public inbox for [email protected]
help / color / mirror / Atom feedFrom: Chris Travers <[email protected]>
To: Tom Lane <[email protected]>
Cc: [email protected]
Subject: Re: Release note trimming: another modest proposal
Date: Wed, 8 Aug 2018 21:53:42 +0700
Message-ID: <CAKt_ZfsDqo-yjYZbGFvuCfm7DPeqCyDFP5vvam125PzpzVr6yw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
On Mon, Aug 6, 2018, 05:57 Tom Lane <[email protected]> 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 everything, forever".
> The release notes are becoming an ever-larger fraction of the docs,
> and that's not good for documentation maintenance or for download
> bandwidth. As an example, looking at the US-letter PDF version of
> the v10 docs, as things stand today:
>
> Total page count: 3550
> Pages in release notes for 10.x: 41 (1%)
> Pages in release notes for older branches: 898 (25%)
> Pages in release notes for pre-9.2 branches: 546 (15%)
>
> I've not measured directly, but it's a reasonable assumption that if
> we dropped all the back-branch release notes the documentation build
> time would drop about 25%, whichever format you were building.
>
> I also live in fear of overrunning TeX's hard-wired limits, in the
> back branches that depend on a TeX-based PDF toolchain. We've hit
> those before and been able to work around them, but I wouldn't count
> on doing so again, and I sure don't want to discover that we have a
> problem of that sort the day before a release deadline. Trimming the
> release notes would definitely give us enough slack to not worry
> about that before all those branches are EOL.
>
> We've discussed trimming the release notes before, and people have
> objected on the grounds that they like being able to access ancient
> notes from time to time. I'm not unsympathetic to that issue, but
> does that access point need to be our daily working documentation?
>
> 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 next year.
> Working backwards, we'd drop 9.1 and before from v10, giving the 15%
> savings in page count that I showed above. A quick measurement says
> that would also trim the size of the v10 tarball by about 4%, which
> is not a lot maybe but it's noticeable across a lot of downloads.
>
> 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 git repo" doesn't seem like an adequate answer
> for that.
>
Works for me. Especially with a release note archive available somewhere.
>
> Thoughts?
>
> regards, tom lane
>
>
view thread (58+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Release note trimming: another modest proposal
In-Reply-To: <CAKt_ZfsDqo-yjYZbGFvuCfm7DPeqCyDFP5vvam125PzpzVr6yw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox