From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: ChangeLogs and rsync time
Date: Sun, 01 Jan 2006 15:43:26 -0700 [thread overview]
Message-ID: <pan.2006.01.01.22.43.26.13849@cox.net> (raw)
In-Reply-To: 20060101214818.GB17018@gentoo.org
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
next prev parent reply other threads:[~2006-01-01 22:46 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-01 20:35 [gentoo-dev] ChangeLogs and rsync time Francesco Riosa
2006-01-01 21:48 ` Grobian
2006-01-01 22:43 ` Duncan [this message]
2006-01-02 9:26 ` Francesco Riosa
2006-01-04 9:22 ` Brian Harring
2006-01-01 22:55 ` Ciaran McCreesh
2006-01-01 23:50 ` Andrej Kacian
2006-01-02 9:37 ` Francesco Riosa
2006-01-02 10:44 ` Paweł Madej
2006-01-02 15:00 ` Matti Bickel
2006-01-02 16:37 ` Francesco Riosa
2006-01-02 16:45 ` Matti Bickel
2006-01-02 16:47 ` Henrik Brix Andersen
2006-01-02 17:25 ` Lance Albertson
2006-01-02 18:40 ` Chris Gianelloni
2006-01-02 19:20 ` Lance Albertson
2006-01-02 23:08 ` Paweł Madej
2006-01-03 5:28 ` Donnie Berkholz
2006-01-03 11:47 ` Chris Gianelloni
2006-01-03 12:18 ` Re[2]: " Jakub Moc
2006-01-03 14:29 ` Paweł Madej
2006-01-03 14:35 ` Mike Frysinger
2006-01-02 23:47 ` Francesco Riosa
2006-01-01 22:59 ` Andrej Kacian
2006-01-02 9:12 ` Francesco Riosa
2006-01-02 21:35 ` Peter Volkov (pva)
2006-01-03 11:50 ` Chris Gianelloni
2006-01-03 17:56 ` Francesco Riosa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pan.2006.01.01.22.43.26.13849@cox.net \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox