Re: Alpha Releases: Docs? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Alpha Releases: Docs?
Date
Msg-id 603c8f070908051808t664a9f55u73f8616860e761b7@mail.gmail.com
Whole thread Raw
In response to Re: Alpha Releases: Docs?  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Alpha Releases: Docs?  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Wed, Aug 5, 2009 at 6:59 PM, Josh Berkus<josh@agliodbs.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables
Next
From: Bruce Momjian
Date:
Subject: Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables