db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren" <m.v.lunte...@gmail.com>
Subject Re: 10.3 branch backports...
Date Wed, 11 Jul 2007 20:23:44 GMT
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