Re: Release note trimming: another modest proposal

"Jonathan S. Katz" writes: > On 2/5/19 11:37 AM, Tom Lane wrote: >> 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. > The contrary point I will make is handling this via a different method.

Re: Release note trimming: another modest proposal

On 2/5/19 12:17 PM, Andres Freund wrote: > Hi, > > On 2019-02-05 12:10:57 -0500, Tom Lane wrote: >> Andres Freund writes: >>> On 2019-02-05 08:50:16 -0500, Jonathan S. Katz wrote: The original thought process was to _not_ do that given the effort, but if it's just for `/current/` it may

Re: Release note trimming: another modest proposal

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

Re: Release note trimming: another modest proposal

Andres Freund writes: > On 2019-02-05 12:24:00 -0500, Tom Lane wrote: >> Huh? The release note contents are identical cross-branch. >> I know, because I'm generally the one making them. > The point is that links in release-$version.html in /current/ or in a > magical new repo will likely contain

Re: Release note trimming: another modest proposal

Hi, On 2019-02-05 12:24:00 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2019-02-05 12:10:57 -0500, Tom Lane wrote: > >> For something like release-9-6-10.html, there's no value in having it > >> appear in three or four different places. You can't even argue that > >> the later branches

Re: Release note trimming: another modest proposal

Andres Freund writes: > On 2019-02-05 12:10:57 -0500, Tom Lane wrote: >> For something like release-9-6-10.html, there's no value in having it >> appear in three or four different places. You can't even argue that >> the later branches might be more up-to-date: that text is *the same*, >> modulo

Re: Release note trimming: another modest proposal

Hi, On 2019-02-05 12:10:57 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2019-02-05 08:50:16 -0500, Jonathan S. Katz wrote: > >> The original thought process was to _not_ do that given the effort, but > >> if it's just for `/current/` it may not be so bad. > > > I think it definitely sho

Re: Release note trimming: another modest proposal

Andres Freund writes: > On 2019-02-05 08:50:16 -0500, Jonathan S. Katz wrote: >> The original thought process was to _not_ do that given the effort, but >> if it's just for `/current/` it may not be so bad. > I think it definitely should also be on /devel/, that's what's out there > on blog posts

Re: Release note trimming: another modest proposal

On 2019-02-05 09:12:56 -0500, Tom Lane wrote: > Andres Freund writes: > > For the record: I think this is a terrible idea. Makes it much harder to > > figure out what changed when, and requires per-branch incantations to > > grep through the log. > > Uh ... "grep through the log"? The git log ou

Re: Release note trimming: another modest proposal

On 2019-02-05 08:50:16 -0500, Jonathan S. Katz wrote: > On 2/5/19 1:02 AM, Andres Freund wrote: > > Hi, > > > > On 2019-01-26 10:06:06 -0500, Tom Lane wrote: > >> "Jonathan S. Katz" writes: > >>> The one "caveat" I will bring up is that once pushed and applied to the > >>> site, we would bring in

Re: Release note trimming: another modest proposal

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

Re: Release note trimming: another modest proposal

"Jonathan S. Katz" writes: > On 2/5/19 9:12 AM, Tom Lane wrote: >> Anyway, if people want something resembling the old presentation, >> I think the way to get there is to have some sort of aggregate >> release notes in a separate place on the web site. We'd discussed >> that briefly upthread, but

Re: Release note trimming: another modest proposal

On 2/5/19 9:12 AM, Tom Lane wrote: > Anyway, if people want something resembling the old presentation, > I think the way to get there is to have some sort of aggregate > release notes in a separate place on the web site. We'd discussed > that briefly upthread, but no one's volunteered to push it

Re: Release note trimming: another modest proposal

Andres Freund writes: > For the record: I think this is a terrible idea. Makes it much harder to > figure out what changed when, and requires per-branch incantations to > grep through the log. Uh ... "grep through the log"? The git log output hasn't changed at all. I've personally never found t

Re: Release note trimming: another modest proposal

On 2/5/19 1:02 AM, Andres Freund wrote: > Hi, > > On 2019-01-26 10:06:06 -0500, Tom Lane wrote: >> "Jonathan S. Katz" writes: >>> The one "caveat" I will bring up is that once pushed and applied to the >>> site, we would bring introduce a lot of 404s into the website. >> >> Hm. In principle we c

Re: Release note trimming: another modest proposal

On 2019-Feb-04, Andres Freund wrote: > Gah, I'd skipped this thread, because I was OK, if not happy, about the > original modest proposal (trimming to supported versions). My fault. > > For the record: I think this is a terrible idea. +1 I don't like it either. The original idea of just removi

Re: Release note trimming: another modest proposal

Hi, On 2019-01-26 10:06:06 -0500, Tom Lane wrote: > "Jonathan S. Katz" writes: > > The one "caveat" I will bring up is that once pushed and applied to the > > site, we would bring introduce a lot of 404s into the website. > > Hm. In principle we could probably insert some redirects, but > I dou

Re: Release note trimming: another modest proposal

"Jonathan S. Katz" writes: > On 2/4/19 11:12 AM, Tom Lane wrote: >> Just for the record, this change causes the time to build HEAD's >> HTML documentation to drop from ~120 sec to ~95 sec for me; the >> size of the resulting html/ directory drops from 21MB to 15MB, >> while the PDF output goes fro

Re: Release note trimming: another modest proposal

On 2/4/19 5:23 PM, Tom Lane wrote: > "Jonathan S. Katz" writes: >> On 2/4/19 4:25 PM, Tom Lane wrote: >>> After a bit more thought, I'm inclined to propose that the policy be >>> that we *don't* update the surviving back branches for branch retirement. > >> ...so I guess in turn, we would not upd

Re: Release note trimming: another modest proposal

"Jonathan S. Katz" writes: > On 2/4/19 4:25 PM, Tom Lane wrote: >> After a bit more thought, I'm inclined to propose that the policy be >> that we *don't* update the surviving back branches for branch retirement. > ...so I guess in turn, we would not update back branches with newer > releases as

Re: Release note trimming: another modest proposal

On 2/4/19 4:25 PM, Tom Lane wrote: > "Jonathan S. Katz" writes: >> On 2/4/19 11:12 AM, Tom Lane wrote: >>> It's not quite clear to me what the policy would be for removing >>> back-branch links from this list when old versions drop out of support. >>> Should we go back and remove them in surviving

Re: Release note trimming: another modest proposal

"Jonathan S. Katz" writes: > On 2/4/19 11:12 AM, Tom Lane wrote: >> It's not quite clear to me what the policy would be for removing >> back-branch links from this list when old versions drop out of support. >> Should we go back and remove them in surviving back branches, or just >> change HEAD?

Re: Release note trimming: another modest proposal

On 2/4/19 11:12 AM, Tom Lane wrote: > "Jonathan S. Katz" writes: >> On 1/26/19 10:06 AM, Tom Lane wrote: >>> If I haven't heard objections, I'll see about making this happen >>> during the first week of Feb (after the CF closes, but before >>> it's time to do the February releases' notes). > >> T

Re: Release note trimming: another modest proposal

"Jonathan S. Katz" writes: > On 1/26/19 10:06 AM, Tom Lane wrote: >> If I haven't heard objections, I'll see about making this happen >> during the first week of Feb (after the CF closes, but before >> it's time to do the February releases' notes). > Thank you! I was hoping to take a crack at doi

Re: Release note trimming: another modest proposal

On 1/26/19 10:06 AM, Tom Lane wrote: > "Jonathan S. Katz" writes: >> The one "caveat" I will bring up is that once pushed and applied to the >> site, we would bring introduce a lot of 404s into the website. > > Hm. In principle we could probably insert some redirects, but > I doubt it's worth th

Re: Release note trimming: another modest proposal

"Jonathan S. Katz" writes: > The one "caveat" I will bring up is that once pushed and applied to the > site, we would bring introduce a lot of 404s into the website. Hm. In principle we could probably insert some redirects, but I doubt it's worth the trouble. If I haven't heard objections, I'll

Re: Release note trimming: another modest proposal

On 1/25/19 6:46 PM, Bruce Momjian wrote: > On Fri, Jan 25, 2019 at 06:41:20PM -0500, Tom Lane wrote: >> Bruce Momjian writes: >>> I assume this means we would only keep the current release notes in the >>> git tree too, e.g. 11.0, 11.1, 11.2, etc. >> >> Yeah, I'd imagine that each branch would hav

Re: Release note trimming: another modest proposal

On Fri, Jan 25, 2019 at 06:41:20PM -0500, Tom Lane wrote: > Bruce Momjian writes: > > I assume this means we would only keep the current release notes in the > > git tree too, e.g. 11.0, 11.1, 11.2, etc. > > Yeah, I'd imagine that each branch would have just its own release notes. > > I'm not su

Re: Release note trimming: another modest proposal

Bruce Momjian writes: > I assume this means we would only keep the current release notes in the > git tree too, e.g. 11.0, 11.1, 11.2, etc. Yeah, I'd imagine that each branch would have just its own release notes. I'm not sure whether to apply this policy retroactively to the supported back bran

Re: Release note trimming: another modest proposal

On Mon, Jan 7, 2019 at 09:18:29PM -0500, Jonathan Katz wrote: > So circling back on this, Peter's point makes a lot of sense. > > If you want to see release notes for other major versions, there would > be URLs to the other major versions, but that would be far less costly > than keeping the actu

Re: Release note trimming: another modest proposal

On 8/30/18 4:15 PM, Magnus Hagander wrote: > On Fri, Aug 10, 2018 at 1:38 AM, Peter Eisentraut > > wrote: > > On 06/08/2018 00:57, Tom Lane wrote: > > Anyway, I'd like to propose a compromise position that I don't think > > has been discussed b

Re: Release note trimming: another modest proposal

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 si

Re: Release note trimming: another modest proposal

On Fri, Aug 10, 2018 at 1:38 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 06/08/2018 00:57, Tom Lane wrote: > > Anyway, I'd like to propose a compromise position that I don't think > > has been discussed before: let's drop release notes for branches > > that were already EO

Re: Release note trimming: another modest proposal

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 t

Re: Release note trimming: another modest proposal

On Thu, Aug 9, 2018 at 07:45:08PM -0400, Tom Lane wrote: > Peter Eisentraut writes: > > On 06/08/2018 00:57, Tom Lane wrote: > >> Anyway, I'd like to propose a compromise position that I don't think > >> has been discussed before: let's drop release notes for branches > >> that were already EOL w

Re: Release note trimming: another modest proposal

Peter Eisentraut writes: > On 06/08/2018 00:57, Tom Lane wrote: >> Anyway, I'd like to propose a compromise position that I don't think >> has been discussed before: let's drop release notes for branches >> that were already EOL when a given branch was released. > Why not go further and just ship

Release note trimming: another modest proposal

On 06/08/2018 00:57, Tom Lane wrote: > Anyway, I'd like to propose a compromise position that I don't think > has been discussed before: let's drop release notes for branches > that were already EOL when a given branch was released. So for > example, 9.3 and before would go away from v12, due out

Re: Release note trimming: another modest proposal

Bruce Momjian writes: > Works for me, though, is there no interest in keeping the SGML files in > the git tree and just not building them as docs? Yeah, I thought about that alternative, but I'm not sure I see the percentage. It'd bloat the tarballs compared to removing them, and for what? Anot

Re: Release note trimming: another modest proposal

On Wed, Aug 8, 2018 at 09:53:42PM +0700, Chris Travers wrote: > It seems to me that this would still provide enough historical > info for just about any ordinary interest.  We could discuss ways > of making a complete release-note archive available somewhere, > if "go dig in the gi

Re: Release note trimming: another modest proposal

On Mon, Aug 6, 2018, 05:57 Tom Lane wrote: > We've been around on this before, I know, but I got annoyed about it > again while waiting around for test builds of the back-branch > documentation. I think that we need some policy about maintaining > back-branch release notes that's not "keep every

Re: Release note trimming: another modest proposal

On Mon, Aug 06, 2018 at 08:14:23AM +0100, Dean Rasheed wrote: > On 5 August 2018 at 23:57, Tom Lane wrote: >> Anyway, I'd like to propose a compromise position that I don't think >> has been discussed before: let's drop release notes for branches >> that were already EOL when a given branch was re

Re: Release note trimming: another modest proposal

> 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 ac

Re: Release note trimming: another modest proposal

"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 t

Re: Release note trimming: another modest proposal

> 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 >> enoug

Re: Release note trimming: another modest proposal

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 goo

Re: Release note trimming: another modest proposal

"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 ins

Re: Release note trimming: another modest proposal

> 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 c

Re: Release note trimming: another modest proposal

"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 could at least have a single > repository of all the releases,

Re: Release note trimming: another modest proposal

> On Aug 6, 2018, at 11:47 AM, Tom Lane wrote: > > "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 o

Re: Release note trimming: another modest proposal

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

"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.

Re: Release note trimming: another modest proposal

> On Aug 6, 2018, at 11:09 AM, Tom Lane wrote: > > "Jonathan S. Katz" writes: >>> On Aug 5, 2018, at 6:57 PM, Tom Lane wrote: >>> ... We could discuss ways >>> of making a complete release-note archive available somewhere, >>> if "go dig in the git repo" doesn't seem like an adequate answer >

Re: Release note trimming: another modest proposal

"Jonathan S. Katz" writes: >> On Aug 5, 2018, at 6:57 PM, Tom Lane wrote: >> ... We could discuss ways >> of making a complete release-note archive available somewhere, >> if "go dig in the git repo" doesn't seem like an adequate answer >> for that. > Why not www.postgresql.org

Re: Release note trimming: another modest proposal

> On Aug 5, 2018, at 6:57 PM, Tom Lane wrote: > > We've been around on this before, I know, but I got annoyed about it > again while waiting around for test builds of the back-branch > documentation. I think that we need some policy about maintaining > back-branch release notes that's not "keep

Re: Release note trimming: another modest proposal

On 5 August 2018 at 23:57, Tom Lane wrote: > Anyway, I'd like to propose a compromise position that I don't think > has been discussed before: let's drop release notes for branches > that were already EOL when a given branch was released. WFM. +1 Regards, Dean

Release note trimming: another modest proposal

We've been around on this before, I know, but I got annoyed about it again while waiting around for test builds of the back-branch documentation. I think that we need some policy about maintaining back-branch release notes that's not "keep everything, forever". The release notes are becoming an ev