| 1 |
On 01-01-2006 21:35:34 +0100, Francesco Riosa wrote with possible deletions: |
| 2 |
> The information contained in the ChangeLogs is essential, and it must be |
| 3 |
> kept, but, force the users to download all that data it's not optimal. |
| 4 |
> |
| 5 |
> That said I can see only two ways to reduce the ChangeLog files (a |
| 6 |
> centralized one is obviously not viable) |
| 7 |
> |
| 8 |
> 1) bzip2 them in some way. |
| 9 |
> 2) "rotate" Changelogs, keeping only the last changes, until a size |
| 10 |
|
| 11 |
or |
| 12 |
3) remove entries for non-existing ebuilds |
| 13 |
This may, or may not be a good idea, but it is founded on the |
| 14 |
following observation: currently old or redundant ebuilds are removed |
| 15 |
from the tree. Once that happens, they don't show up in the rsync |
| 16 |
tree and are only available through the (centralised) CVS Attic. One |
| 17 |
can argue that Changelog entries for non-existing ebuilds are not of |
| 18 |
any use, since the files they refer to aren't present. |
| 19 |
This method would clean up the Changelog entries, in the same way |
| 20 |
ebuilds are removed, and CVS keeps the history around. |
| 21 |
4) compress Changelog entries where possible |
| 22 |
Often, a package is marked testing or stable on request via a bug. |
| 23 |
This usually results in having as much as new Changelog entries as |
| 24 |
there are arch teams involved. These kind of entries, that all more |
| 25 |
or less report 'Marked arch' could be merged into one, given that the |
| 26 |
information itself is Changelog-worthy anyway. (This is arguable |
| 27 |
IMHO.) |
| 28 |
This method may involve a lot of fuzzy matching to perform it |
| 29 |
automatically, with its related risks. The win for the large |
| 30 |
Changelog files is probably minimal. |
| 31 |
|
| 32 |
-- |
| 33 |
Fabian Groffen |
| 34 |
-- |
| 35 |
gentoo-dev@g.o mailing list |
Archives