Re: Release note bloat is getting out of hand

On Mon, Feb 2, 2015 at 10:43 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> Yeah, the PDF size is definitely someting to consider in this context. And
>> the limits.
>
>> But if we can find some good way to "archive" or preserve them *outside the
>> main docs* that should solve this problem, no? We could keep them in SGML
>> even, but make sure they are not actually included in the build? Would
>> still be useful for developers there...
>
>> Or if we could find a way to do like Josh says - archive them separately
>> and publish a separate download. We could even keep it in a separate git
>> repo if we have to, with a "migrate" job to run on a major release?
>
> Yeah, seems like this and Josh's request could both be addressed fine
> with a separate document.
>
> I could live with keeping the ancient-branch release note SGML files
> around in HEAD --- I'd hoped to reduce the size of tarballs a bit, but the
> savings by that measure would only be a few percent (at present anyway).
> What's more important is to get them out of the main documentation build.
> So how about cutting the main doc build down to last-five-branches,
> and adding a non-default make target that produces a separate document
> consisting of (only) the complete release note history?

The last 5 branches only takes us back to 9.0, which isn't very far.
I would want to have at least the 8.x branches in the SGML build, and
maybe the 7.x branches as well. I would be happy to drop anything
pre-7.x from the docs build and just let the people who care look at
the SGML. You seem to be assuming that nobody spends much time
looking at the release notes for older branches, but that is certainly
false in my own case.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company