db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: 10.3 branch backports...
Date Wed, 11 Jul 2007 22:26:33 GMT

I am happy to allow reasonable control by the release manager.  For
instance I think it is very reasonable if it makes their job easier - I
am very happy for the work they are doing.  For example I think it is
very reasonable for a release manager to ask for a  short hiatus
from the time they are trying to build/test a release candidate at point A
until they are done so that they can have exclusive access to fix stuff
before they can release at point B.  So they don't have to worry about
picking/choosing changes and have to retest because someone slipped in -
worst case they may never get done.  It is nice to be able to say the
release is the branch at point NNNNN - rather than have to say the 
release is at point MMMMMM minus changes A, B and C.

After a release is cut I think we should count on committers and the 
normal "branch" checkin protocol, and hope
they can be even more careful while we are in the release voting cycle.
But I think checking in test changes/fixes are very low risk.  I think
it would be even worse to ask to close a branch that was already 
released, I am not as concerned about the 1st release of a branch as
it seems reasonable to allow the release coordinator control to match
the responsibility they have accepted to coordinate, coerce and shephard 
  the release.


Myrna van Lunteren wrote:
> On 7/11/07, Daniel John Debrunner <djd@apache.org> wrote:
>> 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.
>> >>
> At the same time, it was reported critical and this fix fixes the
> problem...Yeah, this one is arbitrary, I guess. :-)
> 
>> >> > 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
>> change".
>> [http://db.apache.org/source.html]
> 
> fair enough, although, I'd say, with some extra care & communication &
> consideration for the release process...
> 
>>
>> 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.
> 
> ok; although it's not quite so black-and-white, if there is a good
> chance of not many +1 votes, there's not much point, and there'd be
> time and effort wasted because other folks doing testing and checking.
> 
> Myrna
> 

Mime
View raw message