[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: branch 1.5?

From: David Glasser <glasser_at_davidglasser.net>
Date: Mon, 28 Jan 2008 19:57:15 -0800

On Jan 28, 2008 7:36 PM, Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu> wrote:
>
> David Glasser wrote:
> > On Jan 28, 2008 1:25 PM, David Glasser <glasser_at_davidglasser.net> wrote:
> >> I think that given the amount of work that is needed, we should have a
> >> relaxed approach to backporting until we're actually ready to roll a
> >> release candidate (either not using the STATUS system at all, or
> >> requiring just two votes (which can be on IRC), etc).
> >
> > Now that Mark has proposed a time for branching (which I am +1 to),
> > I'd like to propose something more specific here. I think that for
> > the short-term future, until we're closer to the point of an RC, that
> > we treat the entire 1.5 branch with the policy we usually apply to
> > non-core code. That is, we require one +1 from a full committer and
> > one +0 from any committer to do a backport. (And this can happen over
> > IRC or whatever and never even pass through the STATUS file, as long
> > as the votes are recorded in the backporting log message.)
>
> Sounds good, though I would recommend still having a STATUS file. It is
> a convenient place to put nominations when nobody is around for an
> immediate review. (Not that you were proposing to do away with STATUS
> completely, I just wanted to make sure it was clear.)

Yup, that's what I meant; just that if somebody approves something
before it makes it into STATUS, you don't need an extra revision of
adding the block to STATUS.

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-29 04:57:28 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.