Re: When to drop/split/summ changelog files
Re: Bill Allombert 2006-03-28 [EMAIL PROTECTED] Please always keep the full Debian changelog information in the package. Of course, you can move very old changelog entry to changelog.old or changelog.1 if they cause problems, but ship them in the deb. Please don't even do that, the changelog is meant to be machine-readable, and unless there is a standard for how to access the full changelog, don't move it away. And even for humans, less changelog is a easier than less changelog changelog.old etc. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: When to drop/split/summ changelog files
Nico Golde [EMAIL PROTECTED] writes: Yes for sure, but useless zipped information is useless anyway. And you know it's useless how? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When to drop/split/summ changelog files
On Sunday 26 March 2006 20:18, Nico Golde wrote: Hi, what would be the appropriate way to handle large and old debian changelog files. Rather arbitrarily, just feels more or less safe: cut everything from before oldstable release. Based on the assumption that oldstable - stable updates occur more or less over the whole stable+1 development circle. So currently, I'd cut everything that pre-dates woody release - probably nobody will do a potato - woody upgrade. But woody is still quite a bit in use, and so those people could track the changelog without looking at multiple versions even if they do partial upgrades and their system spans woody to sid. (Obviously some person will have a system spanning potato to sid and miss the most relevant entry. So never cutting changelogs is another very obvious possibility) cheers -- vbi -- Man kommt in der Ehe am besten aus, wenn man nicht liebt; sowie am besten, wenn man bloß liebt. -- Jean Paul pgpTNKR4SCMBi.pgp Description: PGP signature
Re: When to drop/split/summ changelog files
On Mon, Mar 27, 2006 at 08:13:24PM +0200, Adrian von Bidder wrote: Rather arbitrarily, just feels more or less safe: cut everything from before oldstable release. Based on the assumption that oldstable - stable updates occur more or less over the whole stable+1 development circle. So currently, I'd cut everything that pre-dates woody release - probably nobody will do a potato - woody upgrade. I think one should keep the whole changelog. Most of them won't be really big anyway, and take a neglectable amount of diskspace. It can be relevant for other reasons that seeing differences between two certain versions: To see why (or that) a certain change was made, perhaps in response to which bug. This is what I use changelogs for mostly, only in a small minority of cases I really want to know when a certain change was made (and even then, it matter whether you can confirm the change was made $long_ago, or perhaps just not documented and might be made unmentioned later on). I don't see why one would drop such historical information, even if only interesting for just that -- historical information. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When to drop/split/summ changelog files
On Mon, Mar 27, 2006 at 08:13:24PM +0200, Adrian von Bidder wrote: On Sunday 26 March 2006 20:18, Nico Golde wrote: Hi, what would be the appropriate way to handle large and old debian changelog files. Rather arbitrarily, just feels more or less safe: cut everything from before oldstable release. Based on the assumption that oldstable - stable updates occur more or less over the whole stable+1 development circle. So currently, I'd cut everything that pre-dates woody release - probably nobody will do a potato - woody upgrade. But woody is still quite a bit in use, and so those people could track the changelog without looking at multiple versions even if they do partial upgrades and their system spans woody to sid. (Obviously some person will have a system spanning potato to sid and miss the most relevant entry. So never cutting changelogs is another very obvious possibility) Please always keep the full Debian changelog information in the package. Of course, you can move very old changelog entry to changelog.old or changelog.1 if they cause problems, but ship them in the deb. When renaming a package try to migrate the old changelog to the new one to preserve it. In a large part, changelogs are the history books of Debian. We can learn about what was Debian in the past by reading the changelog. apt and dpkg changelog are very interesting reading. I know it is very useful to me to have the changelog of menu from 1996 on. The changelogs are a legacy we own to the future Debian developers. Thanks for considering, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
When to drop/split/summ changelog files
Hi, what would be the appropriate way to handle large and old debian changelog files. I mean there are package with very active upstream and years old changelog which grew and grew over the years. Is there a way to handle these changelog entries which bloat the package and contain only information which are too old to be useful or is it ok if for example a changelog file would grow more than the source files of the package? May split the changelog and insert an entry which points to http://packages.debian.org/changelogs/pool/main//olderpackage_version-revision/changelog.html where oldpackage_version-revision includes all information which is older than split date. Regards Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org Forget about that mouse with 3/4/5 buttons - gimme a keyboard with 103/104/105 keys! pgp3SoHEr6h12.pgp Description: PGP signature
Re: When to drop/split/summ changelog files
On 10605 March 1977, Nico Golde wrote: what would be the appropriate way to handle large and old debian changelog files. Keep. Is there a way to handle these changelog entries which bloat the package and contain only information which are too old to be useful or is it ok if for example a changelog file would grow more than the source files of the package? You know they are gzipped? -- bye Joerg Ganneff kde und tastatur? passt doch nicht mit dem nutzerprofil windepp zusammen :) pgpHveXPMEIUg.pgp Description: PGP signature
Re: When to drop/split/summ changelog files
Hi, * Joerg Jaspert [EMAIL PROTECTED] [2006-03-26 20:32]: On 10605 March 1977, Nico Golde wrote: [...] Is there a way to handle these changelog entries which bloat the package and contain only information which are too old to be useful or is it ok if for example a changelog file would grow more than the source files of the package? You know they are gzipped? Yes for sure, but useless zipped information is useless anyway. I thought about changelogs like: 2001-04-06 mitch 20:18:29Michael Natterer [EMAIL PROTECTED] Files: .cvsignore (1.1) ( ) directfb.pc.in (1.1.1.1) (+0 -0) directfb.pc.in (1.1) ( ) directfb-config.in (1.1.1.1) (+0 -0) directfb-config.in (1.1) ( ) configure.in (1.1.1.1) (+0 -0) configure.in (1.1) ( ) autogen.sh (1.1.1.1) (+0 -0) autogen.sh (1.1) ( ) acconfig.h (1.1.1.1) (+0 -0) acconfig.h (1.1) ( ) TODO (1.1.1.1) (+0 -0) TODO (1.1) ( ) README.screenshots (1.1.1.1) (+0 -0) README.screenshots (1.1) ( ) README (1.1.1.1) (+0 -0) README (1.1) ( ) NOTES (1.1.1.1) (+0 -0) NOTES (1.1) ( ) NEWS (1.1.1.1) (+0 -0) NEWS (1.1) ( ) Makefile.am (1.1.1.1) (+0 -0) Makefile.am (1.1) ( ) ChangeLog (1.1.1.1) (+0 -0) ChangeLog (1.1) ( ) COPYING (1.1.1.1) (+0 -0) COPYING (1.1) ( ) BUGS (1.1.1.1) (+0 -0) BUGS (1.1) ( ) AUTHORS (1.1.1.1) (+0 -0) AUTHORS (1.1) ( ) .cvsignore (1.1.1.1) (+0 -0) Initial revision Why not to keep it on another place? Or what would be a scenario in which someone could use them for something? I mean I dont want to just drop them I really just wondered why to keep something in the package if it doesn't seem to be useful. Regards Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org Forget about that mouse with 3/4/5 buttons - gimme a keyboard with 103/104/105 keys! pgpZfM80qpe6F.pgp Description: PGP signature
Re: When to drop/split/summ changelog files
Nico Golde wrote: I thought about changelogs like: 2001-04-06 mitch 20:18:29Michael Natterer [EMAIL PROTECTED] This is not a Debian changelog, and your original question talked about those. Many upstreams split their own changelogs occasionally. If you like, suggest to yours that they do this; don't do it on your own. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When to drop/split/summ changelog files
Hallo Antti, * Antti-Juhani Kaijanaho [EMAIL PROTECTED] [2006-03-26 20:52]: Nico Golde wrote: I thought about changelogs like: 2001-04-06 mitch 20:18:29Michael Natterer [EMAIL PROTECTED] This is not a Debian changelog, and your original question talked about those. Urgs yes, I also wondered why I have never seen a changelog like this :) Regards Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org Forget about that mouse with 3/4/5 buttons - gimme a keyboard with 103/104/105 keys! pgpqdhE2fLv4w.pgp Description: PGP signature
