Re: Release notes - Mailing list pgsql-hackers

Also, personally, I would rather do it all at once rather than
throughout the development cycle.  It is like moving 100 potatoes one at
a time compared to placing them in a sack and moving them all at once.

Also, we are having trouble getting enough people to review/commit. 
Does adding an extra step discourage them even further?  I asked for
backpatch mentions in the CVS commit logs and got pushback from that. 
How is maintaining another file on every commit going to go over?

I have enough trouble keeping CVS activity straight.  This would add an
additional item for me to keep in sync with CVS.

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

Bruce Momjian wrote:
> 
> 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. +
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faq

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