Re: Release note trimming: another modest proposal

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-docs(at)lists(dot)postgresql(dot)org
Subject: Re: Release note trimming: another modest proposal
Date: 2018-08-30 20:19:28
Message-ID: CABUevExQ9soaQN374S1WF6baSkho+vB6VN0Ha5WN0JWJh=hjTw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

On Mon, Aug 6, 2018 at 11:17 PM, Jonathan S. Katz <jkatz(at)postgresql(dot)org>
wrote:

>
> > On Aug 6, 2018, at 3:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > "Jonathan S. Katz" <jkatz(at)postgresql(dot)org> writes:
> >>> On Aug 6, 2018, at 3:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
>

Not a huge fan of keeping a separate copy of them. I think we can find a
way to make it work off the current data, which would simplify the process
a bit I think.

> - Display the release notes via pgweb akin to earlier screenshots
>

A thought on this.

Do we actually need a separate copy of the release notes at all? What I
mean is:

We have all the old branch tip release notes already on the site, in the
docs for that particular version. Wouldn't we get pretty far by just
creating a separate *index*, that then links directly to those release
notes?

One advantage of that would be that we'd get away from that link rewriting
that you did in your patch -- because the docs will actually live at their
"natural" location.

The downside would be that they'd end up under "docs" in the navigation
breadcrumbs, rather than under "release notes". But is that really a
problem?

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message Bruce Momjian 2018-09-01 22:55:57 AT TIME ZONE correction
Previous Message Magnus Hagander 2018-08-30 20:15:19 Re: Release note trimming: another modest proposal