From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1EtByT-0003mO-Vh for garchives@archives.gentoo.org; Sun, 01 Jan 2006 22:46:50 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k01MjokS025691; Sun, 1 Jan 2006 22:45:50 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k01MhlMv011380 for ; Sun, 1 Jan 2006 22:43:48 GMT Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by smtp.gentoo.org with esmtp (Exim 4.54) id 1EtBvX-0001Qc-Dr for gentoo-dev@lists.gentoo.org; Sun, 01 Jan 2006 22:43:47 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EtBvP-0005oH-R6 for gentoo-dev@gentoo.org; Sun, 01 Jan 2006 23:43:39 +0100 Received: from ip68-230-97-182.ph.ph.cox.net ([68.230.97.182]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Jan 2006 23:43:39 +0100 Received: from 1i5t5.duncan by ip68-230-97-182.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Jan 2006 23:43:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: ChangeLogs and rsync time Date: Sun, 01 Jan 2006 15:43:26 -0700 Organization: Organization? Only haphazardly. Message-ID: References: <43B83D16.6060803@gentoo.org> <20060101214818.GB17018@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-97-182.ph.ph.cox.net User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Sender: news X-Archives-Salt: 571c22bf-5b92-4add-a3f3-d9910a17ec68 X-Archives-Hash: fb674da84fc4ddef23c9b1c507d7077c 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