Re: Maintaining the list of release changes

Поиск
Список
Период
Сортировка
От Ross J. Reedstrom
Тема Re: Maintaining the list of release changes
Дата
Msg-id 20020208221346.GB14676@rice.edu
обсуждение исходный текст
Ответ на Re: Maintaining the list of release changes  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Maintaining the list of release changes  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Maintaining the list of release changes
Следующее
От: Darren Johnson
Дата:
Сообщение: Re: Replication