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

Re: svn commit: r10268 - trunk

From: Bruce A. Mah <bmah_at_acm.org>
Date: 2004-07-15 17:02:47 CEST

On Thu, 2004-07-15 at 06:56, Andy Whitcroft wrote:
> --On 13 July 2004 22:52 -0500 Ben Collins-Sussman <sussman@collab.net>
> wrote:
> > On Tue, 2004-07-13 at 21:00, Jani Averbach wrote:
> >
> >> Well, I could only guess. In the light of this experience, do you
> >> think it would be worth to keep our CHANGES up to date in the same
> >> way as httpd project does it?
> >
> > No, I still think there's a great advantage to having a single author
> > write the CHANGES description in a single sitting. It makes the
> > description more readable and more consistent.
> I would say that a combination of the two makes sense. Anyone committing
> anything significant could add something to CHANGES, then at release time
> someone can go though and write it all up using those as pointers. At
> least you have something to work with this way.

Warning: Huge apples to oranges comparison approaching...

When I maintained FreeBSD's release notes (from about 4.3 to 5.2.1), I
used the "write as you go along" approach, with updates about once a
week. However, I probably wrote 95+% of the text, so it was *almost* a
single author kind of thing with the consistency that Ben mentioned. My
thinking was that I never wanted to have a huge backlog of work that
would take hours and hours to write at the last minute before we
finalized a release.

From looking at the Subversion 1.1rc1 CHANGES file it looks like it was
just big enough that I wouldn't have wanted to write it all in one go.

Yeah, I know there's a huge difference between FreeBSD's release notes
and Subversion's CHANGES file, but the process looked pretty similar to
me. You-all read my warning, right? :-)


Received on Thu Jul 15 17:03:21 2004

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.