Re: Release notes

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Release notes
Date: 2006-09-14 22:13:22
Message-ID: 200609142213.k8EMDMG12275@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-09-14 22:13:49 Re: information_schema vs temp tables (was Re: [COMMITTERS] pgsql: Sequences were not being shown due to the use of lowercase `s`)
Previous Message Neil Conway 2006-09-14 22:08:48 Re: Release notes