db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: 10.3 branch backports...
Date Wed, 11 Jul 2007 18:20:16 GMT
Myrna van Lunteren wrote:
> On 7/11/07, Daniel John Debrunner <djd@apache.org> wrote:
>> Myrna van Lunteren wrote:
>> > Hi,
>> >
>> > I realize I haven't said what I wanted to go on the 10.3 branch at this
>> > point.
>> >
>> > I would like to minimize the changes to what has been identified as
>> > critical issues at this point; once we have a release, the 'normal'
>> > rules for backporting to a branch apply.
>> >
>> > So, Kathey, if you could backport your fix for the grantRevoke test
>> > fir DERBY-2893? *If* we need another candidate this fix should be in.
>> That actually wasn't a critical issue once it was resolved to be a test
>> problem.
>> > Dan, if you could hold your backport plans for your intended changes?
>> > Same for Bryan and the fix for DERBY-2902; but you already said you'd
>> > wait, thx...
>> Why not allow these fixes in under normal branch backporting rules,
>> especially now that blob/clob changes are apparently needed? Isn't
>> better to have fixes in the release? Bryan's fix, for example is zero
>> risk. Most of my changes would be to improve the testing, I would think
>> carefully about putting the my changes for DERBY-2775 in since they are
>> more widespread, but they will go into the branch at some point.
>> One of the rules for a release is that it must not halt development,
>> seems like not allowing fixes into a branch is halting development.
>> Dan.
> There's black, and white, and grey...There's must have, and might be 
> nice...
> One way to answer this, is to say, development continues on trunk, so
> there's no halting of development.
> Another point, is to ask what the purpose of the release cycle is, if
> we're allowing *any* change to go in, which is what you seem to be
> advocating (even when you're holding back on DERBY-2775).
> What means 0 risk, how do we decide, what are the criteria, measurements?
> (not that I'm contesting any particular issue).

Same rules as usual, committer has a "high degree of confidence in the 

I can also just ask the same question back, what's your current 
requirements for accepting fixes into 10.3 branch? Seems like it is if 
the bug is marked as critical or blocker (regardless of the risk of the 
fix?). The changes for DERBY-2893 don't fall into that category though.

> I had hoped to do another 1 week VOTE period, if we accept more fixes
> to go in the release, we may need to choose to block out more time,
> and postpone the release further.

One way to look at it, is to put a release (with any fixes) up for a 
week's vote. If anyone believes the need more time to test because of 
the recent changes they won't vote +1, those that are comfortable with 
the recent changes and the state of the release will vote +1.


View raw message