Grobian posted <[EMAIL PROTECTED]>, excerpted below, on Sun, 01 Jan 2006 22:48:18 +0100:
> On 01-01-2006 21:35:34 +0100, Francesco Riosa wrote with possible deletions: >> The information contained in the ChangeLogs is essential, and it must be >> kept, but, force the users to download all that data it's not optimal. >> >> That said I can see only two ways to reduce the ChangeLog files (a >> centralized one is obviously not viable) >> >> 1) bzip2 them in some way. >> 2) "rotate" Changelogs, keeping only the last changes, until a size > > or > 3) remove entries for non-existing ebuilds > 4) compress Changelog entries where possible > Often, a package is marked testing or stable on request via a bug. > This usually results in having as much as new Changelog entries as > there are arch teams involved. I'd say: * Remove keywording entries for ebuilds no longer in the tree. * Snip/rotate changelogs, but only manually, and where it makes sense, for the largest changelogs. For the largest, xorg, keep only from the earliest in-tree minor version, forward. Currently, we have 6.8.2-rX in the tree, so 6.8 forward, keeping older info available by CVS only. When the last 6.8 monolithic is removed, that will leave only 7.x modular, and that particular changelog won't grow so fast, as it'll be split into the component packages (the changelogs of which, unfortunately, will grow faster, when the effect is combined, due to entries in multiple changelogs that used too be just one). gcc and glibc are #2,3. They will be tougher, due to the number of versions retained in-tree. Still, keyword bump entry removal for ebuilds no longer in the tree will help some. * Standardize keyword bump entries. Single description, with optional bug number/reporter, followed by keywords in standardized (alpha?) order per entry. This will aid in compression, if decided upon, AND in automated removal of keywording entries upon ebuild removal. * Do /not/ remove other than keyword bump (only) entries for intermediate ebuilds, those no longer in the tree, but bracketed by versions still in the tree. Much of this data will remain valid and useful, as it will often continue to pertain to ebuilds still in-tree. An example would be the record of changes necessary to update an ebuild from one upstream versiion to the next, after a security bump to -rX. We would't want to lose the ebuild version change documentation just because revision zero was removed after the security bump. (Keywording entries for ebuilds no longer in-tree, however, aren't very useful, so they can be removed as suggested above.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
