Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gr4r5-0003zr-Ay for pgsql-docs@arkaria.postgresql.org; Tue, 05 Feb 2019 17:49:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gr4r3-0001FU-Vw for pgsql-docs@arkaria.postgresql.org; Tue, 05 Feb 2019 17:49:53 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gr4r3-0001EN-MG for pgsql-docs@lists.postgresql.org; Tue, 05 Feb 2019 17:49:53 +0000 Received: from meldrar.postgresql.org ([2a02:c0:301:0:ffff::31]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gr4r0-00029V-KY for pgsql-docs@lists.postgresql.org; Tue, 05 Feb 2019 17:49:52 +0000 Received: from [63.118.15.50] (helo=Ph33r-Retina.local) by meldrar.postgresql.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gr4qx-0007EU-1J; Tue, 05 Feb 2019 17:49:49 +0000 Subject: Re: Release note trimming: another modest proposal To: Tom Lane Cc: Andres Freund , Bruce Momjian , Magnus Hagander , Peter Eisentraut , pgsql-docs@lists.postgresql.org References: <19252.1533509841@sss.pgh.pa.us> <20190125233111.GE13803@momjian.us> <16080.1548459680@sss.pgh.pa.us> <20190125234614.GH13803@momjian.us> <8fd2ae88-49de-26f3-def3-e4381cb7e774@postgresql.org> <21920.1548515166@sss.pgh.pa.us> <20190205060201.jo3ejddklqxb5a4q@alap3.anarazel.de> <18071.1549375976@sss.pgh.pa.us> <20245.1549378532@sss.pgh.pa.us> <7963.1549384679@sss.pgh.pa.us> From: "Jonathan S. Katz" Openpgp: preference=signencrypt Autocrypt: addr=jkatz@postgresql.org; keydata= mQINBFtShwABEAC7PNHDUOTYuifpUCk23KqfxdQQkn4nkoxOXRK0+rAj36FiwqGB4TJFuOVZ sDFAEiSlC8Jt4y5Cs7B5tetT8JNd2cs6zp/udMJJDz9d65O9PDpdlMgAmIiTzpLlSdx8FG56 DTksaDv1d8j3cTJPSE4/fWSxqzA7o3Y9UuL7atZPrzfImgpRKs0of7elIHwOa8GucjyhYqcR h60wFBJc2KXqQdDYRTZy43DSnY/0VNc0omiH355fustvpm+m5HjD3w7qZyfN3fpKJpnX1LCF f3MnPHaDGITIYGRCBXvf0UqUtD6OEVWPv2C2gyqWMIpWmZTOgDufltKyIByKBoS9x0PlFkij 04X3KODCngt+N8Ssc9OICc6QSxhjoP48PYPdmiTmkrGuf0LX084wj1xeo1NX7XxZK39F6dTJ DhsIiW0sNS0xMxQHLHG9VLbPjx3SANQBh6BuryPz5ZupW9/TIDmkvprtU/oXfKgtfYm3fxmk EctxbWrEPsFTFPyuMqQu6l+xyQv0s1VLZfjNWaua6H1/gGoIt6kRnn5qMXDVVpijuWkHbv7G ngaQMd258UrrOEHnnjzhQ7jxMWV9D+emxbAtlIxnYvCWlV4IwAQhEHfvudqYaIY3hNWrvQ6H GB2KXoTZYN9g5djm14/5nj1IU5zOcovkjJnKhoo9iStnpFF2cwARAQABtCdKb25hdGhhbiBT LiBLYXR6IDxqa2F0ekBwb3N0Z3Jlc3FsLm9yZz6JAlQEEwEIAD4CGwMFCQeGH4AFCwkIBwIG FQoJCAsCBBYCAwECHgECF4AWIQT6hLaVryv3miBkP/HxBJxynxxlJwUCW1KJJQAKCRDxBJxy nxxlJwjrD/kBgqsW4QpNpTFw7ifRokZV08CCX4huPBJQ91rrv+UEWlEcotFBHVkYyHnpzARl tcZxhJ9CbFxjniH9cOTty5T/O1yolbOHtZSW8Z8aWV6BVEbjMb+BFxSSLm7RnvJdzQbGCZq2 ZZvfVpB6z3EHYph4KDdVKvMFjoLskxmdS1DE0tE3zTxvoQsi24Q+HOS07kUjs6fsu/WICMfz mgO++AWG9Y0CvN0mm4TkujESzyKM9E5irD+leEMIcddl51Aa2c/VMfBXQbRmpHIgUFTmuHQD CnQih+9i3OJAksDg66SP8a7yiXv5mwvyDi1EfTGVKYR2j+pwyjwnC3oIbvDMmB3uTn2JIjnT iZKPVtAcAylXjubFltihQgNyuShdP4W+kBwZizhUFqUVL8Anx+KoytYmJPfMRFLGuK4obXKq a2ZS3k9KB+H+isOx2nFJOsc7V360Zp1DVaNmuiK10TT6QndShSPaqkJqFtCb6r92rZ9sZM/L 3vtCI4Rrl3Pt1MgtENXupS8gZpJnAYS0j5A1PAZ09r6ANoaeMHspF+5J5fOHeEvqphXr36mm a83Vl1t4orPb0+QmmijmlpseDU63M88Aw5p3c4qj7t8Qr2EZ5zrn7/sFn5wOfbs8Nymxafif QCnlV2vg9p0m7vSk/yLJ4PFZvs52FgqAGRCdRn0s2EC99bkCDQRbUocAARAAv8ho/toQ9DG3 j4f9h9n1aRHr2FlviN2Utpy6L8+dfDggO0geilmkGQOolZ2E60gGfye/kUtF9W3NByO4hxDR 9u6qbOXcdqnuA+cc68EfqlWFJrVtYFxt0h4ElWYOYnIezKthriWch/FY70FGrxs3z8UHOHq5 0wBW433eTvZm90WixBiXEt2v1DgW4Vr3ymfO7Aap/IYyPuE4JzgudAuAl0HKPyNEHWHG1dAb jX1RiCw9gknIDWQOF0B4UAaJctWGVcnZ3A2ULwNGMa1P9ZJlBWf1vcj01aiHMU0yQ7JjJiSp vfm9eM0uSLwRdDrJjyl5ZZqVumjdv2SMNQ8GvYRbEMys3GGDSt9zXgfCSUnPnJfYxjzBHRI6 x44Wfsx8S6hWxepOogCJJ/g67Bk9mY8YV4klWIXDJVOL5jnBC09DbsZG81JaE2QxB8Y7W36Z Mroi9XMxg3s805hQAQUvdG/poU8hN8BWdrnTm/+4eQQp7gDY1ePDmGM6bJC+OHOSnFtR/f+7 0zpKJ10cc7cBygGnl1yR3KjhFyAWUFvP4ZGziKCcpMwXZfe9PGuyA/YOubMphxIn3YsK2wrd faKZYX2GMZCZhMMcvx9IpQrxIJgU+VlwXu/O+Lk10VIPcxPJJwmpdI6HzcS8ZgG6IMcC444X XTuLaP8j2mgcMvYak3ScCykAEQEAAYkCPAQYAQgAJhYhBPqEtpWvK/eaIGQ/8fEEnHKfHGUn BQJbUocAAhsMBQkHhh+AAAoJEPEEnHKfHGUnReMP/RA2UhGQj+G4uBshkRLjpRysabdPqgQB dEBk6wYbio88Wg/2/hgY7UzmDDEwX3sZfQDcrI6+vIobI8uqstZID+WgAAa1JLfChMyVQnSy 0zfWMOABXscc5tGuvFRZvJklTissMFjXUwaREEKp4ZikTvJ/62MCjSdtrUhnPLvoTsHTKRKD ichE+b5A54alwsubTijw12O6N22r5IjZiiSZV0u7dsShyKw+7wCSax9fuBoE43NMYf+dnjMK nerAQYUcZWYMnk+EC8RaqYAxv6XZ2tKx1AkGGktwkQIBwrz9IlDSvJ3LWJ2UIIuLRTdngNgg GIL4zzuUa2F56FqskQIuYMaNETk6LYfalBDQ6TVLAcgCPQxp4k4i/PRsZ3lZ2ZhRHRYciOvm kp+I6EfHwllQpYrWs1thluBGqlJSVJgKl0IOFvKLsQ6KKfqzAwh6FxrO5qajp4viNIgtWoFw O5Bp0jgFTbH2OrMWIRfUdUCH1Djbuo65svhNj7FNsQVYzHDI+Nd1I/LOBoPc3UorRMF2M4JV kUR7skOHWUbPTSNUr7qc14NSMY3PKjGeVGAsBVHBPvmRx/Ss2tW/TpJWpxg4pmquFQSXuaYh Yf4FN8Sxy320pcr+FqN8AhZkYJcNY82OTtR5VEKRC/mYcyq61qXIKqngydn79bJjGxHipxyF FmEC Message-ID: Date: Tue, 5 Feb 2019 12:49:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <7963.1549384679@sss.pgh.pa.us> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oWtUYWfgaz51tzjCUYlN9GLzEQoVjvXsl" X-Host-Lookup-Failed: Reverse DNS lookup failed for 63.118.15.50 (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oWtUYWfgaz51tzjCUYlN9GLzEQoVjvXsl Content-Type: multipart/mixed; boundary="VFp8JoQM5Uj5mgjjUabwqk2OC4VveZ2VL"; protected-headers="v1" From: "Jonathan S. Katz" To: Tom Lane Cc: Andres Freund , Bruce Momjian , Magnus Hagander , Peter Eisentraut , pgsql-docs@lists.postgresql.org Message-ID: Subject: Re: Release note trimming: another modest proposal References: <19252.1533509841@sss.pgh.pa.us> <20190125233111.GE13803@momjian.us> <16080.1548459680@sss.pgh.pa.us> <20190125234614.GH13803@momjian.us> <8fd2ae88-49de-26f3-def3-e4381cb7e774@postgresql.org> <21920.1548515166@sss.pgh.pa.us> <20190205060201.jo3ejddklqxb5a4q@alap3.anarazel.de> <18071.1549375976@sss.pgh.pa.us> <20245.1549378532@sss.pgh.pa.us> <7963.1549384679@sss.pgh.pa.us> In-Reply-To: <7963.1549384679@sss.pgh.pa.us> --VFp8JoQM5Uj5mgjjUabwqk2OC4VveZ2VL Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2/5/19 11:37 AM, Tom Lane wrote: > I wrote: >> BTW, while we're thinking about this --- I remembered that as things >> stand, we've broken my historical practice of putting up first-draft >> minor release notes for people to look at if they choose. Those will >> now be in the newest back branch, which we don't have an automatic >> build-and-post pipeline for, AFAIK. Now, maybe the people who would >> review those notes are all comfortable with looking at the git >> commitdiff anyway. But somebody who preferred to wait for the next >> guaibasaurus run and then look at the website is now out of luck. >> Would it be possible to drive this aggregation off the git copies >> of release-NN.sgml (from appropriate branches) instead of the last >> released versions? Or set up something equivalent to the devel >> notes pipeline for back branches? >=20 > After further thought about that, I'm liking the idea that was > discussed upthread of setting up a separate git repo for the > aggregate release notes. It'd have a simple(?) Makefile with > the only build product being the aggregate release notes as > HTML (maybe PDF too). The constituent files would be copies > of the release-NN.sgml files from the master code repo. There'd > be no particular need for multiple branches in this repo, it'd > just be latest data all the time. >=20 > The main drawback of this approach is the need to copy the > release-NN.sgml files from the master code repo. This is where I had a slight moment of panic especially regarding the release process. Yes, it's not often -- it's an extra step, but perhaps in the end it saves a lot of headaches and allows us to cover the below. > But since > we'd only touch it four or five times a year, that doesn't > seem like unacceptable overhead to me. The benefits are: >=20 > * It's not so hard to cope with the fact that the various > branches don't all use the same docs toolchain. We'd just > agree that the release notes repo uses the current toolchain, > and when transferring over old release notes, they'd have to > be edited as necessary to make them build. >=20 > * The web site could be set up to build-and-publish from this > repo automatically, more or less like the devel docs are published > from the master code repo automatically. That'd fix the problem > I worry about above: drafts could be published by shoving them into > the release note repo ahead of official release. The original pgweb patch I wrote sort-of handled this: it basically looked for release notes within the core repo, found ones that it did not already have, and stuffed them into a table. It should not be difficult to repurpose that code to load them in from a separate repo, and perform that similar parsing. > (Contrariwise, if we had say a security-related update we did > *not* want to be visible immediately, we'd just delay transferring > that to the release note repo.) I don't see this as an insurmountable issue. The contrary point I will make is handling this via a different method. I believe one of the things Magnus objected to in the original patch upthread (or in a private conversation) was that we were double-storing the release note data in the patch I proposed. My way around that was going to perform some careful scripting, i.e: - Find the version of PostgreSQL from newest to oldest - Find the associated release notes from newest to oldest - Make available on the site Which all should be doable from the current data we store. The advantage is that allows us to leave everything as is when displaying release notes on the site. (which if we end up going this way, I'm happy to work on this) >=20 > I'd be willing to do most of the legwork in populating this repo, > if someone else were to handle the website plumbing. If we go down the new path, I would be happy to do the website work, it will require Magnus sign-off if there is a schema change. Thanks, Jonathan --VFp8JoQM5Uj5mgjjUabwqk2OC4VveZ2VL-- --oWtUYWfgaz51tzjCUYlN9GLzEQoVjvXsl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE+oS2la8r95ogZD/x8QSccp8cZScFAlxZzLcACgkQ8QSccp8c ZSfkvw//UqFJboOg5rlOpFPnv/UTG2Y1q6OE5LpsJQkcuQ/MRiASEgVONO/n8uFN Tqc57CG3A4uKduhsBea8BZmuHTVYbu9M4MVVhalXeAXmVHHlFYX3FDOWH2JdYnDR B/D8GZN8+iwxYgLmY9qJOlt6Hu2ATNpYMc71TyOZfpxDqFaMTRDhHlo0xabSd7qE N64mntRL6+KKSn2tqIwG3MpswPdZHosN3i2hZ+G1OJkGADemMeBNt2j3IWc0YWYR VJGpv9d82b2DiFukbipWbU2VD9f2j75abRYQ5b2HWPkalnFBVGLwGPNVpGj6yXW7 v6mSkDS2WFXUlU4Y0jSLP0bfmgaMyITFSV6BOvcjXFyJC3UB9GdE6CrTJ/Q/lQKD QRAvrs1LXhJ1UFL63GJfniP56iswQMvKi3CghKwLQ7wpWBRs/873EmF98Vfasbon m8JzScHYpaZtAzMLbwKGZPFk53ahuRg/QzwpzCZUHRlTZrYz0eXlkojMuHNQ365m 1OOioZTOR931SQBBdLqN+yp4/F6Q8z5oshn4zwDMr7PdR1EJEYqOp0tfpM02+bNJ IjWFslMGSRnOOZmlzW0ppseg9NnTLC+MuoibrryplkmgTEh5BfUebCPfZc1jyA/5 LYLMATDSOT8c8U6epCZYV26DEaw54DC4EPs3fC5ZtrTyWMNhVzU= =Su73 -----END PGP SIGNATURE----- --oWtUYWfgaz51tzjCUYlN9GLzEQoVjvXsl--