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

Re: Let's set a date/goal for the 1.5 Branch

From: Mark Phippard <markphip_at_gmail.com>
Date: 2007-08-31 21:56:36 CEST

On 8/31/07, Greg Stein <gstein@gmail.com> wrote:
> Yup, it's Hard, and I'll note that branching too early could reduce
> testing, much like keeping the stuff on the frickin' branch for so
> long was horribly costly.
> When we did 1.0, we stabilized on the trunk, not on a branch. You
> branch to allow other dev to occur on the trunk. Or when you're in
> *the* final stretch. Thus, the idea of branching on a date is
> somewhat, inherently wrong. It is hard to know *today* what sort of
> shape the trunk will be in.
> IMO, the concept of a date is corporate-speak. The proper mechanism is
> a status file of open items, along with the open issues (oh, and the
> idea of an issue for all work items is also corporate). Then people
> focus on the file/issues and work that to empty. *then* branch.
> Note that posting a weekly summary of 1.5 issues, along with that
> status file is a great way to "surface" the info so that all devs can
> see what is left. If that email can also cover progress, then devs can
> also see/feel like stuff is happening.
> This is more akin to agile dev than classic feature&date product
> delivery, which usually fails anyway.

Just for the record, I agree with all of this and if anyone feels I
was suggesting otherwise let me clarify.

I have no objection if people are still doing stuff outside the issue
tracker, or if they are working on stuff that does not have the 1.5
milestone set. What I am saying is this:

1. If you know of an issue that could block/delay the 1.5 release
please raise its visibility. The issue tracker and the 1.5 milestone
is what we agreed to for this a few weeks ago. If you want to use the
mailing list, I will be happy to enter to the issue tracker.

2. The idea of a date is to set a goal, and also to make people aware
that the end of year is coming fast. If you want to work on a new
feature and do not think it can be wrapped up by this date, put it on
on a branch. We do not need to destabilize trunk with new features we
were not planning.

3. I am assuming is fairly stable already, known issues not with
standing. I would hope we would branch and cut RC1 all in a short
time frame. At least that is what I proposing.

Mark Phippard
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 31 21:53:41 2007

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