Re: [gentoo-dev] Rotating oversized ChangeLog files
Sounds good. So, we have a spec... and the portage team has two months to get it into emerge --changelog. :) For whoever is interested, I've just filed a portage feature request in bug 389611. https://bugs.gentoo.org/show_bug.cgi?id=389611 Please support rotated ChangeLog files in emerge --changelog -- Andreas K. Huettel (dilfridge) Gentoo Linux developer kde, sci, arm, tex
Re: [gentoo-dev] Rotating oversized ChangeLog files (was: Old changelogs / eclass dir)
On Thu, 3 Nov 2011 01:33:38 +0100 Andreas K. Huettel dilfri...@gentoo.org wrote: Dear all, 2) I'd like to suggest that for changelogs that grow beyond a certain size (e.g. profiles/ChangeLog) the file is rotated similar to /var/log logfiles. I.e. the current file is renamed with a date extension and a new file is started. This has the benefit that the archived file is static and will never be retransmitted by rsync. to prevent that this becomes a victim of general ChangeLog bikeshedding (we must rotate at a logical point, how could it be automatized even if it is relevant for only a few files, then how do we prevent epmty files...) I suggest the following procedure: In a week's time I personally, manually, will rotate all ChangeLog files larger than 100k in the tree, by splitting them at 31/12/2010-1/1/2011. The old entries file will in each case be named ChangeLog-2010 in the same directory. (PMS: A package directory may contain other files or directories, whose purpose is not covered by this specification.) Maybe we should keep old changelogs in a separate directory to decrease ebuilddir pollution? The new ChangeLog file will be identical to the current ChangeLog file except for being truncated at 1/1/2011. Maybe it'd be a good idea to add some kind of footer saying 'for further entries, please inquiry ChangeLog-2010 file'. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Rotating oversized ChangeLog files
On Thu, 3 Nov 2011, Andreas K Huettel wrote: The old entries file ChangeLog-2010 will be identical to the current ChangeLog file except for skipping at the start all entries added later than 31/12/2010. Just to make sure that I understand it: Does this imply that the old entries file will have a proper header? 774821 profiles/ChangeLog Maybe you could split this one on a yearly basis, to keep the chunks close to 100 kB? Ulrich
Re: [gentoo-dev] Rotating oversized ChangeLog files
On 11/03/2011 01:33 AM, Andreas K. Huettel wrote: In a week's time I personally, manually, will rotate all ChangeLog files larger than 100k in the tree, by splitting them at 31/12/2010-1/1/2011. Opinions, flames, ...? opinion Again for 'emerge --changelog': As we do have the $delay before breaking old period, usually with $delay=1 year: Should we also apply this $delay to the output of above command? If yes, what I can think of ATM is: * Do that first splitting in January 2012 (in less than 2 months). * Have PM search in the old ChangeLogs if necessary. The latter would also allow for completely emptying current ChangeLog each January by moving that to ChangeLog-$lastyear. /opinion /haubi/
Re: [gentoo-dev] Rotating oversized ChangeLog files
On Donnerstag 03 November 2011 09:24:07 Ulrich Mueller wrote: On Thu, 3 Nov 2011, Andreas K Huettel wrote: The old entries file ChangeLog-2010 will be identical to the current ChangeLog file except for skipping at the start all entries added later than 31/12/2010. Just to make sure that I understand it: Does this imply that the old entries file will have a proper header? Yes. 774821 profiles/ChangeLog Maybe you could split this one on a yearly basis, to keep the chunks close to 100 kB? Makes sense, yes. (With the earliest splitting when the file exceeds 100k for the first time.) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Rotating oversized ChangeLog files
On Donnerstag 03 November 2011 10:16:53 Michael Haubenwallner wrote: Again for 'emerge --changelog': As we do have the $delay before breaking old period, usually with $delay=1 year: Should we also apply this $delay to the output of above command? If yes, what I can think of ATM is: * Do that first splitting in January 2012 (in less than 2 months). * Have PM search in the old ChangeLogs if necessary. The latter would also allow for completely emptying current ChangeLog each January by moving that to ChangeLog-$lastyear. Makes all perfect sense... however I suggest to agree on a general scheme and go ahead manually first if implementation and/or discussion of its details or planned features is lingering... As opposed to EAPI features, this here is one of the cases where availability of an implementation means I'm here and can do it quickly. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Rotating oversized ChangeLog files (was: Old changelogs / eclass dir)
On Donnerstag 03 November 2011 09:09:19 Michał Górny wrote: Maybe we should keep old changelogs in a separate directory to decrease ebuilddir pollution? Not sure about that. The new ChangeLog file will be identical to the current ChangeLog file except for being truncated at 1/1/2011. Maybe it'd be a good idea to add some kind of footer saying 'for further entries, please inquiry ChangeLog-2010 file'. Yes, makes sense and is easily done. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Rotating oversized ChangeLog files
On Thu, 3 Nov 2011, Andreas K Huettel wrote: On Donnerstag 03 November 2011 10:16:53 Michael Haubenwallner wrote: As we do have the $delay before breaking old period, usually with $delay=1 year: Should we also apply this $delay to the output of above command? Makes all perfect sense... however I suggest to agree on a general scheme and go ahead manually first if implementation and/or discussion of its details or planned features is lingering... How about this: - Possible split points are only at the end of years. - Start at the end of the file and go backwards. - Split it whenever the piece after the split point is larger than $size. - Stop if the next split point is less than $delay ago. Reasonable values are 50 or 100 KiB for $size and 1 year for $delay, IMHO. ulrich
Re: [gentoo-dev] Rotating oversized ChangeLog files (was: Old changelogs / eclass dir)
On Nov 3, 2011 10:25 a.m., Andreas K. Huettel dilfri...@gentoo.org
wrote:
On Donnerstag 03 November 2011 09:09:19 Michał Górny wrote:
Maybe we should keep old changelogs in a separate directory to decrease
ebuilddir pollution?
Not sure about that.
Thank you for this infusion of practicality.
How about in ${FILESDIR} ?
Re: [gentoo-dev] Rotating oversized ChangeLog files
On Donnerstag 03 November 2011 11:59:55 Ulrich Mueller wrote: On Thu, 3 Nov 2011, Andreas K Huettel wrote: On Donnerstag 03 November 2011 10:16:53 Michael Haubenwallner wrote: As we do have the $delay before breaking old period, usually with $delay=1 year: Should we also apply this $delay to the output of above command? Makes all perfect sense... however I suggest to agree on a general scheme and go ahead manually first if implementation and/or discussion of its details or planned features is lingering... How about this: - Possible split points are only at the end of years. - Start at the end of the file and go backwards. - Split it whenever the piece after the split point is larger than $size. - Stop if the next split point is less than $delay ago. Reasonable values are 50 or 100 KiB for $size and 1 year for $delay, IMHO. Sounds good. So, we have a spec... and the portage team has two months to get it into emerge --changelog. :) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Rotating oversized ChangeLog files
On 11/02/2011 08:33 PM, Andreas K. Huettel wrote: I currently count 19 relevant files. If we keep the 100k limit and rotate yearly, this will be doable by hand in the foreseeable future and any attempt at automating is a complete waste of time. Opinions, flames, ...? Just an observation: I think www-client/chromium has the fastest growing ebuild changelog at 50-60k per year. That's a lot of version bumps! signature.asc Description: OpenPGP digital signature
