Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fvTPn-0000cM-4w for pgsql-docs@arkaria.postgresql.org; Thu, 30 Aug 2018 20:19:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fvTPk-00085s-W6 for pgsql-docs@arkaria.postgresql.org; Thu, 30 Aug 2018 20:19:36 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fvTPk-00085l-Kn for pgsql-docs@lists.postgresql.org; Thu, 30 Aug 2018 20:19:36 +0000 Received: from mail-lf1-x142.google.com ([2a00:1450:4864:20::142]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fvTPf-0000oe-RM for pgsql-docs@lists.postgresql.org; Thu, 30 Aug 2018 20:19:36 +0000 Received: by mail-lf1-x142.google.com with SMTP id h64-v6so8200121lfi.10 for ; Thu, 30 Aug 2018 13:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hagander-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4ImiD9XtJteiNT7SFVgIoGeN/7ApJomgRn+RqS0cTcA=; b=NS9ezDCVg/x6cqo4k+nXj/UTvTH80pZ6epWhHZRqtIfP6802Rx5Xp7HGCPjMaepEXg 6hhSmySNL3W3pxIpLueS3LRIPzHgZysCufwj4C5fembSB8rDvMBuKuXvmh9rS7e8A5Gn 4XifJGok0DZmSb1V6KABKnjv+VJXZS9SSeTj5d5rG5pCHcdqlNzzJYkkg8d/jw4iwK+H 3+GlwbS6tI9AjRlMQkpv5nemvyfQh85YC1wLfae1focT5r9cKlu1V/05KPc7O1RfzqUq 6KbsSr46FMKHEuT+wIxknCuTO1V07fRfUk7uNhgc6VQw6hVl6Og7qRmPD1f5zaRUxHYU fW/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4ImiD9XtJteiNT7SFVgIoGeN/7ApJomgRn+RqS0cTcA=; b=TkunRaFnlbhz+KBLnAE+Ne+SMGfJ+M4bs/CV/AQDsCfd44RJwBFoF3iG0ocr/Lp2P+ 5MkOwmSJ8kthzgiwe5U5VXTFHaPj+AxaCyoN9VIm5U8fkuHMelNr5BKawF72IhoxamLj dZajWStzujpD/xOAW7yBVhYWxF32uECtBx4fyNmM8f7e3Z/cNra9WIH+fQJujJxjNUUg mgqmgWS0CNTLoRoV6AtGtlMg3CuPbA7Q6+3DzyTnMtUC4mfSRWjCJNo3qSBqTUp9L4YI MSRh0MhpJFzxxqdNWzxwA2ZgqYITyN0pIEo9DKusYx7qrieswzlIo6CahYhvSW/FbHfA BuUA== X-Gm-Message-State: APzg51A5GIGJl2BRXdLccP1AcuFELOBxP74qpx1X2VyoOn8XNpB0NEGj Digmf5NeujyCnNOE+SljVVhRupZ+BsZ/k0UFsj/z4Q== X-Google-Smtp-Source: ANB0VdbdXYBedqwRm3wwK0nqPIsczP8atm0V1BQ/u7TzsGzB+KPgbR9djuWGVB6rPdbIo9xnqNZA81mldkBVYJFV6Jo= X-Received: by 2002:a19:1517:: with SMTP id l23-v6mr8952850lfi.69.1535660369732; Thu, 30 Aug 2018 13:19:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:18e4:0:0:0:0:0 with HTTP; Thu, 30 Aug 2018 13:19:28 -0700 (PDT) In-Reply-To: <9FBD8BD2-F2F3-4618-A304-DEE93007EDBB@postgresql.org> References: <19252.1533509841@sss.pgh.pa.us> <37D00E58-A0F0-42E4-83F1-A124A282575D@postgresql.org> <18020.1533568149@sss.pgh.pa.us> <04F6EF85-C7B7-42F3-84BC-D5670C9D77E1@postgresql.org> <19825.1533570442@sss.pgh.pa.us> <3070E803-B5D5-46DA-80E5-47B43BE9B085@postgresql.org> <23297.1533574521@sss.pgh.pa.us> <660.1533583153@sss.pgh.pa.us> <1083.1533583655@sss.pgh.pa.us> <1F8EA64B-695C-4893-A436-B655C840788D@postgresql.org> <1620.1533584265@sss.pgh.pa.us> <9FBD8BD2-F2F3-4618-A304-DEE93007EDBB@postgresql.org> From: Magnus Hagander Date: Thu, 30 Aug 2018 22:19:28 +0200 Message-ID: Subject: Re: Release note trimming: another modest proposal To: "Jonathan S. Katz" Cc: Tom Lane , pgsql-docs@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000d5bd2e0574accacf" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000d5bd2e0574accacf Content-Type: text/plain; charset="UTF-8" On Mon, Aug 6, 2018 at 11:17 PM, Jonathan S. Katz wrote: > > > On Aug 6, 2018, at 3:37 PM, Tom Lane wrote: > > > > "Jonathan S. Katz" writes: > >>> On Aug 6, 2018, at 3:27 PM, Tom Lane 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/ Work: https://www.redpill-linpro.com/ --000000000000d5bd2e0574accacf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Aug 6, 2018 at 11:17 PM, Jonathan S. Katz <jkatz@postgresql.org= > wrote:

> 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&#= 39;s relnotes
>>> from the active branches, the only copy of that data is the on= e in the
>>> archive table the docload script is filling.=C2=A0 Given, say,= a bug in the
>>> docload script that causes it to overwrite the wrong table ent= ries,
>>> can we recover?
>
>> Well, the release notes are still in the git history as well as th= e 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 curre= nt
> workflow can process.=C2=A0 For instance, if we did another documentat= ion
> 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.=C2=A0 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 s= eparate copy of them. I think we can find a way to make it work off the cur= rent data, which would simplify the process a bit I think.
=C2=A0=
- Display the release notes via pgweb akin to earlier screenshots

A thought on this.

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

We have all the old branch tip release notes alr= eady 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 directl= y to those release notes?

One advantage of that wo= uld 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 en= d up under "docs" in the navigation breadcrumbs, rather than unde= r "release notes". But is that really a problem?
=
--
=C2=A0Magnus Hagander
=C2=A0Me: https://www.hagander.net/<= br>=C2=A0Work: https://www.redpill-linpro.com/
--000000000000d5bd2e0574accacf--