public inbox for [email protected]
help / color / mirror / Atom feedFrom: Magnus Hagander <[email protected]>
To: Tom Lane <[email protected]>
Cc: Jonathan S. Katz <[email protected]>
Cc: [email protected]
Subject: Re: Release note trimming: another modest proposal
Date: Thu, 30 Aug 2018 22:13:22 +0200
Message-ID: <CABUevEzqtiA6uDS_VxWEs6tgLJuwQiDwZv7KpGgGe=k06cLbUA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
On Mon, Aug 6, 2018 at 9:37 PM, Tom Lane <[email protected]> wrote:
> "Jonathan S. Katz" <[email protected]> writes:
> >> On Aug 6, 2018, at 3:27 PM, Tom Lane <[email protected]> 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.
>
The current process to load the docs is basically "extract the HTML files
from the tarballs". We run this against the tarballs of any "latest minor
release".
So yes, as long as we are OK with only loading release notes the same way
we do docs, which is from tarballs, then I really don't think this part
will be a problem, and we don't need to do anything about the old files
either. But it's not like we're going to be *editing* old release notes in
branches that are out of support. We'll be trimming them out of the master
branch, but the master branch is not used to load the old docs, only the
developer docs.
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/;
view thread (58+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Release note trimming: another modest proposal
In-Reply-To: <CABUevEzqtiA6uDS_VxWEs6tgLJuwQiDwZv7KpGgGe=k06cLbUA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox