Re: Release note trimming: another modest proposal

On 2/4/19 11:12 AM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz(at)postgresql(dot)org> 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 doing this, but I would not
>> be able to do so in the above timeline. However, I should be able to review.
>
> Attached is a diff showing what I'm thinking about, for HEAD; each
> active back branch would get a similar change. I'd also "git rm"
> now-unreferenced files in relevant branches, but that'd just bulk up
> the diff so I've not shown it here.

Thanks on all accounts. I reviewed and its along the lines of what I was
thinking as well. The documentation in release.sgml on how to create
things is clear. I did not try applying the patch, but syntactically it
passes the eyeball test.

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

Yeah, that was one of my first thoughts as I reviewed the patch. It's
one of those "once-a-year" things that are easily forgotten (e.g. with
EOL warnings, which is why we updated a few things around that). But as
long as they're added to the process of wrapping for the release, it
does not sound like its a huge burden.

> Note that this would change our workflow for release notes a bit,
> in that real editing work would happen in the back branches, rather
> than them just getting copies of text from HEAD. I don't see a big
> problem there, but it's a bit different from how we've traditionally
> done things.

I guess one way to look at it: overhead of adding these additional
changes vs. overhead saved with build times + tarball size? Are the
extra X minutes of developer time worth it?

>
> 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 from 17MB to 12.2MB. I didn't try to
> measure the impact on tarball size, but it should be noticeable.

Wow, 28-29% reduction in the file sizes, and 20% reduction in build
time! Nice.

Jonathan