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 17:49:41 GMT
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).

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.


View raw message