Re: Release note bloat is getting out of hand

On Mon, Feb 2, 2015 at 3:44 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Sun, Feb 1, 2015 at 11:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> I propose that we go over to a policy of keeping in HEAD only release
> >> notes for actively maintained branches, and that each back branch should
> >> retain notes only for branches that were actively maintained when it
> split
> >> off from HEAD. This would keep about five years worth of history in
> >> Appendix E, which should be a roughly stable amount of text.
>
> > -1. I find it very useful to be able to go back through all the
> > release notes using grep, and have done so on multiple occasions. It
> > sounds like this policy would make that harder, and I don't see what
> > we get out of of it. It doesn't bother me that the SGML documentation
> > of the release notes is big; disk space is cheap.
>
> Disk space isn't the only consideration here; if it were I'd not be
> concerned about this. Processing time is an issue, and so is distribution
> size, and so is the length of the manual if someone decides to print it
> on dead trees. I also live in fear of the day that we hit some hard-to-
> change internal limit in TeX.
>

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?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/