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
|
Список | 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 по дате отправления: