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

Re: New release manager needed.

From: Bruce A. Mah <bmah_at_packetdesign.com>
Date: 2003-07-02 19:42:38 CEST

If memory serves me right, Ben Collins-Sussman wrote:
> pll@lanminds.com writes:
>
> > In release.txt it says:
> >
> > 1. Tweak trunk/CHANGES to contain all the latest changes
> >
> > How do I know what all the latest changes are? Is that stuff I
> > need to gather from an svn diff of the last release or comb through
> > the mail archives, etc.?
>
> Look and see at what point the last release branch was copied from
> trunk. Assume it branched off of /trunk in revision 6000. Then you
> would run
>
> 'svn log -v -r6000:HEAD > logfile'
>
> Then you read 'logfile' very carefully, and try to write a consise
> summary of important events.

I try to do updates to FreeBSD's equivalent of trunk/CHANGES on an
ongoing basis (by reading the commit logs), rather than do everything
right before a release. subversion's release cycle is fairly short, so
it might not make that much of a difference, but on FreeBSD the releases
are so far apart (small number of months) that there's the potential for
a lot of stuff to build up in between.

(A cool thing about subversion is, of course, the fact that you *can*
execute the command line above and get some useful output.)

> > Just curious about what I'm supposed to be putting in there.
>
> This is the toughest "human" part of being a release manager. The
> CHANGES file has a very specific, very terse format. It does not list
> every single change. It only lists the "most important" ones, which
> is a subjective call. How do you make the subjective call? Read
> through the earlier CHANGES entries and try to get a feel for the
> "filter" that people were using, and then try to preserve that filter
> when you start reading commit-logs yourself. It's not an easy thing
> to do. :-)

Almost every release notes-type document will cover something like:
"Things that are critically important to a few users, important to most
people, or interesting to everybody." subversion's trunk/CHANGES file
implements this very well, IMHO.

The fact that this *is* intrinsically hard is why I try to spread the
work out. This is a heck of a good way to learn a little bit about
everything that's happening on a project.

Free advice, worth what you-all paid for it.

Thanks to everyone who's worked on the subversion releases, and good
luck to the new release engineer(s)!

Bruce.

  • application/pgp-signature attachment: stored
Received on Wed Jul 2 19:43:39 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.