Re: Faster Release Cycle = More Up to date Packages...
On Fri, 12 Apr 2002 10:15:05 +0100, Carlos Sousa [EMAIL PROTECTED] wrote: testing is, in my opinion, the feature that sets Debian apart from all other Linux distributions. It's as if woody is released every day. If we had a security team working for testing, testing would be the distribution of choice to use. Currently, testing has the worst security record of all Debian distributions, and I don't like that. Unfortunately, I don't have enough spare time to start an effort in that direction, and am therefore stuck with stable on servers, and unstable on non-vital machines. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster Release Cycle = More Up to date Packages...
On Sat, Apr 13, 2002 at 10:57:57AM +0200, Marc Haber wrote: On Fri, 12 Apr 2002 10:15:05 +0100, Carlos Sousa [EMAIL PROTECTED] wrote: testing is, in my opinion, the feature that sets Debian apart from all other Linux distributions. It's as if woody is released every day. If we had a security team working for testing, testing would be the distribution of choice to use. Of course I can talk only for myself, but I use testing only very reluctantly on production servers, because *) I have to recheck whether everything worked out right after an update. *) Update all my servers at the same day so I have the same versions everywhere. *) Keep up-to-date with global conversions like the sdl stuff, the python transition and what else, which force me to hold most stuff for indefinate(sp?) time. Testing is great for my workstation where I want recent software and I don't mind slight glitches, but I can evade the catastrophes of unstable, but I feel uncomfortable using it on servers. For me Stability vs. Current Versions is no binary Yes/No decision. Things like newer kernels (and tools), newer toolchain, newer applications (php, apache, mysql just to name a few) are _also_ important. Nevertheless I think you are doing a great job with Debian. It just rocks. Thank you for providing the only distribution with the fun and community of free software built in. Regards, David -- Signaturen sind wie Frauen. Man findet selten eine Vernuenftige -- gesehen in at.linux Signaturen sind wie Frauen. Hat man einmal eine Vernuenftige gefunden gibt man sie nicht wieder her. -- Hubert Partl pgpeQnbMxStW9.pgp Description: PGP signature
Re: Faster Release Cycle = More Up to date Packages...
Good day everyone, thank you for a lot of input. As a fair number of you have pointed out, you are all quite busy with getting Woody out the door. I aggree that is important, and that the release process can not be changed now right in the middle of Woody-work. Priority right now is fixing bugs in Woody. Unfortunately I can not help you with that as I am not a developer and is no good with code on the production level. While you guys get Woody ready, I will try to find out more about the current release procedure and the past of Debian development. Hopefully I will see you all again May 2Nd. Best regards Johnny Ernst Nielsen :o) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster Release Cycle = More Up to date Packages...
On 11 Apr 2002 21:27:23 -0400 Thomas Hood [EMAIL PROTECTED] wrote: I think testing is an excellent thing to have, since it provides a semi-stable proto-release. Unfortunately it is true that the existence of testing hasn't shortened the release cycle. testing is, in my opinion, the feature that sets Debian apart from all other Linux distributions. It's as if woody is released every day. I can't imagine anyone using potato on his desktop system (Mozilla M18?), and I bet a lot of (most?) production systems out there have also tired of potato and made the move to woody. If the option were a move to unstable, we'd probably be stuck to Mozilla M18 today, and perhaps seriously considering a switch to some other more current Linux distribution. Sorry for the slightly OT post. -- Carlos Sousa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster Release Cycle = More Up to date Packages...
Johnny Ernst Nielsen [EMAIL PROTECTED] cum veritate scripsit: While you guys get Woody ready, I will try to find out more about the current release procedure and the past of Debian development. Hopefully I will see you all again May 2Nd. Or better, start help fixing bugs now. You've wasted enough bandwidth, and showed lack of knowledge about how the current system works. Without knowing how the current system works, it is futile to suggest/point out how to fix it. regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster Release Cycle = More Up to date Packages...
Johnny Ernst Nielsen wrote: Debian's current problem with old packages can be seen by the fact that a number of vendors have reportedly dumped the current Stable release in favor of the Testing distribution some time ago. That can only mean that currentness of content has become more important than bugs, security and stability. It means that Debian is not in balance with currentness of contents. Debian can not continue down that path without compromising Debians own policy of supporting its users. So someone was more interesed in currency than in stability, and they swiched from the debian tree that emphases the later to the tree that emphasises the former. And what was the problem again? The package currentness issue is controlled by an other issue: - How long the period of a freeze lasts before all RC bugs are fixed. Wrong. You would do well to make sure you're fully up-to-date on how debian's release process is currently handled before posting half-baked critisism of it. A casual persusual of the last 10 months or so of postings to debian-devel-announce might be a useful first step. The main proposal is to introduce a fixed short Testing development period into the development cycle like this: 1. Feed Unstable packages to Testing for a fixed short period of time. So you think that dumping a large number of upstream updates of packages into testing in a very short period of time will result in a better integrated and less buggy debian. I see. For the sake of examples, I could imagine the Testing development period being defined to last for 3 months. As, for example, it was planned to be in between the releases of hamm and potato, IIRC. And we know how well that worked. Introducing a fixed short development period for Testing automatically reduces the time between Stable releases. Limiting the time during which Testing is able to recieve RC bugs from Unstable (the Testing development period), should reduce the number of RC bugs in Testing, and thus shorten the freeze time. Here's something to think about. Base has been frozen for 8 months, tasks + standard have been quasi-frozen for several months, and yet we are still getting new release critical bugs filed on those sections of the distribution, on a daily basis. Why do you think that might be? a lot of time for RC bugs to get from Unstable to Testing, thus prolonging the resulting Woody Testing freeze, thus adding to the age of the packages in Stable 3.0. They will be about 6 months old at the time of release (half a year). The versions of mozilla and X in testing are not 6 months old. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster Release Cycle = More Up to date Packages...
On Thu, Apr 11, 2002 at 05:20:27PM +0200, Johnny Ernst Nielsen wrote: At the current pace 3.0 may be out right around May 1St 2002. At that time it will have been more than 1 year and 6 months since the previous point release, which by then contains packages more than 1 year and 6 months old. Er, it will have been less than 1 month since the most recent point release. The current ``stable'' distribution of Debian GNU/Linux is version 2.2r6, codenamed potato. It was released on April 3rd, 2002 -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster Release Cycle = More Up to date Packages...
On Thu, Apr 11, 2002 at 05:20:27PM +0200, Johnny Ernst Nielsen wrote: The main proposal is to introduce a fixed short Testing development period into the development cycle like this: 1. Feed Unstable packages to Testing for a fixed short period of time. 2. Freeze, bugfix, release. Repeat. This was the whole idea of testing. Experience shows it does not work. Please try again - but please wait with discussing it until after May 1st so we can finally get the fucking release done. Greetings Torsten pgp3dcUkyEk0N.pgp Description: PGP signature
Re: Faster Release Cycle = More Up to date Packages...
Thank you Joey for being so obliging to a constructive proposal, and thank you for your polite way of replying to my proposal. Do you think you could put your 6 year old attitude aside for a few moments and take this as a contructive proposal as other normal grownups would do? If you think I have my facts wrong and/or miss information upon which I can base my proposal, I would like you to point me to the sources of the information I miss. I have spent some time trying to find all the information I could, from web pages and mailing lists, but obviously there is information I did not find. Johnny Ernst Nielsen wrote: Debian's current problem with old packages can be seen by the fact that a number of vendors have reportedly dumped the current Stable release in favor of the Testing distribution some time ago. That can only mean that currentness of content has become more important than bugs, security and stability. It means that Debian is not in balance with currentness of contents. Debian can not continue down that path without compromising Debians own policy of supporting its users. So someone was more interesed in currency than in stability, and they swiched from the debian tree that emphases the later to the tree that emphasises the former. And what was the problem again? I am not sure I can explain this in an understandable way, but I will try. The problem seems to be that publicly Debian only supports Stable. I do not disaggree with this. We can not support both Stable, Testing and Unstable. Thus, vendors that want Debian support must use Stable. However, the vendors' users are requesting more up to date software than what Stable provides. So vendors are currently trapped between using a Debian distribution users find too old, or using a Debian distribution for which there is no support. It all falls back on what the users want. Have you forgotten point 4 in the Debian Social Contract? Our Priorities are Our Users and Free Software We are not giving priority to our users if they request up to date software and we do not provide that in the only distribution we publically support. The package currentness issue is controlled by an other issue: - How long the period of a freeze lasts before all RC bugs are fixed. Wrong. You would do well to make sure you're fully up-to-date on how debian's release process is currently handled before posting half-baked critisism of it. A casual persusual of the last 10 months or so of postings to debian-devel-announce might be a useful first step. I am as up-to-date on the Debian release process as I have been able to make myself, and I do not bake. Furthermore, I do not critisise Debians release procedure. I happen to like it, at least what I know about it so far. I did not recognize any release process information in either the debian-policy mailing list, the debian-devel mailing list, or the debian-devel-announce mailing list. Neither did i find such information searching the Debian web site, nor reading the Debian Policy Manual. The only information I found was in the Developer's Reference, Section 5.6.1. It basically says that when the Release Manager thinks it is time to freeze, Testing freezes. Nice and simple. It gives the impression that Testing stops accepting packages from Unstable all together, perhaps unless a package from Unstable will fix a RC bug. As you indicate a bit further below that does not seem to be the way the real world process works. I have done all the searching I can. Someone need to point me to the information you obviously know exists, but which I can't find. Otherwise I will continue to make bad cakes, to your huge annoyance. The main proposal is to introduce a fixed short Testing development period into the development cycle like this: 1. Feed Unstable packages to Testing for a fixed short period of time. So you think that dumping a large number of upstream updates of packages into testing in a very short period of time will result in a better integrated and less buggy debian. I see. No. You either do not understand my point, or I phrase my point in the wrong way. I did not propose a dump. Perhaps the word feed was the wrong one to use. I proposed that Testing accepts packages from Unstable according to our current rules, but only do so for 3 months, essentially forcing a freeze after 3 months. About dumping. The dumping I see is the number of Unstable packages that acumulate in front of Testing's door while it is closed while Testing is in freeze. When Testing is released and a new Testing is put behind the door, then when the door is opened for a new round of Testing development, all the acumulated Unstable packages will fall through the door. Isn't that exactly what happens today? The only difference I see between what happens today, and what would happen according to my proposal, is that the dump of packages from Unstable into Testing would
Re: Faster Release Cycle = More Up to date Packages...
On Thu, Apr 11, 2002 at 11:13:49PM +0200, Johnny Ernst Nielsen wrote: Thank you Joey for being so obliging to a constructive proposal, and thank you for your polite way of replying to my proposal. Do you think you could put your 6 year old attitude aside for a few moments and take this as a contructive proposal as other normal grownups would do? This gets you right about nowhere, fighting flame with fire. I think Torsten has a much, much better point here - get rid of the current RC-bugs now, and find out how woody+1 is going to be done in the weeks following the Woody-release - with the new DPL. -- Rune B. Broberg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster Release Cycle = More Up to date Packages...
Good day Torsten, thank you for your kind answer. The main proposal is to introduce a fixed short Testing development period into the development cycle like this: 1. Feed Unstable packages to Testing for a fixed short period of time. 2. Freeze, bugfix, release. Repeat. This was the whole idea of testing. Experience shows it does not work. Please try again - but please wait with discussing it until after May 1st so we can finally get the fucking release done. I never found information proving that that scheme was atually implemented into the release procedures. Do you know some place where it says something like: 3 months after a release, Testing must freeze. I am not a developer, and I am not suited for code development. But I would like to spend untill 1St of May collecting additional information about the release procedures. best regards Johnny Ernst Nielsen :o) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster Release Cycle = More Up to date Packages...
Good day Matt, thank you for your kind answer. At the current pace 3.0 may be out right around May 1St 2002. At that time it will have been more than 1 year and 6 months since the previous point release, which by then contains packages more than 1 year and 6 months old. Er, it will have been less than 1 month since the most recent point release. The current ``stable'' distribution of Debian GNU/Linux is version 2.2r6, codenamed potato. It was released on April 3rd, 2002 I was not aware that a revision was the same as a point release. Correct me if I am wrong, but do the revisions contain anything new except from security fixes and bugfixes? Has any actual development, like GIMP 1.0 to GIMP 1.2, happened between revisions? I am sorry if I confuse point releases with revisions. What I meant with point releases was versions like 2.0, 2.1 and 2.2. Not revisions like 2.2r1, 2.2r2, etc. Best regards Johnny Ernst Nielsen :o) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster Release Cycle = More Up to date Packages...
On Thu, Apr 11, 2002 at 11:44:36PM +0200, Rune B. Broberg wrote: On Thu, Apr 11, 2002 at 11:13:49PM +0200, Johnny Ernst Nielsen wrote: Thank you Joey for being so obliging to a constructive proposal, and thank you for your polite way of replying to my proposal. Do you think you could put your 6 year old attitude aside for a few moments and take this as a contructive proposal as other normal grownups would do? This gets you right about nowhere, fighting flame with fire. I think Torsten has a much, much better point here - get rid of the current RC-bugs now, and find out how woody+1 is going to be done in the weeks following the Woody-release - with the new DPL. You just hit the nail on the head. Fixing the bugs is the only way to get releases out faster. If the bugs aren't getting fixed properly, no sort of mechanisms will help. Laziness[1] cannot be overcome by scripts and policies. As for the DPL comment, you should note that there is nothing the DPL can do directly to affect the release cycle. Sure, he can delegate duties, and try to pin-point efforts. However, if no one does the work, what's the DPL going to do? [1] That's not directed at any group of people. Yes, I can be accused of being lazy at times too. Yes, we are all volunteers, which is the whole point of the matter. Volunteers cannot be forced into doing anything, and asking a small group to come up with some magic strategy that will somehow overcome The Volunteer Mindset, is like trying to redesign a 22 caliber gun to fight off a 4-mile-wide asteroid headed towards earth. -- Debian - http://www.debian.org/ Linux 1394 - http://linux1394.sourceforge.net/ Subversion - http://subversion.tigris.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster Release Cycle = More Up to date Packages...
On Thu, Apr 11, 2002 at 11:13:49PM +0200, Johnny Ernst Nielsen wrote: Thank you Joey for being so obliging to a constructive proposal, and thank you for your polite way of replying to my proposal. Do you think you could put your 6 year old attitude aside for a few moments and take this as a contructive proposal as other normal grownups would do? [ bla bla bla ] Johnny Ernst Nielsen wrote: Debian's current problem with old packages can be seen by the fact that a number of vendors have reportedly dumped the current Stable release in favor of the Testing distribution some time ago. That can only mean that currentness of content has become more important than bugs, security and stability. It means that Debian is not in balance with currentness of contents. Debian can not continue down that path without compromising Debians own policy of supporting its users. So someone was more interesed in currency than in stability, and they swiched from the debian tree that emphases the later to the tree that emphasises the former. And what was the problem again? ^^^ Who wrote this part? You've stripped the proper attributions. I have no idea who Joey is (there are at least 2 DDs who it could be). It's impossible to carry on a discussion if you can't follow basic email etiquette. [ hint: if you are complaining about a flame, using a flame to do it is probably not the best solution ] Finally, please do go read the archives. The we need to fix the release mechanism and here's my s00per-d00per method to do it thread arrives here every few weeks. It';s hard to believe anyone has anything new to say at this point. [ snip ] Regards, -- Nathan Norman - Micromuse Ltd. mailto:[EMAIL PROTECTED] Gil-galad was an Elven-king.| The Fellowship Of him the harpers sadly sing: |of the last whose realm was fair and free | the Ring between the Mountains and the Sea. | J.R.R. Tolkien pgp1BiP2Jj5zI.pgp Description: PGP signature
Re: Faster Release Cycle = More Up to date Packages...
On Thu, Apr 11, 2002 at 11:46:55PM +0200, Johnny Ernst Nielsen wrote: I am not a developer, and I am not suited for code development. But I would like to spend untill 1St of May collecting additional information about the release procedures. Currently that is black magic, mostly the release manager knows, what's going on ;) I think you are right, we have to rethink the release process again. But please let's defer that until after this release... Discussing that woody's release is going nowhere will get woody's release nowhere ;-) cu Torsten pgpJwVBgqS2vm.pgp Description: PGP signature
Re: Faster Release Cycle = More Up to date Packages...
Johnny Ernst Nielsen wrote: Do you think you could put your 6 year old attitude aside for a few moments and take this as a contructive proposal as other normal grownups would do? Having discussed all this before in my 6 year old tenure with Debian, no, I really don't have time to rehash it all again with someone who has not done basic research and who descends to implausable personal attacks on my birthday. Making up claims out of whole cloth as you do here is a good way to find yourself ignored, by me anyway -- Today, when the new Testing opens for contributions from Unstable (after 3.0 is released) there will be about 6 months worth of packages waiting in Unstable that will dump into Testing from Unstable right away. http://ftp-master.debian.org/testing/update_excuses.html Or perhaps there is some large set of packages in that list that I'm missing that will magically fall through into testing on May second. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster Release Cycle = More Up to date Packages...
On Apr 11, Johnny Ernst Nielsen wrote: To make things worse, 3.0 contents will at the time of release already be about 6 months out of date. Here's a challenge for you: identify the top date in the changelog for the current version of every package in testing (3.0). I doubt there's a single package in standard that hasn't been changed in the past six months. Except for frozen packages, an updated upstream version of any package uploaded today would make it into testing by May 1, unless aj switches to a hard freeze on all packages in the next ten days. Since my guess is that we won't see a hard freeze until all the RC bugs are done, I like the chances of any package in unstable making it into woody. The only packages in unstable that aren't in woody (testing) are in the update-excuses output: http://ftp-master.debian.org/testing/update_excuses.html Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster Release Cycle = More Up to date Packages...
Johnny Ernst Nielsen: Don't worry about flames launched by cranky developers who didn't get what they wanted for their birthdays. Many of us haven't read _every_ posting on _every_ debian list for the past six years and may therefore once in a while bring up some issue that has been discussed previously. The appropriate way to deal with poor people like ourselves it to post URLs for relevant threads we should read. I think your suggestion has some merit. Torsten Landschoff replied that This was the whole idea of testing. Experience shows it does not work. I think testing is an excellent thing to have, since it provides a semi-stable proto-release. Unfortunately it is true that the existence of testing hasn't shortened the release cycle. Ben Collins offered what amounts to a possible explanation for this. He says that it is the rate of bug fixing that determines how fast the next release gets out. Since the rate of bug fixing is fixed, therefore the release cycle cannot be speeded up. (I hope that is a faithful summary.) But this argument fails for two reasons. Mr. Nielsen's proposal is designed to speed up the release schedule, not to increase the bug-fixing throughput. Instead of doing 100 units of bug-breeding development followed by 100 units of RC debugging, he suggests doing 50 units of development, 50 units of RC debugging, 50 units of development, 50 units of RC debugging. Of course it's far from being so simple as that, but the overall idea seems sound. If we take smaller bites, we will have less to chew and less to swallow. Our throughput might even increase (no gagging ... fewer Heimlich maneuvers required). The second reason that B.C.'s argument fails is that a shorter cycle might encourage greater effort on the part of the volunteers. Under the current system, the periods during which maintainers concentrate their efforts so that they can get their packages ready for release are fewer and farther between than they might be. Under the current process there are long periods when bugs can be ignored because the release is years away. We have seen members resign in frustration with the sluggishness of the whole process. More frequent releases, brought about by means of Mr. Nielsen's suggestion, might evoke greater total effort. We don't want releases so frequent that they cease to be important events, but the current release schedule is, I would guess, not optimally harnessing the resources that we have. signature.asc Description: This is a digitally signed message part
Re: Faster Release Cycle = More Up to date Packages...
On Thu, Apr 11, 2002 at 09:27:23PM -0400, Thomas Hood wrote: birthdays. Many of us haven't read _every_ posting on _every_ debian list for the past six years and may therefore once in a while bring up some issue that has been discussed previously. This isn't exactly every debian list for the past six years. I would wager that there's been a major (50+ posts) thread on this subject on this mailing list at worst every 6 months. -- David Starner - [EMAIL PROTECTED] It's not a habit; it's cool; I feel alive. If you don't have it you're on the other side. - K's Choice (probably referring to the Internet) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster Release Cycle = More Up to date Packages...
On Thu, Apr 11, 2002 at 09:27:23PM -0400, Thomas Hood wrote: Torsten Landschoff replied that This was the whole idea of testing. Experience shows it does not work. I think testing is an excellent thing to have, since it provides a semi-stable proto-release. Unfortunately it is true that the existence of testing hasn't shortened the release cycle. Largely, I think, because boot-floppies weren't ready in a plausible time, and we thought for a while that we'd be able to use debian-installer for woody. That all slowed things down. At the start we also had the move to package pools, and recently we had crypto-in-main which took a long time to get decided. The testing distribution also took a long time to settle down when it was first introduced. I remember spending a lot of time going through update_excuses.html and update_output.txt a year or so ago trying to work out where all the problems were. It seems to have mostly settled down to a steady state now where not too many nightmare package-renaming transitions are trying to happen at once, and it will start off the next release cycle in that state. *If* debian-installer is ready in time, then I think we have a good chance of being able to release woody+1 much more quickly than woody. If not, then I guess we don't. I'd like to see a team of QA people attacking release-critical bugs right from the start of the next release cycle, so that the rest of the distribution has a chance of staying releaseable. But this argument fails for two reasons. Mr. Nielsen's proposal is designed to speed up the release schedule, not to increase the bug-fixing throughput. Instead of doing 100 units of bug-breeding development followed by 100 units of RC debugging, he suggests doing 50 units of development, 50 units of RC debugging, 50 units of development, 50 units of RC debugging. Of course it's far from being so simple as that, but the overall idea seems sound. It's not implausible - but everyone suggesting this kind of thing always forgets about the historical difficulty of getting the installation system ready. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Faster Release Cycle = More Up to date Packages...
On Thu, Apr 11, 2002 at 08:39:54PM -0500, David Starner [EMAIL PROTECTED] was heard to say: On Thu, Apr 11, 2002 at 09:27:23PM -0400, Thomas Hood wrote: birthdays. Many of us haven't read _every_ posting on _every_ debian list for the past six years and may therefore once in a while bring up some issue that has been discussed previously. This isn't exactly every debian list for the past six years. I would wager that there's been a major (50+ posts) thread on this subject on this mailing list at worst every 6 months. At worst? I'd think at worst every week. Or maybe we have different definitions of at worst.. :-) Daniel -- / Daniel Burrows [EMAIL PROTECTED] ---\ |But what *does* kill me bloody well leaves me dead!| | -- Terry Pratchett, _Carpe Jugulum_| \-Evil Overlord, Inc: planning your future today. http://www.eviloverlord.com-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
