Re: Release notes - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Release notes
Date
Msg-id 200609142213.k8EMDMG12275@momjian.us
Whole thread Raw
In response to Re: Release notes  (Neil Conway <neilc@samurai.com>)
Responses Re: Release notes  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
The only win to doing this incrementally is that people will have some
idea of what is the release before I create the list just before beta. 
This will probably save me only minimal amount of time compared to the
extra work it will require of everyone.  Also consider patches on top of
patches are going to require someone knowing what is already on the list.

---------------------------------------------------------------------------

Neil Conway wrote:
> Bruce Momjian wrote:
> > There are problems with this.
> 
> There are going to be problems with just about any proposal, but I think 
> updating the release notes incrementally is still a clear net win.
> 
> > First, since everyone isn't going to do it, I still have to go
> > through all the CVS logs, and then I have to merge the created list
> > to avoid duplicates.
> 
> A solution would be to require all the committers to do it: we can say 
> that any CVS commit that makes a user-visible change should update the 
> release notes as part of the commit. If anyone sees a commit that fails 
> to do this, they can flame^H email the guilty party. People submitting 
> patches can include an update to the release notes directly, or else the 
> committer can write the release note entry if necessary. This is similar 
> to the policy on documentation updates, which seems to have worked 
> decently well.
> 
> I would be happy to volunteer to do my best to ensure that this policy 
> is applied for the 8.3 development cycle, if enough people agree that 
> this is worth doing.
> 
> > Then there is the problem that we need consistent wording through the
> > release notes, so again, I have to wack around some more text.
> 
> I think this is a strange objection. Many different people have 
> contributed to the documentation, and yet we've managed to keep the 
> wording reasonably consistent throughout -- I think we can manage 
> consistent usage in some release notes. Frankly, the grammar and diction 
> in the release notes is often not perfect on the first draft anyway, so 
> there needs to be copy-editing done regardless.
> 
> > Doing it in one pass is the most reliable, and efficient.
> 
> Does anyone else have any opinions on this?
> 
> -Neil
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: information_schema vs temp tables (was Re: [COMMITTERS] pgsql: Sequences were not being shown due to the use of lowercase `s`)
Next
From: Tom Lane
Date:
Subject: Re: [ADMIN] Vacuum error on database postgres