10.3 branch backports...

[Myrna van Lunteren <m....@gmail.com>]

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.

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...

Thx,
Myrna

Re: 10.3 branch backports...

[Mike Matrigali <mi...@sbcglobal.net>]

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 <dj...@apache.org> wrote:
>> Myrna van Lunteren wrote:
>> > On 7/11/07, Daniel John Debrunner <dj...@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
> 

Re: 10.3 branch backports...

[Myrna van Lunteren <m....@gmail.com>]

On 7/11/07, Daniel John Debrunner <dj...@apache.org> wrote:
> Myrna van Lunteren wrote:
> > On 7/11/07, Daniel John Debrunner <dj...@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

Re: 10.3 branch backports...

[Daniel John Debrunner <dj...@apache.org>]

Myrna van Lunteren wrote:
> On 7/11/07, Daniel John Debrunner <dj...@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 
change".
[http://db.apache.org/source.html]

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.

Dan.

Re: 10.3 branch backports...

[Myrna van Lunteren <m....@gmail.com>]

On 7/11/07, Daniel John Debrunner <dj...@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).

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.
I'll be back in September, we could do a release then.

Myrna

Re: 10.3 branch backports...

[Daniel John Debrunner <dj...@apache.org>]

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.