Re: Release note trimming: another modest proposal

On 2/5/19 11:37 AM, Tom Lane wrote:
> I wrote:
>> BTW, while we're thinking about this --- I remembered that as things
>> stand, we've broken my historical practice of putting up first-draft
>> minor release notes for people to look at if they choose. Those will
>> now be in the newest back branch, which we don't have an automatic
>> build-and-post pipeline for, AFAIK. Now, maybe the people who would
>> review those notes are all comfortable with looking at the git
>> commitdiff anyway. But somebody who preferred to wait for the next
>> guaibasaurus run and then look at the website is now out of luck.
>> Would it be possible to drive this aggregation off the git copies
>> of release-NN.sgml (from appropriate branches) instead of the last
>> released versions? Or set up something equivalent to the devel
>> notes pipeline for back branches?
>
> After further thought about that, I'm liking the idea that was
> discussed upthread of setting up a separate git repo for the
> aggregate release notes. It'd have a simple(?) Makefile with
> the only build product being the aggregate release notes as
> HTML (maybe PDF too). The constituent files would be copies
> of the release-NN.sgml files from the master code repo. There'd
> be no particular need for multiple branches in this repo, it'd
> just be latest data all the time.
>
> The main drawback of this approach is the need to copy the
> release-NN.sgml files from the master code repo.

This is where I had a slight moment of panic especially regarding the
release process. Yes, it's not often -- it's an extra step, but perhaps
in the end it saves a lot of headaches and allows us to cover the below.

> But since
> we'd only touch it four or five times a year, that doesn't
> seem like unacceptable overhead to me. The benefits are:
>
> * It's not so hard to cope with the fact that the various
> branches don't all use the same docs toolchain. We'd just
> agree that the release notes repo uses the current toolchain,
> and when transferring over old release notes, they'd have to
> be edited as necessary to make them build.
>
> * The web site could be set up to build-and-publish from this
> repo automatically, more or less like the devel docs are published
> from the master code repo automatically. That'd fix the problem
> I worry about above: drafts could be published by shoving them into
> the release note repo ahead of official release.

The original pgweb patch I wrote sort-of handled this: it basically
looked for release notes within the core repo, found ones that it did
not already have, and stuffed them into a table.

It should not be difficult to repurpose that code to load them in from a
separate repo, and perform that similar parsing.

> (Contrariwise, if we had say a security-related update we did
> *not* want to be visible immediately, we'd just delay transferring
> that to the release note repo.)

I don't see this as an insurmountable issue.

The contrary point I will make is handling this via a different method.
I believe one of the things Magnus objected to in the original patch
upthread (or in a private conversation) was that we were double-storing
the release note data in the patch I proposed. My way around that was
going to perform some careful scripting, i.e:

- Find the version of PostgreSQL from newest to oldest
- Find the associated release notes from newest to oldest
- Make available on the site

Which all should be doable from the current data we store. The advantage
is that allows us to leave everything as is when displaying release
notes on the site.

(which if we end up going this way, I'm happy to work on this)

>
> I'd be willing to do most of the legwork in populating this repo,
> if someone else were to handle the website plumbing.

If we go down the new path, I would be happy to do the website work, it
will require Magnus sign-off if there is a schema change.

Thanks,

Jonathan