Re: Release note trimming: another modest proposal

2018-08-06 Thread Jonathan S. Katz
> 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

Re: Release note trimming: another modest proposal

2018-08-06 Thread Tom Lane
"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

Re: Release note trimming: another modest proposal

2018-08-06 Thread Jonathan S. Katz
> On Aug 6, 2018, at 3:27 PM, Tom Lane wrote: > > I wrote: >> Hm, so the only objection I can think of is that this results in the old >> release notes only being available on the website; there's no other way >> to access them, short of digging around in the git repo. But maybe that's >>

Re: Release note trimming: another modest proposal

2018-08-06 Thread Tom Lane
I wrote: > Hm, so the only objection I can think of is that this results in the old > release notes only being available on the website; there's no other way > to access them, short of digging around in the git repo. But maybe that's > enough. Actually, a concrete reason why that might not be

Re: Release note trimming: another modest proposal

2018-08-06 Thread Tom Lane
"Jonathan S. Katz" writes: > On Aug 6, 2018, at 2:05 PM, Jonathan S. Katz wrote: >> 1. Add to the “docload” script to segment out the release notes and store >> them in a separate table. Perform an “upsert” (i.e. check for an existing >> reference; if it’s there, update any content, otherwise

Re: Release note trimming: another modest proposal

2018-08-06 Thread Jonathan S. Katz
> On Aug 6, 2018, at 12:55 PM, Tom Lane wrote: > > "Jonathan S. Katz" writes: >> FWIW I’m thinking of something like: > >> `/docs/release-notes/release-X-Y(-Z)?.html` > >> and have them all live there. Of course the docs themselves would still >> have their copy of the release notes, but we

Re: Release note trimming: another modest proposal

2018-08-06 Thread Alvaro Herrera
On 2018-Aug-06, Tom Lane wrote: > OTOH, if we can easily set up a generic redirect rule like "if > https://www.postgresql.org/docs/*/static/release-*.html > doesn't exist, then redirect to > https://www.postgresql.org/docs/old-release-notes/static/release-*.html; > it might be worth doing. Yeah

Re: Release note trimming: another modest proposal

2018-08-06 Thread Tom Lane
"Jonathan S. Katz" writes: > Though thinking on this further, we’d probably want to maintain the URLs > that have been generated through the years so they don’t all 404 at once. > That would require having the appropriate URL rules written out either in > pgweb itself or at the web server level.