Re: Release note trimming: another modest proposal - Mailing list pgsql-docs

From Jonathan S. Katz
Subject Re: Release note trimming: another modest proposal
Date
Msg-id 9FBD8BD2-F2F3-4618-A304-DEE93007EDBB@postgresql.org
Whole thread Raw
In response to Re: Release note trimming: another modest proposal  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Release note trimming: another modest proposal  (Magnus Hagander <magnus@hagander.net>)
List pgsql-docs
> On Aug 6, 2018, at 3:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>>> On Aug 6, 2018, at 3:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Actually, a concrete reason why that might not be good is that it results
>>> in having a single point of failure: once we remove branch N's relnotes
>>> from the active branches, the only copy of that data is the one in the
>>> archive table the docload script is filling.  Given, say, a bug in the
>>> docload script that causes it to overwrite the wrong table entries,
>>> can we recover?
>
>> Well, the release notes are still in the git history as well as the tarballs.
>> One could always pull an older tarball of PostgreSQL with the full
>> release.sgml and load from there.
>
> True ... as long as those older tarballs represent data that our current
> workflow can process.  For instance, if we did another documentation
> format change (from XML to something else), the older tarballs would
> perhaps no longer be useful for this purpose.
>
> On the other hand, it's hard to believe that we'd make such a conversion
> without tools to help.  So probably if the situation came up, we could
> cobble together something that would allow ingesting the old format.

Attached is a (rough) working copy of the patch to pgweb. It can:

- Extract the release notes from the docload and puts them into their
own table
- Display the release notes via pgweb akin to earlier screenshots

It needs:

- The notes actually exposed in the navigation tree
- Review how some of the xrefs are translated (esp. non-release ones)
- Dependency on all major versions being cataloged in our “Version”
table on pgweb, which currently we do not do
- Magnus review, as to do this I introduced a new Python dependency

I was able to successfully load all of the release notes from the 10.4
tarball and spot checked view several different major/minor version
combinations.

It’s not near production ready, but wanted to demonstrate that it would
not be too hard to get this done.

Jonathan


Attachment

pgsql-docs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Release note trimming: another modest proposal
Next
From: Michael Paquier
Date:
Subject: Re: Release note trimming: another modest proposal