Re: Release notes

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(at)momjian(dot)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(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

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