Re: Maintaining the list of release changes - Mailing list pgsql-hackers

From Ross J. Reedstrom
Subject Re: Maintaining the list of release changes
Date
Msg-id 20020208221346.GB14676@rice.edu
Whole thread Raw
In response to Re: Maintaining the list of release changes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Maintaining the list of release changes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Feb 08, 2002 at 04:03:39PM -0500, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> I think I prefer the file-of-notes idea, but this is a possibility worth
> >> suggesting.
> 
> > We can do whatever people want.  I was just afraid it would be too much
> > work for people, and I am willing to continue doing it. Actually, if
> > people want to help, looking over the final is 10x more valuable than
> > having a separate file, at least for me.
> 
> Even if people do review the notes, who's to say they'll remember a
> change they made months ago?  I think it's important for developers to
> prepare at least a rough-draft entry for the release notes at the time
> the change is made.  We can debate different ways to keep that info
> available until the docs are prepared, but the real problem here is to
> not rely on memory.

The _really_ critical piece for making this cumulative file work: _every_
user visible change needs to go into it, at the time it's commited to CVS.
Be hardnosed, so external patches _must_ touch that file, or put it in
the commit log. The problem with the commit log is that it puts the onus
on the CVS commiter, not the patch maker.

I'm partial to a combo - a 'USER VISIBLE CHANGES: <yes|no>' line in CVS
commit logs (put it in the template, default to yes?) and every 'yes'
submit _must_ patch the cumulative release file.

Ross


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Maintaining the list of release changes
Next
From: Darren Johnson
Date:
Subject: Re: Replication