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

Re: The Drive to 1.5

From: David Glasser <glasser_at_mit.edu>
Date: 2007-07-10 15:16:04 CEST

On 7/10/07, Karl Fogel <kfogel@red-bean.com> wrote:
> "Mark Phippard" <markphip@gmail.com> writes:
> > Hopefully this is not inappropriate given that I do not contribute
> > very much to the actual code. But I do follow and participate in the
> > process very actively so I am fairly well in tune with what is going
> > on. It seems like we are drawing closer to the end of the 1.5
> > development cycle. There is still work to be done for sure, things we
> > all want to see done. I am not suggesting we are ready to branch,
> > because we are not.
> >
> > In the interests of working towards the point when we can branch,
> > however, I think it would be a good time to start defining what is
> > left to do. I know that Dan has been doing a good job maintaining a
> > to-do list for merge tracking in:
> >
> > http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt
> >
> > There are definitely still some things to do on that list, but it is
> > definitely shrinking. I get the sense that there are a lot of
> > "loose-ends" throughout various aspects of the product that only
> > different sets of people know much about. I think it would make sense
> > to establish some kind of master TODO file in trunk where we can start
> > to record all of the things that need to get done before we branch.
> > This would accomplish a few things:
> >
> > 1) Increase visibility of what is left to be done. This will help
> > focus our efforts on what needs to be done. It is summer, which means
> > people are going on vacations. We don't want something to get missed
> > because the only person that knows about something is away. Having a
> > list might also help motivate people that have a couple of spare hours
> > to knock something off it.
> >
> > 2) It should help with communication and help set our expectations for
> > the release. As an example, the recent changes that make it easier to
> > use Serf with Neon has also raised the awareness that we have work to
> > do in ra_serf. Was someone hoping to tackle all of that work before
> > 1.5? Please do not answer here, it is an example. The point is that
> > if someone adds that to the TODO list it can open up the topic for
> > discussion and negotiation, especially if it gets to a point where it
> > is the only remaining item. Again, this is just an off-the-cuff
> > example, do not read anything into the specifics.
> >
> > 3) Give us a better idea of when we are going to branch.
> >
> > I know that historically the project has not maintained a TODO list,
> > or wanted to have one around. It just seems like this release is
> > really big and there are these little loose ends all over the place
> > that need to be documented before they are forgotten. Maybe a lot of
> > them have been cleaned up already, but a list would help make that
> > clear as well as allow us to prioritize what is remaining.
> >
> > Finally, I am not proposing any kind of high ceremony process or
> > document here. Just a place where people can record things that
> > either they want to get done themselves or maybe no needs to be done
> > before we can release. This issue with the fsfs transaction names is
> > a good a recent example.
> Good idea -- how about just making it be the 1.5 release notes file,
> with extra slots for individual "todo" sub-items? As they are done,
> we can just remove them. What remains would be the high-level feature
> and change descriptions, that is, the usual release notes.

This is the first release cycle I've been around for the beginning
of... do we also want to do some triage/milestone-setting in the issue
tracker at some point?


David Glasser | glasser_at_mit.edu | http://www.davidglasser.net/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 10 15:15:40 2007

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.