public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jonathan S. Katz <[email protected]>
To: Tom Lane <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: Magnus Hagander <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: [email protected]
Subject: Re: Release note trimming: another modest proposal
Date: Mon, 4 Feb 2019 11:26:59 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<CABUevEzX3dq-uUeMR0mSnCj4B6TK3v4QuQKKsf6Oz+ZdyRHMZg@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
On 2/4/19 11:12 AM, Tom Lane wrote:
> "Jonathan S. Katz" <[email protected]> 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
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
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], [email protected], [email protected], [email protected]
Subject: Re: Release note trimming: another modest proposal
In-Reply-To: <[email protected]>
* 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