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

Re: One free Release Manager Hat to first taker!

From: <kfogel_at_collab.net>
Date: 2003-10-26 23:40:06 CET

pll@lanminds.com writes:
> It is with deep regret that I must announce my resignation from the
> position of release manager.

Thank you for all your hard work, Paul, and for the offer to stick
around and help the next release manager get up to speed!

I see that Jostein Andersen has already volunteered, and others may be
considering it too (please post if so).

Before we hand off the hat to a new person, I'd like to first describe
the job, so people know what they're getting into. It's not as easy
as you might think.

The release manager's job is:

   * Update the CHANGES file. This basically means going over all the
     commits since the last release, and summarizing them in a way
     that tells users and developers the important news, but doesn't
     overwhelm them in details. In order to do this, one must
     (obviously) be able to distinguish branch changes from trunk
     changes, tell what's been merged, and understand the user-visible
     implications of each change.

   * Make the release branch, and communicate with the other
     developers to determine if any changes need be merged in or out
     of that branch (i.e., a release is not always a straight copy of
     some particular trunk revision).

   * Carefully follow the laborious procedure in notes/releases.txt,
     making sure to test the release tarball over all three ra layers
     (so familiarity with 'make check' in all its forms is a plus).

   * Post the tarball, update the www/project_status.html page, etc.

   * Watch carefully to see if there are any problems, be ready to
     repeat the entire process if there are.

The first item, the CHANGES file, is probably the hardest, in terms of
time and concentration. You may prefer to keep it up-to-date as
commits are made -- but whichever way, it needs to be done by one
person, not by committee, so it has a consistent tone, and so that
items have the right relative priorities.

I'm sure this isn't enough to scare Jostein off :-), I just wanted to
make clear the level of commitment needed here (since we have a bit of
time before the next release anyway).


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 27 00:19:00 2003

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.