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 1fvTJp-0000KW-S2 for pgsql-docs@arkaria.postgresql.org; Thu, 30 Aug 2018 20:13:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fvTJo-0001G3-0K for pgsql-docs@arkaria.postgresql.org; Thu, 30 Aug 2018 20:13:28 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fvTJn-0001Fw-NF for pgsql-docs@lists.postgresql.org; Thu, 30 Aug 2018 20:13:27 +0000 Received: from mail-lj1-x242.google.com ([2a00:1450:4864:20::242]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fvTJk-0004nQ-OG for pgsql-docs@lists.postgresql.org; Thu, 30 Aug 2018 20:13:26 +0000 Received: by mail-lj1-x242.google.com with SMTP id f1-v6so8318847ljc.9 for ; Thu, 30 Aug 2018 13:13:24 -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=yAF7UWnCIW8eC4sb2Q9LJLuzsBnDu9v8NUBR5omJgmY=; b=l3ZePDb+e8hNDdeAa7zwypfGHQtYFjJu/2ts82LmR5Ivlfyrc30T1aV321v8VpNmdv 4XqoV5OVEFC4deCHwIFmuP9uLfiS8wJaHnVdHtGDvQ+Yni1LYK4e5jtxW3bZzhYVZMGX XJMk9NtUmaex5S80GkGqgwhGENCNbsqKMtM0dDIqdT8YfKinAVL9sWq5MZ1lLqjBZ3vW Ss8UM6SHYJ1EHGGaNcXmCz4uCFNgCQwDZsA++WLyWjgMZ4eCO/x9oZAEX+XVxDoc6r5s 1JxZE6SOX1GoBrYhtgVjdZC3jPlE8lUK7Pm37yN2Sm8VPJ00OSF0AuoTHdydxbdZe42U Rbow== 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=yAF7UWnCIW8eC4sb2Q9LJLuzsBnDu9v8NUBR5omJgmY=; b=hrSNkC9Kbh7ki9ItrDnsAV8GsCBVmNVfpJzvlb+jqaccZIcWMq7SuGUlNtGXvAhQGY KjlDCHDWBeJIstj0JnzABKmci0YT0tEddKtwOZCDsf/6Iwh0IFWsO06cS2IkcUsEBTYY JjO2hlz5DdxOLC32cXRKtvq/Y6Erp816xtCBqBu+o1/fhEn0kgsi256s+t1S0PoWynH8 012z+Eo4zMFPvP8tN4ZNNmPvkr2lLhMONguNfxAZ7daIHafWUpqfdH3zDyecdtpeHpyp DuD47KIo1s0i6Y6tmBJdImwN8OZarBT6O8CzKagUujywVW00sEy2MobTy3vZEuvocPuB PxSQ== X-Gm-Message-State: APzg51Ch025qtADDV5vQ0aJvvwLnxxmHbW7p0NlmZEies+paSPsaos/L XXzjFTz64Wz6SjBqN21qm6OOdD9QQ0RyvVnGVii33w== X-Google-Smtp-Source: ANB0VdZcKne8Ia54gY8hXkQa2sHrKTnOPrMGQ9YfNE6UZlCRbCr6b0Jc79AiyVRa3DMrDa2+fHtsIEgr7dZKONhuYSQ= X-Received: by 2002:a2e:800e:: with SMTP id j14-v6mr8123839ljg.114.1535660002963; Thu, 30 Aug 2018 13:13:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:18e4:0:0:0:0:0 with HTTP; Thu, 30 Aug 2018 13:13:22 -0700 (PDT) In-Reply-To: <1620.1533584265@sss.pgh.pa.us> 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> From: Magnus Hagander Date: Thu, 30 Aug 2018 22:13:22 +0200 Message-ID: Subject: Re: Release note trimming: another modest proposal To: Tom Lane Cc: "Jonathan S. Katz" , pgsql-docs@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000f905750574acb489" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000f905750574acb489 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 6, 2018 at 9: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. > 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/ Work: https://www.redpill-linpro.com/ --000000000000f905750574acb489 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Aug 6, 2018 at 9:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wro= te:
"Jonathan S. Ka= tz" <jkatz@postgresql.org> writes:
>> On Aug 6, 2018, at 3:27 PM, Tom Lane <<= a href=3D"mailto:tgl@sss.pgh.pa.us">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.=C2=A0 Given, say, a b= ug 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 ta= rballs.
> 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 cur= rent
workflow can process.=C2=A0 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 conve= rsion
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.

The current process to load the docs is basic= ally "extract the HTML files from the tarballs". We run this agai= nst the tarballs of any "latest minor release".

So yes, as long as we are OK with only loading release notes the sa= me way we do docs, which is from tarballs, then I really don't think th= is part will be a problem, and we don't need to do anything about the o= ld 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 th= em out of the master branch, but the master branch is not used to load the = old docs, only the developer docs.

--
=C2=A0Magnus Hagander
=C2=A0Me: https://www.hagander.net/
=C2=A0Work: https://www.redpill-l= inpro.com/
--000000000000f905750574acb489--