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