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? :-)
Bruce.
Received on Thu Jul 15 17:03:21 2004