* [gentoo-dev] Re: ChangeLogs and rsync time
@ 2006-01-01 22:43 99% ` Duncan
0 siblings, 0 replies; 1+ results
From: Duncan @ 2006-01-01 22:43 UTC (permalink / raw
To: gentoo-dev
Grobian posted <20060101214818.GB17018@gentoo.org>, 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
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2006-01-01 20:35 [gentoo-dev] ChangeLogs and rsync time Francesco Riosa
2006-01-01 21:48 ` Grobian
2006-01-01 22:43 99% ` [gentoo-dev] " Duncan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox