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

Re: Release targets and timeline for 1.4?

From: Greg Stein <gstein_at_lyra.org>
Date: 2006-01-31 08:52:16 CET

On Mon, Jan 30, 2006 at 11:32:04AM -0600, kfogel@collab.net wrote:
> Justin Erenkrantz <justin@erenkrantz.com> writes:
> > For x.x.0 releases with all of the RCs, it's actually a *lot* of work.
> > Ask Dave. Patch releases are much easier to cut as the initial
> > testing has been done on the minor. But, declaring a trunk version as
> > stable, IMHO, places a lot of work on the RM to try to understand what
> > changed and where to look for new problems.
> I think that's the most constructive thing anyone's said yet:
> "Ask Dave" :-)
> Yes, let's. Dave? How do you feel about this?

Is the question asked a means to prove or disprove the various points
of view? I don't think that is constructive. It is an interesting
question, but I hope the result is not used to say "nyeah. see? I told
you so!" :-)

The load on the RM is one factor. There is also the amount of time
that the development community gets to spend on the next release(*),
expecting of users, and more.

(*) if some devs work on release and get shut out of contributing to
the next release, are you making them happy? "But they have a choice!"
you might respond. They certainly do, but sometimes they will choose
an answer that is responsible rather than fun ("somebody needs to work
on stabilizing"). And for a developer who enjoys working on SVN to
ship *features* to be cut out (due to timing) from that enjoyment is
probably not a good thing for anyone (certainly that dev, but possibly
the project in terms of the dev's future contributions when it no
longer becomes fun).


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 31 08:48:58 2006

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.