From: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-docs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Release note trimming: another modest proposal |
Date: | 2018-08-06 21:17:41 |
Message-ID: | 9FBD8BD2-F2F3-4618-A304-DEE93007EDBB@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
> 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
- 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 | Content-Type | Size |
---|---|---|
release-notes.patch | application/octet-stream | 7.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-08-07 11:31:37 | Re: Release note trimming: another modest proposal |
Previous Message | Tom Lane | 2018-08-06 19:37:45 | Re: Release note trimming: another modest proposal |