db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Bumping the fourth digit
Date Wed, 11 Feb 2009 14:07:47 GMT
Jean T. Anderson wrote:
> Rick Hillegas wrote:
>> Jean T. Anderson wrote:
>>> Rick Hillegas wrote:
>>>> Jean T. Anderson wrote:
>>>>> Kathey Marsden wrote:
>>>>>> Rick Hillegas wrote:
>>>>>>> As a test of this, I have updated the description of

>>>>>>> You can see this by clicking on the link you forwarded. Does

>>>>>>> this format look reasonable to you?
>>>>>> I think we cannot include an url to the Sun build in Jira.  
>>>>>> According to:
>>>>>> http://www.apache.org/dev/release.html
>>>>>> "Do not include any links on the project website that might 
>>>>>> encourage non-developers to download and use nightly builds, 
>>>>>> snapshots, release candidates, or any other similar package.
>>>>>> ...
>>>>>> Under no circumstances are unapproved builds a substitute for 
>>>>>> releases. If this policy seems inconvenient, then release more 
>>>>>> often. Proper release management is a key aspect of Apache 
>>>>>> software development.
>>>>> That www.apache.org/dev/release.html policy governs distribution 
>>>>> of software produced by an Apache project and made available for 
>>>>> download from  an Apache website.
>>>>> Why are we concerned about tracking releases produced by 
>>>>> non-Apache entities, such as Sun?
>>>> And IBM. And anyone else who wants to build a distribution from the 
>>>> community branches. We're talking about tracking and fixing bugs 
>>>> which are logged against commit points on a community codeline, 
>>>> whether that is the development mainline or one of our stable 
>>>> branches. This is useful to everyone who drinks out of the common 
>>>> well.
>>> but it doesn't make sense for an apache project to reference 
>>> somebody else's external (non-Apache) build or distribution.  
>>> --That's a slippery slope that would then need to accommodate 
>>> anybody who comes along. And we should never bump the Derby release 
>>> number to accommodate an external project.
>> Hi Jean,
>> If you need to fix bugs in the metadata queries, then you have to 
>> bump the last digit of the release id in order to coax Derby into 
>> recompiling the queries. This is what IBM did to fix DERBY-3919. 
>> Committers fix bugs all the time in order to accommodate external 
>> projects. Do you believe that the community has agreed to a 
>> limitation on updates to the last digit of the release id, and if so, 
>> what are those limitations?
> I think I'm not quite understanding the fundamental issue here.  I 
> have no problem with Sun tech support finding a problem, doing the 
> fix, and committing it to Apache. Or IBM doing the same thing. Or Joe 
> WhomEver from Company X.
> The issue is if any external entity fixes something in their own 
> distro that hasn't been contributed back to apache yet, they're on 
> their own. I don't think we should accommodate that. But rereading 
> this, I don't think this is what you intended and I misunderstood. I'm 
> sorry.
No need to apologize. I think the issues are still a bit tangled and 
we're all muddling through this together.
> Sun effectively released from the 10.4.2 branch to include a fix that 
> is in that branch at Apache, but "10.4.2" isn't specific enough to 
> identify what comprises that release. Is this right? :-)
That's right. We're talking about bugs that were fixed in the open and 
patches that were checked into the community codeline..
> In this case, I agree that we might want to consider bumping the digit 
> on a per-request basis, but I want to make sure that we do this in a 
> way that makes general sense. And I also realize that this might 
> conceivably leave us open to criticism that we are enabling support 
> for unofficial releases.
A couple more thoughts:

1) It helps me to separate the version id in the branch from the version 
id in JIRA. I would have no problem with bumping the 4th digit of the 
branch id every time someone checked a bugfix into the branch. I'm not 
saying I want to do this, I'm just saying that it wouldn't bother me.

2) It would seem simpler to me if we had generic release ids in JIRA, 
like "10.3.next" and "10.4.next". The meaning of these ids is "the next 
release vehicle created from that branch". We don't really know what the 
release id will be until we've generated a couple release candidates and 
at that point, the release manager has to bulk-reassign the "fixed-in" 
field anyway.

3) Then there is the question of how to mark issues whose fixes appear 
in distributions which were created outside the community even though 
the distributions were created from community codelines. Is this 
information which the community should track?

4) There's also the question of how to log bugs which surface in one of 
these external distributions. These are bugs in the community code and 
everyone benefits from knowing about these bugs and from their fixes. 
What should we put in the "affects version" field? How do we signal what 
the subversion commit-stamp is--the bug-fixer may need this information. 
It seems to me that the main sources of bug reports are:

a) Bugs arising in official Derby releases which users have downloaded 
from the Apache website

b) Bugs arising in Cloudscape releases. If I understand correctly, these 
releases roll up additional bug fixes on top of what appear in the 
community distributions. That is, these distributions represent a 
subversion commit-stamp further along the branch than the corresponding 
community release.

c) Bugs arising in Java DB releases whose bits are identical to official 
Derby releases and whose subversion commit-stamps are identical to 
community releases.

d) Bugs arising in Java DB releases which roll up additional bug fixes, 
like the Cloudscape releases.

> My actual preference here is if there's a need for release with, let's 
> say, 2 bug fixes, go ahead and release officially. :-) I would think 
> that a branch + 2 fixes (or however many) would be an easy shoe-in for 
> a release vote because all the heavy lifting was done on that release 
> for that branch.
This would be a way forward if our release process were simpler. I think 
that our procedures are improving, but as Myrna points out in a later 
message, producing a Derby release takes a fair amount of time. The 
community process adds a minimum of 2 weeks to the production of a patch 
release. That's too long for someone who needs to get an emergency patch 
to a customer.

> -jean

View raw message