Re: Alpha Releases: Docs?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Alpha Releases: Docs?
Date: 2009-08-06 01:08:08
Message-ID: 603c8f070908051808t664a9f55u73f8616860e761b7@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 5, 2009 at 6:59 PM, Josh Berkus<josh(at)agliodbs(dot)com> wrote:
>> As far as the release notes, I think we would have to have proof that
>> the alpha-generated release notes are as good or close to the quality of
>> the release notes using the current process.  If they are, we can use
>> them for 8.6, or even for 8.5 if the quality is similar, but we can't
>> know that without creating identical release notes for 8.5 and comparing
>> them, to make sure the alpha process has not missed any items, etc.
>
> I can't speak for Robert or Peter, but for me this gives me exactly zero
> incentive to bother.  If you're just going to do the same amount of work
> anyway ... and potentially delay the release by just as much ... then
> there's really no point on me spending my nights and weekends wrestling
> with SGML formatting.  I'll leave it to you.

I think I am in agreement. Parsing Bruce's words carefully, he seems
to be saying that the only way to determine whether the release notes
are of sufficient quality is to repeat the whole process of release
note generation ab initio to determine whether what has been produced
is good enough. Presumably this would be followed by some comparison
of the two work products (by a panel of impartial judges?).

I can't believe this is necessary. It ought to be possible with
careful bookkeeping to make it easy to verify that every commit has
been either included or intentionally omitted. The obvious system
that occurs to me is to track the git hash of each commit and the
release note text associated with it, but I am sure there are other
unique identifiers that could equally well be used. Once you've
verified that, then the only remaining issue is the actual quality of
the work product, and I would think that it could be much faster to
edit someone else's work than to do the whole thing over. Peter and
Josh both have excellent written communication skills, and I like to
think that I do as well; I would think that the necessary work would
be more on the order of fine-tuning than a wholesale rewrite.

That having been said, I am not going to spend a lot of time trying to
push water up a hill.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2009-08-06 01:25:40 Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables
Previous Message Tom Lane 2009-08-06 00:05:25 Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables