Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: domain of m.v.lunteren@gmail.com
 designates 209.85.132.246 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=MuQzTAwxVJXB5sHoZRPoUGbJlrwDbFWJ9NeUCNYXpRR2OSgtC3Te1Plae7TY5QvHHXgzgftRp9e8T8otqwFWVP8JZzr1M2EeCJnsrAdS5tCqK25vuZZIwZ9+9jsu5HaSFFGRvvznyv+kN0Kx8wkVz9wgxb4A559PjFOprpdWG9U=
Message-ID: <c25576af0707111323l36730a3aha121b4a23cdea78@mail.gmail.com>
Date: Wed, 11 Jul 2007 13:23:44 -0700
From: "Myrna van Lunteren" <m.v.lunteren@gmail.com>
To: derby-dev@db.apache.org
Subject: Re: 10.3 branch backports...
In-Reply-To: <46951F60.7070500@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <c25576af0707101549i35c68f53r780ab0f6aec892f@mail.gmail.com>
	 <469513A6.8080808@apache.org>
	 <c25576af0707111049q6783ecd4p52ea6769dfcf2953@mail.gmail.com>
	 <46951F60.7070500@apache.org>

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