Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On 15-Mar-00, 01:06 (CST), Craig Sanders [EMAIL PROTECTED] wrote: DO NOT PUT WORDS IN MY MOUTH. your argument for want of a better term is obviously so poor that you have no choice but to misrepresent mine to make your points. Hmm, it's ok for you to misrepresent other people's arguments, but not the other way around, as follows: so why do you have a problem with infrastructure (i.e. package pools in one form or another) which makes it easier to build a snapshot image? do you have some kind of aversion to automating tedious and time-consuming tasks? DO NOT PUT WORDS IN MY MOUTH. your argument for want of a better term is obviously so poor that you have no choice but to misrepresent mine to make your points. (And you *are* mispresenting my point, because you completely ignored the next paragraph where I spoke favorably about package pools.) and fuck you too! how dare you fucking misrepresent my position and twist what i said in such a reprehensible manner? Why not? You do it to everybody else. In the meantime, plonk! Cheers, sg -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Wed, Mar 15, 2000 at 08:41:01PM -0600, Steve Greenland wrote: On 15-Mar-00, 01:06 (CST), Craig Sanders [EMAIL PROTECTED] wrote: DO NOT PUT WORDS IN MY MOUTH. your argument for want of a better term is obviously so poor that you have no choice but to misrepresent mine to make your points. Hmm, it's ok for you to misrepresent other people's arguments, but not the other way around, as follows: so why do you have a problem with infrastructure (i.e. package pools in one form or another) which makes it easier to build a snapshot image? do you have some kind of aversion to automating tedious and time-consuming tasks? DO NOT PUT WORDS IN MY MOUTH. notice that i asked questions. it up to you to confirm or deny or ignore a question. it implicitly gives you the opportunity to accept or refute the query, without a prejudgement of the situation. what you did was quite different. you came up with a reprehensible misinterpretation of what i said and what my views are, and then projected it onto me. you *stated* that your offensive misrepresentation was my position. do you comprehend the difference? your argument for want of a better term is obviously so poor that you have no choice but to misrepresent mine to make your points. (And you *are* mispresenting my point, because you completely ignored the next paragraph where I spoke favorably about package pools.) no, i stated that you made no points. that was a) true, and b) nothing like deliberately misrepresenting your points. and fuck you too! how dare you fucking misrepresent my position and twist what i said in such a reprehensible manner? Why not? You do it to everybody else. fuck off, lying scum. In the meantime, plonk! plonk your fucking self. arsehole. craig -- craig sanders
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
Steve Greenland: Hmm, it's ok for you to misrepresent other people's arguments, but not the other way around, as follows: Craig Sanders: so why do you have a problem with infrastructure (i.e. package pools in one form or another) which makes it easier to build a snapshot image? Steve Greenland: (And you *are* mispresenting my point, because you completely ignored the next paragraph where I spoke favorably about package pools.) Here's what Steve wrote: If you want to work on the unstable stuff, I think the package-pool implementation would good place to start. Craig Sanders: notice that i asked questions. it up to you to confirm or deny or ignore a question. Statements are confirmed or denied, not questions. Questions are answered. There's a gigantic difference between these two questions: do you have a problem with infrastructure (i.e. package pools ...)? why do you have a problem with infrastructure (i.e. package pools ...)? You wrote the latter, which clearly misrepresents what Steve wrote. You seem like a smart guy, so I can only assume you were being dishonest, and not just incompetent. Combine that with your selfishness, your arrogance, and your excessive, unnecessary, and juvenile obscenity, and here's what you get: *plonk* -- Brian Kimball
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Tue, Mar 14, 2000 at 05:27:26PM -0500, Ben Collins wrote: Well, it's really sad that you like to dredge up year old context for this thread to suit your mundane arguments, they have little context with what I was saying. actually, it's really sad that you haven't learnt that closing down 'unstable' is a disastrously bad idea. you've been with debian long enough now to have learnt that. you miss two important points. the first is that the release is not everyone's highest priority. the second is that some people have nothing to contribute to frozen/stable, so discouraging (or preventing) them from working on unstable is counterproductive. Once can argue that the reason is because they don't know how they can help. one could argue that, but one would be wrong. Everyone within Debian has a stake in frozen, simply by being a member, and every can help. There is nothing preventing that. sure, everyone can help (but that doesn't necessarily mean that the freeze/release process will go faster...in fact, for some tasks it is guaranteed to slow it down). however, there is no reason to require everyone to help or even to care very much about frozen/stable. both of these points are proved by the fact that we have over 500 developers yet, according to your own words, we are short on needed resources for getting potato release ready. if everyone, or the majority...or even a substantial minority, had your priorities then that would not be the case. First of all, you need to check your numbers. Last I checked there were ~350 official developers in the keyring. last i checked we were approaching 500. irrelevant, anyway. 350 or 500, it's still more than enough to prove my point. Right, so this proves my point in that we should encourage developers to put a priority on frozen and the next release cycle. no, it doesn't prove it at all. adding many more people to the task of getting the stable release out the door will not speed it up - if anything, it will slow it down. And please stop refering to stable. That is not my main concern here, and I never brought it into this conversation. do you have some kind of comprehension problem with the english language? my references to the 'stable release' are obviously referring to the work that needs to be done to get potato released. in any case, simply adding more people to the project won't make it happen any faster. what WILL make it faster is to fork off the stable release as a sub-project of debian, and give the release team absolute authority over the release, with the right to make NMUs of any package and make any other changes for any reason they see fit. as with any other debian initiative, any developer (or user) would be free to work on it or not as they please. How would that help? That is simply a superficial thing. Calling it a seperate project would do nothing to improve the situation. it is far from superficial. co-ordinating the activities of a small group of 10-30 (estimated) people is a lot easier and a lot more efficient than co-ordinating the activities of 300 or 500 people. by forking the release as a sub-project, and granting complete authority and responsibility to those who give enough of a damn to join the release team, you can minimise the delays and interruptions caused by the vast majority of developers who work on unstable yet have little or nothing to contribute to the release process. Plus that creates havoc with changes made to the frozen release that aren't in unstable. So we get split bug reports and a lot of other crazy things. that's something for the release team to worry about - after all, they're the ones who are going to face the problems caused when it comes time to do the next freeze/release. i.e. there will be an inherent sanity-check on their changes, caused by their desire to make future versions as easy to produce as possible. also, the issue is not man-power, the issue is man-hours - i.e. how much time any of the people doing the important jobs can devote to debian. most of them have full-time jobs or are full-time students and are working on debian in their spare time. the really imporant tasks can't be sped up by some kind of time-sharing arrangement. Ok, let's play word games. Man-hours is a direct result of man-power. no it is not. more precisely, the relationship is nowhere near as simple as what you are trying to make out. does it just suit your argument to play dumb or what? the following should be elementary knowledge, especially to anyone in the computer industry (who should have at least superficial knowledge of the ideas in the _The Mythical Man Month_ by Frederick Brooks), but you appear to need to have it pointed out: having 10 times as many people does not mean you get 10 times as much work done or even the same job done in 1/10th the time. e.g. if 1 person can dig a hole in 10 minutes, having 10 people work on it does not
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Tue, Mar 14, 2000 at 11:50:05PM +0100, Josip Rodin wrote: Uh, which were the packages in question? Did you report it at the time? no need, the holes were already well known - and fixed in unstable. Security fixes have to be (and are) fixed in stable, too! most are. craig -- craig sanders
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Tue, Mar 14, 2000 at 05:43:38PM -0500, Michael Stone wrote: On Tue, Mar 14, 2000 at 05:27:26PM -0500, Ben Collins wrote: it doesn't distract me at all. i mostly ignore it these days as it is of little or no relevance to me. Safe to say, that is a really self-centered attitude. One which I hope that most developers don't have. Not a very team oriented situation if everyone felt that way. OTOH (to play devil's advocate) the stable process seems to continually get bogged down. Slipping deadlines, inappropriate package upgrades, etc., begin to make things seem hopeless. When push comes to shove, things usually get done--but what's the push right now? good to see that someone sees my point (although it's not solely my point - it has been made several times by many others over the years). amongst numerous other benefits, snapshot CDs will take the pressure off the release team and allow them to take as much time as they feel is necessary to produce the 'perfect' release. craig -- craig sanders
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On 14-Mar-00, 18:58 (CST), Craig Sanders [EMAIL PROTECTED] wrote: actually, it's really sad that you haven't learnt that closing down 'unstable' is a disastrously bad idea. you've been with debian long enough now to have learnt that. How do you know? We've never tried it. You and others say it would be a disaster. I and others think it would help. Proof by assertion isn't. However, there is no reason to require everyone to help or even to care very much about frozen/stable. Except that it is part of what Debian does. Joining the org implies at least some interest in the goals. If you disagree with the goals, lobby to change them. by forking the release as a sub-project, and granting complete authority and responsibility to those who give enough of a damn to join the release team, you can minimise the delays and interruptions caused by the vast majority of developers who work on unstable yet have little or nothing to contribute to the release process. Why do you continue to insist that they can't contribute? They can test installs, they can fix bugs, they can improve docs. that's something for the release team to worry about - after all, they're the ones who are going to face the problems caused when it comes time to do the next freeze/release. Yeah, this release team should take on all responsibility for all the other peoples packages. Beautiful. Never mind that the next freeze, those problems *still* exist because the maintainer of the package doesn't need to care about fixing bugs or following policy; after all, it's something for the release team to worry about. also, the issue is not man-power, the issue is man-hours - i.e. the following should be elementary knowledge, especially to anyone in the computer industry (who should have at least superficial knowledge of the ideas in the _The Mythical Man Month_ by Frederick Brooks), but you appear to need to have it pointed out: having 10 times as many people does not mean you get 10 times as much work done or even the same job done in 1/10th the time. e.g. if 1 person can dig a hole in 10 minutes, having 10 people work on it does not mean that you can dig the same hole in 1 minute. in fact, most likely that same hole will take at least 20 or 30 minutes due to the hassle of organising everyone and, even worse, everyone getting in each other's way and interfering with their work. Apparently you need to go back and read MMM again, and tCatB as well: you missed the point that the reason that productivity does not vary linearly with people has to do with how easily the tasks are done in parrallel. 10 people *can* dig 10 holes 10 times as fast as 1 person. And what computing task *is* well done in parallel? Testing and debugging. That's why the whole Bizzaar methodology works! so how many people can work on the one problem (say, the boot-floppies) at the same time? it *might* go faster if there were 2 or 3 people working on it rather than just one, but it would *certainly* go a lot slower if there were 20 or 30 or 300 people working on it. It would go a hell of lot faster if 30 or 300 people would test the damn things and report problems with their various hardware configurations, and the choices/options they used in their particular install situation. But no, you'd rather they uploaded yet another clock tool. what i said was that i want to see the real debian (aka unstable) become more accesible to the majority of our users. the way to do this is by making regular snapshot releases. There is nothing stopping anyone from making snapshot releases of unstable. Mirror the archive. Burn a CD. Done. That's what a snapshot is. God forbid you make the snapshot on a day that perl is broken, of course. Or dpkg. Or glibc. Damn unreliable Debian PoS. I think you have a very narrow idea of what most users want. this capability has been touted as one of the advantages of the package pools ideas every time it has come up over the last few years. That's right, it has. If it's so important, why haven't people (you!) gotten off your ass and done something about it? If you want to work on the unstable stuff, I think the package-pool implementation would good place to start. your proposal, quite frankly, stinks. your position is that if people won't or can't work on what YOU consider to be important then you don't want them to work on anything at all...they should just twiddle their thumbs and wait for 'stable' to be released before they are allowed to contribute anything. Your attitude, quite frankly, stinks. Your position is that that once you've uploaded a package, you have nothing else to contribute to the project. Instead, other people should babysit your packages to make them work with the rest of the system. Debian is supposed to be a team, a group of people working to create something good and valuable. If we're not going to be that, we might as well just the Red Hat contrib directory. Very sad that
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Tue, Mar 14, 2000 at 09:23:42PM -0600, Steve Greenland wrote: On 14-Mar-00, 18:58 (CST), Craig Sanders [EMAIL PROTECTED] wrote: actually, it's really sad that you haven't learnt that closing down 'unstable' is a disastrously bad idea. you've been with debian long enough now to have learnt that. How do you know? We've never tried it. You and others say it would be a disaster. I and others think it would help. Proof by assertion isn't. because if developers had to wait 12 or 18 months to get their new stuff into debian then there would be very few developers who would bother. that constitutes a disaster. it would be the death of debian. However, there is no reason to require everyone to help or even to care very much about frozen/stable. Except that it is part of what Debian does. i am glad you recognise that it is only *part* of what debian does. Joining the org implies at least some interest in the goals. If you disagree with the goals, lobby to change them. i do not disagree with debian's goals. if i did then i wouldn't be here. by forking the release as a sub-project, and granting complete authority and responsibility to those who give enough of a damn to join the release team, you can minimise the delays and interruptions caused by the vast majority of developers who work on unstable yet have little or nothing to contribute to the release process. Why do you continue to insist that they can't contribute? i don't insist that at all. quite the contrary, i insist that they continue to contribute in whatever way they see fit, including the option of uploading new stuff to unstable. They can test installs, they can fix bugs, they can improve docs. not everyone has the time, patience, inclination, skills, desire or whatever to do these things. if somebody wants to work on these things, then that's fine. if somebody wants to work on unstable, where is the problem? that's something for the release team to worry about - after all, they're the ones who are going to face the problems caused when it comes time to do the next freeze/release. Yeah, this release team should take on all responsibility for all the other peoples packages. wrong. they take on the responsibility for the RELEASE. if that means that they feel they have to make a change to somebody else's package then so be it, they should have the right to do so. delegate complete authority to the release team to do whatever they feel is necessary to produce a high-quality release version of debian. if the maintainer of a changed package agrees with their decision then they will incorporate the changes into their version of the package. if not, then there is a dispute which will eventually need to be resolved. big deal, shit happens, deal with it on a case-by-case basis. Beautiful. Never mind that the next freeze, those problems *still* exist because the maintainer of the package doesn't need to care about fixing bugs or following policy; that might happen in a tiny minority of cases, but it's hardly likely to be the normal case. there's no need to paint it in such black white terms, either. there are legitimate grounds for a package maintainer to disagree with the release team, without wearing those insulting labels. after all, it's something for the release team to worry about. if the maintainers and the release team are doing their job properly then this will rarely be a problem. in the few cases where it does become a problem then we deal with it in the usual way - have a discussion or flamewar on debian-devel and eventually reach consensus (or at least, adapt policy so that the current ambiguity is resolved) Apparently you need to go back and read MMM again, and tCatB as well: you missed the point that the reason that productivity does not vary linearly with people has to do with how easily the tasks are done in parrallel. 10 people *can* dig 10 holes 10 times as fast as 1 person. And what computing task *is* well done in parallel? Testing and debugging. That's why the whole Bizzaar methodology works! testing packages is not the only delay in the release cycle. for example, the boot floppies were a significant delay this time around. that's not surprising at all, they usually are...there's a lot of new development and a lot of work in making sure all the new base packages and new kernel work properly as an install set. even if everything in the freeze/release cycle were perfectly parallelizable, that would still be no justification for closing off unstable. not everyone has the ability or the desire to contribute to frozen - they should be allowed to contribute to unstable as they always have been. so how many people can work on the one problem (say, the boot-floppies) at the same time? it *might* go faster if there were 2 or 3 people working on it rather than just one, but it would *certainly* go a lot slower if there were 20 or 30 or 300 people working on
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
Le Wed, Mar 15, 2000 at 06:06:24PM +1100, Craig Sanders écrivait: and fuck you too! how dare you fucking misrepresent my position and twist what i said in such a reprehensible manner? if you don't fucking understand what i'm saying then shut the fuck up. Could you stop use those FUCKING words ? Can't you be polite ? And yes, your attitude stinks ! You have 3 RCB open against your packages (11, 25 and 21 days old), so YOUR FUCKING job is to close those FUCKING RCB and not concentrate on woody or whatever you care ... If all maintainer could correct their own bugs, then there would be no need to work on someone else package just to make it ready for potato ! And you also have 50 other bugs to correct on your little packages. You're certainly NOT the guy who can speak loud, you're not an example to follow ! Really, from time to time I think we should close debian-devel since we're loosing time on discussion that are not worh it and/or with people that should be doing something else than flaming here ... A funny new rule would be that anybody having a RCB on one of its packages, can't post to the Debian lists unless it's specifically for correcting those bugs ... Cheers, -- Raphaël Hertzog 0C4CABF1 http://tux.u-strasbg.fr/~raphael/ pub CD Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd Formations Linux et logiciels libres : http://www.logidee.com /pub
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Wed, Mar 15, 2000 at 12:10:54PM +1100, Craig Sanders wrote: Uh, which were the packages in question? Did you report it at the time? no need, the holes were already well known - and fixed in unstable. Security fixes have to be (and are) fixed in stable, too! most are. IMNSHO *all* of them must be. It would be wrong to leave the users of stable `in the cold'. Those bugs that aren't fixed in stable are the worst release-critical bugs. -- enJoy -*/\*- don't even try to pronounce my first name
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Wed, Mar 15, 2000 at 09:35:35AM +0100, Raphael Hertzog wrote: Le Wed, Mar 15, 2000 at 06:06:24PM +1100, Craig Sanders écrivait: and fuck you too! how dare you fucking misrepresent my position and twist what i said in such a reprehensible manner? if you don't fucking understand what i'm saying then shut the fuck up. Could you stop use those FUCKING words ? Can't you be polite ? i respond to insults in whatever fucking manner i see fit. if steve had stuck to the fucking issue and refrained from being an insulting prick then i wouldn't have felt any need to swear at him. And yes, your attitude stinks ! You have 3 RCB open against your packages (11, 25 and 21 days old), so YOUR FUCKING job is to close those FUCKING RCB and not concentrate on woody or whatever you care ... fuck off. these 3 RCBS are news to me, but that's no fucking suprise because it wouldn't be the first fucking time that the fucking bug tracking system failed to fucking send a bug report to the fucking maintainer. Here's a fucking clue for you: I DO NOT DO WHAT YOU FUCKING TELL ME TO, GET THE FUCKING PICTURE? i'll close them when i fucking feel like it and when i have the fucking time. Cheers, fucking hypocrite. if you're going to be an arsehole in email, the least you can fucking do is get rid of the phony fucking Cheers. no fucking regards, craig ps: fuck you too, arsehole. pps: i'll use whatever fucking words i like. if you don't like it, then don't fucking read it. go censor your fucking self. -- craig sanders
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Wed, Mar 15, 2000 at 10:05:09AM +0100, Josip Rodin wrote: Security fixes have to be (and are) fixed in stable, too! most are. IMNSHO *all* of them must be. It would be wrong to leave the users of stable `in the cold'. Those bugs that aren't fixed in stable are the worst release-critical bugs. most are. most of them even in a timely fashion. craig -- craig sanders
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
15.03.2000 pisze Craig Sanders ([EMAIL PROTECTED]): [cut] Gentlemen, I have seen ``South Park: The Movie'' and I like it -- in the cinema. Not here. I don't like to see developers of my favourite Linux distribution to behave in such a childish way. Would you kindly like to get your toys and go to the other sand-box to play (or fight, or kill yourselves, I don't care)? sincerely, Jubal -- [ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ] [ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ] Lsku moji kne Igor si bere nad sklenkou vodky hraju si s revolverem havran used na stechy Petrburgu ert aby to spral -- Jaromir Nohavica
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Wed, Mar 15, 2000 at 09:35:35AM +0100, Raphael Hertzog wrote: You have 3 RCB open against your packages (11, 25 and 21 days old), right. one of them for a package (spamdb) which doesn't even exist anymore so it's a bit difficult to see how it could be release critical. two of them for the same package (vtun). again, they hardly seem release critical i haven't yet decided what to do about vtun. i'll probably get around to upgrading it to the latest version one day, but i made a mistake packaging it in the first place - i thought it would be useful, but i don't even use it any more. it's not a particularly important package (both cipe and tunnelv do a much better job of the same kind of thing) and it would be small loss to debian if it happened to get dropped from frozen while i'm taking my time deciding what to do. if anyone cares enough about vtun to adopt the package or do an NMU before i get around to it, feel free. And you also have 50 other bugs to correct on your little packages. the bulk of those are for spamdb, which doesn't exist any more - it's obsolete (and i gave over a year's warning that i was going to orphan it - nobody cared enough about it to bother adopting it in that time). most of the rest have actually been fixed, but i must have got the BTS syntax wrong when closing the bugs in the changelog. craig -- craig sanders
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Tue, 14 Mar 2000, Ben Collins wrote: snip First of all, you need to check your numbers. Last I checked there were ~350 official developers in the keyring. Right, so this proves my point in that we should encourage developers to put a priority on frozen and the next release cycle. And please stop refering to stable. That is not my main concern here, and I never brought it into this conversation. No, that means you should OPEN NEW-DEVELOPERS! Jesus! On the one hand I hear all of these complaints about not having enough help and the other hand is flipping a big 'ol bird at anyone who's offering to help. The only way I see new manpower being added to Debian ATM is cloning, and I'm kind of hoping nobody in Debian qualifies as sheep or pigs. we now return you to your regularly scheduled snip ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] The Internet must be a medium for it is neither Rare nor Well done! a href=mailto:[EMAIL PROTECTED]John Galt /a
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Wed, Mar 15, 2000 at 09:03:18PM +1100, Craig Sanders wrote: On Wed, Mar 15, 2000 at 09:35:35AM +0100, Raphael Hertzog wrote: You have 3 RCB open against your packages (11, 25 and 21 days old), two of them for the same package (vtun). again, they hardly seem release critical i haven't yet decided what to do about vtun. i'll probably get around to upgrading it to the latest version one day, but i made a mistake packaging it in the first place - i thought it would be useful, but i don't even use it any more. Hmm. I don't see this on the list of orphaned packages. It also doesn't seem like you indicated this to [EMAIL PROTECTED], so how would the release manager know it? -- Mike Stone pgp0I6zOe5nD0.pgp Description: PGP signature
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Wed, Mar 15, 2000 at 07:07:51AM -0500, Michael Stone wrote: On Wed, Mar 15, 2000 at 09:03:18PM +1100, Craig Sanders wrote: i haven't yet decided what to do about vtun. i'll probably get around to upgrading it to the latest version one day, but i made a mistake packaging it in the first place - i thought it would be useful, but i don't even use it any more. Hmm. I don't see this on the list of orphaned packages. try reading the words in front of you. i have not yet decided what i'm going to do about vtun. i will probably upgrade it to the latest version one day. if someone wants to take it over or do an NMU before i get around to it then they should feel free to do so. It also doesn't seem like you indicated this to [EMAIL PROTECTED], once again: I haven't yet decided what to do about vtun. craig -- craig sanders
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Wed, Mar 15, 2000 at 11:18:49PM +1100, Craig Sanders wrote: On Wed, Mar 15, 2000 at 07:07:51AM -0500, Michael Stone wrote: On Wed, Mar 15, 2000 at 09:03:18PM +1100, Craig Sanders wrote: i haven't yet decided what to do about vtun. i'll probably get around to upgrading it to the latest version one day, but i made a mistake packaging it in the first place - i thought it would be useful, but i don't even use it any more. Hmm. I don't see this on the list of orphaned packages. try reading the words in front of you. i have not yet decided what i'm going to do about vtun. i will probably upgrade it to the latest version one day. if someone wants to take it over or do an NMU before i get around to it then they should feel free to do so. How would people know that if it's not on the list? If you put it on the list and then change your mind, you can take it off. If you orphan it and later decide you want to upgrade it, *you* can do an NMU. But by doing nothing you make it very difficult for other people to maintain your package for you. -- Mike Stone pgpvQGajt2aWv.pgp Description: PGP signature
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
[ ok I'll keep calm this time ] Le Wed, Mar 15, 2000 at 09:03:18PM +1100, Craig Sanders écrivait: right. one of them for a package (spamdb) which doesn't even exist anymore so it's a bit difficult to see how it could be release critical. That's possible, but then it would be great if you could close all the bugs related to spamdb so that they won't burden us anymore ... two of them for the same package (vtun). again, they hardly seem release critical Then it's your job to lower the priority and/or to close them. I don't want more from maintainer, I just want that they do what they have to and it's not that much ... it's not difficult to check once a week your page on the BTS. most of the rest have actually been fixed, but i must have got the BTS syntax wrong when closing the bugs in the changelog. The same problem applies to many developers, but that must change, when a bug is gone, it must be closed in the BTS or the BTS will be worthless one day or another. Cheers, -- Raphaël Hertzog 0C4CABF1 http://tux.u-strasbg.fr/~raphael/ pub CD Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd Formations Linux et logiciels libres : http://www.logidee.com /pub
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Wed, Mar 15, 2000 at 03:24:29AM -0700, John Galt wrote: On Tue, 14 Mar 2000, Ben Collins wrote: snip First of all, you need to check your numbers. Last I checked there were ~350 official developers in the keyring. Right, so this proves my point in that we should encourage developers to put a priority on frozen and the next release cycle. And please stop refering to stable. That is not my main concern here, and I never brought it into this conversation. No, that means you should OPEN NEW-DEVELOPERS! Jesus! On the one hand I hear all of these complaints about not having enough help and the other hand is flipping a big 'ol bird at anyone who's offering to help. The only way I see new manpower being added to Debian ATM is cloning, and I'm kind of hoping nobody in Debian qualifies as sheep or pigs. New Maintainer is OPEN. They posted a call for applications from currently sponsored developers last week. This means that people who are currently helping via the sponorship program are going to get in quite quickly. IMNHO, this is exactly the right thing to do. People who have shown that they are willing to contribute, even if it means waiting, have shown they have what it takes to become a developer. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
Steve Greenland wrote: There is nothing stopping anyone from making snapshot releases of unstable. Mirror the archive. Burn a CD. Done. That's what a snapshot is. As one of the many people who does not have cheap, fast, reliable internet access, I would like to say that for me to mirror 650 MB of debian and burn a CD of it would cost around $130 in charges and 2 and a half days of straight downloading if I was lucky. Probably much longer. So I'd like snapshots, but really I run stable run until the moment frozen becomes stable at which I can get a CD on which everything has a good chance of working, because if anything breaks I'm pretty much stuffed. -- Martijn van Oosterhout [EMAIL PROTECTED] Trust the computer industry to shorten Year 2000 to Y2K. It was this kind of thinking that caused the problem in the first place.
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
I'll believe it when I see a newly minted developer. It never should have been closed in the first place, so therefore I see the fact that it HAD to be opened as doubt-inspiring as to whether there will ever be a newly minted developer. Until I see a working new-developers mechanism, I see complaints about lack of manpower as rhetorical at best, hypocritical at worst. On Wed, 15 Mar 2000, Ben Collins wrote: On Wed, Mar 15, 2000 at 03:24:29AM -0700, John Galt wrote: On Tue, 14 Mar 2000, Ben Collins wrote: snip First of all, you need to check your numbers. Last I checked there were ~350 official developers in the keyring. Right, so this proves my point in that we should encourage developers to put a priority on frozen and the next release cycle. And please stop refering to stable. That is not my main concern here, and I never brought it into this conversation. No, that means you should OPEN NEW-DEVELOPERS! Jesus! On the one hand I hear all of these complaints about not having enough help and the other hand is flipping a big 'ol bird at anyone who's offering to help. The only way I see new manpower being added to Debian ATM is cloning, and I'm kind of hoping nobody in Debian qualifies as sheep or pigs. New Maintainer is OPEN. They posted a call for applications from currently sponsored developers last week. This means that people who are currently helping via the sponorship program are going to get in quite quickly. IMNHO, this is exactly the right thing to do. People who have shown that they are willing to contribute, even if it means waiting, have shown they have what it takes to become a developer. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' Sacred cows make the best burgers Who is John Galt? [EMAIL PROTECTED], that's who!!!
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
I am going to attempt to install Potato over a 28.8/56k modem. I have downloaded and 'burned' all 15 floppies needed for the basic system, and will install that first. Then I will set up PPP, and fire up dselect (apt method). I have already done this at work (but on a T1-lan-proxy setup). I expect that the process will take several 'over-night' runs. You don't need to download 650mb worth of stuff, I suspect that for a typical debian install 100mb of 'stuff' actually is needed to be downloaded. There are a LOT of functionaly duplicate packages, little used packages, and source packages on the CD's that few people make use of. That's why many of the books can come with Debian on a single CD, they have prunned out the stuff that most people won't use leaving a still very functional representation of Debian. In my case my dialup connection is a local call (basicly free) and $19.95 a month (for up to something like 250hrs) for the isp. This is probably typical for the average US user, I realize that in Europe and elsewhere you are probably paying more. I am still waiting on GD Flashcom to get my IDSL connection working, I had hoped it would be up by the time Potato was frozen but I will try the modem method meantime. Others have told me that they installed Debian this way, so I will try it at least once. Steve Greenland wrote: There is nothing stopping anyone from making snapshot releases of unstable. Mirror the archive. Burn a CD. Done. That's what a snapshot is. As one of the many people who does not have cheap, fast, reliable internet access, I would like to say that for me to mirror 650 MB of debian and burn a CD of it would cost around $130 in charges and 2 and a half days of straight downloading if I was lucky. Probably much longer. So I'd like snapshots, but really I run stable run until the moment frozen becomes stable at which I can get a CD on which everything has a good chance of working, because if anything breaks I'm pretty much stuffed. - = Amateur Radio, when all else fails! http://www.qsl.net/wa2mze Debian Gnu Linux, Live Free or . __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Mon, Mar 13, 2000 at 01:31:41PM +, Edmund GRIMLEY EVANS wrote: Paul M Sargent [EMAIL PROTECTED]: OK, Here's a question then. If Woody is unstable, which kernel is it running? Woody should be running 2.3 or pre-2.4. That should have been among the first things to change. I don't think so. People who are interested in debugging the kernel can install 2.3 themselves; people who are only interested in debugging Mozilla (say) don't want to have new kernel releases trashing their discs every few days. right .. and I'm testing the new kernel at this time i'm writing a short (simple) parser for traslate old isapnp to the kernel interface. This is very simple task but other can be done by developer (and i'm not such one), and no tested by user (at least if they don't need new drivers). However it's a good idea to point that new kernel exists and, soon or late, it has to be supported -- Daniele Cruciani [EMAIL PROTECTED] Check my GPG sign at ..??..
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
Josip Rodin wrote: But slink is practically completely adjusted for 2.2 already. Sure, if you ignore the 12 packages that break (http://www.debian.org/releases/stable/running-kernel-2.2) -- see shy jo
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
Eray Ozkural wrote: What happened to the package pools proposal? It's not been implemented. It's as if Debian developers are suffering from amnesia. It's easy to be amnesiac about vaporware. -- see shy jo
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Mon, Mar 13, 2000 at 08:17:00PM -0800, Joey Hess wrote: Josip Rodin wrote: But slink is practically completely adjusted for 2.2 already. Sure, if you ignore the 12 packages that break (http://www.debian.org/releases/stable/running-kernel-2.2) Most people can run 2.2 on slink without the world coming to an end. I think that calling slink practically...adjusted for 2.2 is reasonable, as upgrading packages is unnecessary in most cases and minimal in most others. -- Mike Stone pgpRsBXAwQDwm.pgp Description: PGP signature
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
Eray == Eray Ozkural [EMAIL PROTECTED] writes: Eray What happened to the package pools proposal? It's as if Debian Eray developers are suffering from amnesia. I guess the package Eray pools, as an idea at least, had found a significant appeal in Eray this list. According to some form of that proposal, what you've Eray mentioned and even better release flexibility would be Eray possible. As someone said, it remain vapourware unless someone works on it. So far, there is no implementation of that idea. Are you volunteering? ;-) I believe it is being worked on, but it is quite inchoate at the moment. manoj -- You canna change the laws of physics, Captain; I've got to have thirty minutes! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Mon, Mar 13, 2000 at 11:50:47AM +, Paul M Sargent wrote: On a side note. I'm really not sure that this 'release' stuff works on debian. Coordinating the development cycles of an infinite number of packages is impossible. What I would like to see is an unstable tree where all development is done. As packages reach maturity they 'graduate' to the stable tree. A snapshot of stable tree at any time works. The unstable tree just becomes a place for developers to share packages. The key point is a continually evolving release. As has been said before, Debian isn't commercial. It doesn't have to behave like it is with releases. well said! and you make an important point that most people overlook - that the whole commercial product style release cycle may not be thet best way for debian releases to be made. craig -- craig sanders
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Mon, Mar 13, 2000 at 09:08:43AM -0500, Ben Collins wrote: Woody should be running 2.3 or pre-2.4. That should have been among the first things to change. We are knee deep in a release cycle. We should not be expending our resources on woody right now. speak for yourself. not everyone in debian has your priorities. more to the point, your priorities are not the only valid ones. many people can (and ARE!) contribute a lot to woody, without impacting on frozen in the slightest. We should be making potato the best that it can be. Every release cycle, peoples obsession with this new thing or that latest beta is what makes the cycle so drawn out. With all of our resources we should be able to wipe out every RC bug within a day (or atleast close to all of them). The faster we get potato out the door, the sooner we can start on those nifty new things to put into woody. then fork the stable release so that those who want to focus on it exclusively can do so without being distracted by those attracted by the shiny new toys...and those who want to work on new stuff don't have to be distracted by the test freezing cycle. and some people will happily work on both. you can't force everyone to work on frozen, trying to do so is not only highly undesirable it would be completely broken and counter-productive. volunteers work on what they want, when they want, and they contribute according to their abilities and their availabile time - many have nothing that they can contribute to stable or frozen, so they work on unstable. that is good, that is as it should be. debian's release cycle persists in being so slow because people persist in seeing debian's release in the same terms as a commercial operating system. the only viable way to speed that up is to implement the package pool idea, coupled with reasonably frequent snapshot releases and less frequent but fully-tested stable releases. craig -- craig sanders
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Mon, Mar 13, 2000 at 08:17:00PM -0800, Joey Hess wrote: But slink is practically completely adjusted for 2.2 already. Sure, if you ignore the 12 packages that break (http://www.debian.org/releases/stable/running-kernel-2.2) I believe 12 out of ~2250 counts as practically completely. -- enJoy -*/\*- don't even try to pronounce my first name
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Tue, Mar 14, 2000 at 10:01:15PM +1100, Craig Sanders wrote: On Mon, Mar 13, 2000 at 09:08:43AM -0500, Ben Collins wrote: Woody should be running 2.3 or pre-2.4. That should have been among the first things to change. We are knee deep in a release cycle. We should not be expending our resources on woody right now. speak for yourself. not everyone in debian has your priorities. more to the point, your priorities are not the only valid ones. many people can (and ARE!) contribute a lot to woody, without impacting on frozen in the slightest. Direct impact yes, indirectly though, we are short on needed resources for getting potato release ready. We should be making potato the best that it can be. Every release cycle, peoples obsession with this new thing or that latest beta is what makes the cycle so drawn out. With all of our resources we should be able to wipe out every RC bug within a day (or atleast close to all of them). The faster we get potato out the door, the sooner we can start on those nifty new things to put into woody. then fork the stable release so that those who want to focus on it exclusively can do so without being distracted by those attracted by the shiny new toys...and those who want to work on new stuff don't have to be distracted by the test freezing cycle. and some people will happily work on both. Sorry that getting the next stable release out the door is such a distraction. I'll try to see if there is some way we can keep this messy part of Debian out of your way. you can't force everyone to work on frozen, trying to do so is not only highly undesirable it would be completely broken and counter-productive. volunteers work on what they want, when they want, and they contribute according to their abilities and their availabile time - many have nothing that they can contribute to stable or frozen, so they work on unstable. that is good, that is as it should be. I don't recall saying anything about forcing. Maybe you mistook encourage for force. I don't know, maybe those two words are too similar for you for some reason. Not my issue though, I still think we need to encourage people to work on frozen until it's completely out the door. debian's release cycle persists in being so slow because people persist in seeing debian's release in the same terms as a commercial operating system. the only viable way to speed that up is to implement the package pool idea, coupled with reasonably frequent snapshot releases and less frequent but fully-tested stable releases. Package pools are not an end all and frequent snapshots and less frequent stable releases are only doable when we have people working on it. Since you think that encouraging people to work on it is not ok, then I don't see how we can have the resources to do this. The only people who see Debian release cycles as commercial are the ones outside of Debian who think we need to compete and market. I don't see how that directly affects the release cycle itself. Any way, package pools wont come till after potato, since it is (and should be) still the first priority right now. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Tue, Mar 14, 2000 at 09:02:50AM -0500, Ben Collins wrote: On Tue, Mar 14, 2000 at 10:01:15PM +1100, Craig Sanders wrote: On Mon, Mar 13, 2000 at 09:08:43AM -0500, Ben Collins wrote: We are knee deep in a release cycle. We should not be expending our resources on woody right now. speak for yourself. not everyone in debian has your priorities. more to the point, your priorities are not the only valid ones. many people can (and ARE!) contribute a lot to woody, without impacting on frozen in the slightest. Direct impact yes, indirectly though, we are short on needed resources for getting potato release ready. you miss two important points. the first is that the release is not everyone's highest priority. the second is that some people have nothing to contribute to frozen/stable, so discouraging (or preventing) them from working on unstable is counterproductive. both of these points are proved by the fact that we have over 500 developers yet, according to your own words, we are short on needed resources for getting potato release ready. if everyone, or the majority...or even a substantial minority, had your priorities then that would not be the case. in any case, simply adding more people to the project won't make it happen any faster. what WILL make it faster is to fork off the stable release as a sub-project of debian, and give the release team absolute authority over the release, with the right to make NMUs of any package and make any other changes for any reason they see fit. as with any other debian initiative, any developer (or user) would be free to work on it or not as they please. also, the issue is not man-power, the issue is man-hours - i.e. how much time any of the people doing the important jobs can devote to debian. most of them have full-time jobs or are full-time students and are working on debian in their spare time. the really imporant tasks can't be sped up by some kind of time-sharing arrangement. then fork the stable release so that those who want to focus on it exclusively can do so without being distracted by those attracted by the shiny new toys...and those who want to work on new stuff don't have to be distracted by the test freezing cycle. and some people will happily work on both. Sorry that getting the next stable release out the door is such a distraction. I'll try to see if there is some way we can keep this messy part of Debian out of your way. it doesn't distract me at all. i mostly ignore it these days as it is of little or no relevance to me. like many others, i am perfectly happy with the real debian (i.e. the live development version aka unstable) as it has served my needs extremely well on production servers and workstations for 5+ years. in other words, empirical evidence over the years has shown that the distinction between stable and unstable is not only irrelevant, it is an arbitrary falsehood. this same empirical evidence has also proved that 'stable' is LESS stable and reliable and secure than 'unstable'. the few debian boxes which i know of that have been compromised were cracked BECAUSE they were still running stable and had older versions of various programs which had known security holes. the main reason they were still running stable is because they didn't have fast, reliable internet connections - i.e. if regular snapshot CDs were available, they would have been up to date. i would like to see the real debian become more accessible to the general public, and the way to do that is to make frequent snapshot CD images. I don't recall saying anything about forcing. Maybe you mistook encourage for force. no, i didn't. i simply put your current remarks in context with other statements of yours in the past, where you have been an advocate of the insane idea that unstable should be closed down between the freeze and the release. Not my issue though, I still think we need to encourage people to work on frozen until it's completely out the door. fine, keep on with the encouragements. just keep the shoulds and should nots in check. they are shrill and irritating. Package pools are not an end all and frequent snapshots and less frequent stable releases are only doable when we have people working on it. one person can do a snapshot release in a day or so - that's the point...it's an untested snapshot of unstable as it is at that moment in time. use at your own risk, just like unstableand just like 'stable' - we don't after all, offer any guarantee for stable. there's no need to even make new base/install disks for a snapshot release - the old ones from the previous stable release will be adequate...just install those and then upgrade to the snapshot. the stable releases will, of course, still take time to test and to produce new boot-floppies. however, that time will be reduced because some of the testing will already have been done by people using the snapshots. Since you think that encouraging
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Wed, Mar 15, 2000 at 08:42:07AM +1100, Craig Sanders wrote: this same empirical evidence has also proved that 'stable' is LESS stable and reliable and secure than 'unstable'. the few debian boxes which i know of that have been compromised were cracked BECAUSE they were still running stable and had older versions of various programs which had known security holes. Uh, which were the packages in question? Did you report it at the time? -- enJoy -*/\*- don't even try to pronounce my first name
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Tue, Mar 14, 2000 at 11:02:20PM +0100, Josip Rodin wrote: On Wed, Mar 15, 2000 at 08:42:07AM +1100, Craig Sanders wrote: this same empirical evidence has also proved that 'stable' is LESS stable and reliable and secure than 'unstable'. the few debian boxes which i know of that have been compromised were cracked BECAUSE they were still running stable and had older versions of various programs which had known security holes. Uh, which were the packages in question? Did you report it at the time? no need, the holes were already well known - and fixed in unstable. security is one of the main reasons i run unstable and upgrade regularly...script kiddies may be stupid, but they are capable of running an exploit written by someone else - so you have to keep at least a few months ahead of them. running unstable is not a 100% guarantee of security (nothing is or can be)...however, in practice there is only a few days (at most) window of opportunity between an exploit becoming known and my servers being secured against it. all i have to do is login with ssh and run apt-get to upgrade. craig -- craig sanders
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
Well, it's really sad that you like to dredge up year old context for this thread to suit your mundane arguments, they have little context with what I was saying. resources on woody right now. speak for yourself. not everyone in debian has your priorities. more to the point, your priorities are not the only valid ones. many people can (and ARE!) contribute a lot to woody, without impacting on frozen in the slightest. Direct impact yes, indirectly though, we are short on needed resources for getting potato release ready. you miss two important points. the first is that the release is not everyone's highest priority. the second is that some people have nothing to contribute to frozen/stable, so discouraging (or preventing) them from working on unstable is counterproductive. Once can argue that the reason is because they don't know how they can help. Everyone within Debian has a stake in frozen, simply by being a member, and every can help. There is nothing preventing that. both of these points are proved by the fact that we have over 500 developers yet, according to your own words, we are short on needed resources for getting potato release ready. if everyone, or the majority...or even a substantial minority, had your priorities then that would not be the case. First of all, you need to check your numbers. Last I checked there were ~350 official developers in the keyring. Right, so this proves my point in that we should encourage developers to put a priority on frozen and the next release cycle. And please stop refering to stable. That is not my main concern here, and I never brought it into this conversation. in any case, simply adding more people to the project won't make it happen any faster. what WILL make it faster is to fork off the stable release as a sub-project of debian, and give the release team absolute authority over the release, with the right to make NMUs of any package and make any other changes for any reason they see fit. as with any other debian initiative, any developer (or user) would be free to work on it or not as they please. How would that help? That is simply a superficial thing. Calling it a seperate project would do nothing to improve the situation. Plus that creates havoc with changes made to the frozen release that aren't in unstable. So we get split bug reports and a lot of other crazy things. also, the issue is not man-power, the issue is man-hours - i.e. how much time any of the people doing the important jobs can devote to debian. most of them have full-time jobs or are full-time students and are working on debian in their spare time. the really imporant tasks can't be sped up by some kind of time-sharing arrangement. Ok, let's play word games. Man-hours is a direct result of man-power. Everyone in Debian only has but so many hours than can put into the project, so increasing each developers time in the project is not an option. So we encourage developers to spend their time that they have to projects for the next stable release. then fork the stable release so that those who want to focus on it exclusively can do so without being distracted by those attracted by the shiny new toys...and those who want to work on new stuff don't have to be distracted by the test freezing cycle. and some people will happily work on both. Sorry that getting the next stable release out the door is such a distraction. I'll try to see if there is some way we can keep this messy part of Debian out of your way. it doesn't distract me at all. i mostly ignore it these days as it is of little or no relevance to me. Safe to say, that is a really self-centered attitude. One which I hope that most developers don't have. Not a very team oriented situation if everyone felt that way. like many others, i am perfectly happy with the real debian (i.e. the live development version aka unstable) as it has served my needs extremely well on production servers and workstations for 5+ years. in other words, empirical evidence over the years has shown that the distinction between stable and unstable is not only irrelevant, it is an arbitrary falsehood. this same empirical evidence has also proved that 'stable' is LESS stable and reliable and secure than 'unstable'. the few debian boxes which i know of that have been compromised were cracked BECAUSE they were still running stable and had older versions of various programs which had known security holes. the main reason they were still running stable is because they didn't have fast, reliable internet connections - i.e. if regular snapshot CDs were available, they would have been up to date. i would like to see the real debian become more accessible to the general public, and the way to do that is to make frequent snapshot CD images. Another sad situation. Sad because you feel that it is better to forget the harder situations, and simply deal with the
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Tue, Mar 14, 2000 at 11:02:20PM +0100, Josip Rodin wrote: On Wed, Mar 15, 2000 at 08:42:07AM +1100, Craig Sanders wrote: this same empirical evidence has also proved that 'stable' is LESS stable and reliable and secure than 'unstable'. the few debian boxes which i know of that have been compromised were cracked BECAUSE they were still running stable and had older versions of various programs which had known security holes. Uh, which were the packages in question? Did you report it at the time? And were they keeping up with packages on security.debian.org meant specifically for the stable release? -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Wed, Mar 15, 2000 at 09:18:00AM +1100, Craig Sanders wrote: this same empirical evidence has also proved that 'stable' is LESS stable and reliable and secure than 'unstable'. the few debian boxes which i know of that have been compromised were cracked BECAUSE they were still running stable and had older versions of various programs which had known security holes. Uh, which were the packages in question? Did you report it at the time? no need, the holes were already well known - and fixed in unstable. Security fixes have to be (and are) fixed in stable, too! -- enJoy -*/\*- don't even try to pronounce my first name
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Tue, Mar 14, 2000 at 05:27:26PM -0500, Ben Collins wrote: it doesn't distract me at all. i mostly ignore it these days as it is of little or no relevance to me. Safe to say, that is a really self-centered attitude. One which I hope that most developers don't have. Not a very team oriented situation if everyone felt that way. OTOH (to play devil's advocate) the stable process seems to continually get bogged down. Slipping deadlines, inappropriate package upgrades, etc., begin to make things seem hopeless. When push comes to shove, things usually get done--but what's the push right now? -- Mike Stone pgpL3uVBScuka.pgp Description: PGP signature
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
Paul M Sargent [EMAIL PROTECTED]: OK, Here's a question then. If Woody is unstable, which kernel is it running? Woody should be running 2.3 or pre-2.4. That should have been among the first things to change. I don't think so. People who are interested in debugging the kernel can install 2.3 themselves; people who are only interested in debugging Mozilla (say) don't want to have new kernel releases trashing their discs every few days. On a side note. I'm really not sure that this 'release' stuff works on debian. Coordinating the development cycles of an infinite number of packages is impossible. What I would like to see is an unstable tree where all development is done. As packages reach maturity they 'graduate' to the stable tree. A snapshot of stable tree at any time works. The unstable tree just becomes a place for developers to share packages. I made roughly this point in a message that seems not to have reached the list. Where there are no complex dependencies, there is no need for packages to be released (i.e. declared stable) simultaneously. I suggested creating a stable-test branch containing packages that are built to run on stable without breaking anything in stable or stable-test. When a package maintainer is confident that the version in stable-test is in every way superior to the version in stable he asks the release manager to move that package from stable-test to stable. (I'm not sure how the version numbering would work, but no doubt a numbering scheme could be invented.) Edmund
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Mon, Mar 13, 2000 at 11:50:47AM +, Paul M Sargent wrote: Woody should be running 2.3 or pre-2.4. That should have been among the first things to change. There's a misunderstanding here: the distribution has no default kernel, the boot floppies do. Since nobody is working on woody boot floppies (why should they?), there is no default kernel for woody, it's all inherited from potato. But anyway, as I said before, a newer kernel source should be available as package. Coordinating the development cycles of an infinite number of packages is impossible. [...] The key point is a continually evolving release. Something like this will be possible when the package pools are implemented... -- enJoy -*/\*- don't even try to pronounce my first name
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Mon, Mar 13, 2000 at 02:50:12PM +0100, Josip Rodin wrote: On Mon, Mar 13, 2000 at 11:50:47AM +, Paul M Sargent wrote: Woody should be running 2.3 or pre-2.4. That should have been among the first things to change. There's a misunderstanding here: the distribution has no default kernel, the boot floppies do. Since nobody is working on woody boot floppies (why should they?), there is no default kernel for woody, it's all inherited from potato. ...but a distribution is designed for a particular kernel. e.g. slink is designed for 2.0.x with some packages for 2.2.x support. Supporting a kernel is not as much about the kernel package itself, but about the tools which surround it. Classic examples are thing like mount, or binutils. If the kernel isn't even in the archive then potential problems aren't going to be found. Paul P.S. I missed the discussion on package pools. What's the theory? -- Paul Sargent mailto: [EMAIL PROTECTED]
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
Woody should be running 2.3 or pre-2.4. That should have been among the first things to change. We are knee deep in a release cycle. We should not be expending our resources on woody right now. We should be making potato the best that it can be. Every release cycle, peoples obsession with this new thing or that latest beta is what makes the cycle so drawn out. With all of our resources we should be able to wipe out every RC bug within a day (or atleast close to all of them). The faster we get potato out the door, the sooner we can start on those nifty new things to put into woody. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Mon, Mar 13, 2000 at 01:43:46PM +, Paul M Sargent wrote: Woody should be running 2.3 or pre-2.4. That should have been among the first things to change. There's a misunderstanding here: the distribution has no default kernel, the boot floppies do. Since nobody is working on woody boot floppies (why should they?), there is no default kernel for woody, it's all inherited from potato. ...but a distribution is designed for a particular kernel. e.g. slink is designed for 2.0.x with some packages for 2.2.x support. Supporting a kernel is not as much about the kernel package itself, but about the tools which surround it. But slink is practically completely adjusted for 2.2 already. IIRC, Sparc people needed a new glibc and a new kernel for slink, and that pulled in overall support for 2.2 in packages like mount or similar. If the kernel isn't even in the archive then potential problems aren't going to be found. I wouldn't put that much `weight' in the fact that kernel is in the archive: kernel packages don't get upgraded to new upstream versions, so if you want a new kernel, you have to make the decision to install it, on your own. Having the kernel in the archive is convenient for those with limited network access, using stable, or a snapshot of unstable. P.S. I missed the discussion on package pools. What's the theory? Implement a database for managing the FTP archive that would make lots of nifty things available... search the Debian Weekly News or debian-devel archives for details. -- enJoy -*/\*- don't even try to pronounce my first name
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Mon, Mar 13, 2000 at 09:08:43AM -0500, Ben Collins wrote: Woody should be running 2.3 or pre-2.4. That should have been among the first things to change. We are knee deep in a release cycle. We should not be expending our resources on woody right now. Ohh, Agreed. Potato is number one. No question. We should be making potato the best that it can be. Every release cycle, peoples obsession with this new thing or that latest beta is what makes the cycle so drawn out. All I was saying was that 'that new thing' should be included in the unstable tree as soon as possible. Add things early, not late in the release cycle. That way the most water is under the bridge by the time the release comes. I doubt every one is working on Potato. To those people who are working on Woody I would say 'don't wait for the upstream developers to say things are finished before you put them in.' If anything I'm trying to back you up, don't mess with Potato. Save it all for woody, but get it in early. Paul -- Paul Sargent mailto: [EMAIL PROTECTED]
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Mon, Mar 13, 2000 at 03:30:53PM +0100, Josip Rodin wrote: On Mon, Mar 13, 2000 at 01:43:46PM +, Paul M Sargent wrote: ...but a distribution is designed for a particular kernel. e.g. slink is designed for 2.0.x with some packages for 2.2.x support. But slink is practically completely adjusted for 2.2 already. I know, that's what I ment. I was just saying there is some interdependancy. I didn't mean in infer that slink didn't do 2.2. I know it does, I've used it. If the kernel isn't even in the archive then potential problems aren't going to be found. I wouldn't put that much `weight' in the fact that kernel is in the archive: kernel packages don't get upgraded to new upstream versions, so if you want a new kernel, you have to make the decision to install it, on your own. But don't you think it's good to have the base system in place as soon as possible for a new development cycle. It's putting a stake in the ground. If somebody sees kernel-image-2.3.58 in the archive then it suggests they should be giving it a go. That's good in my book because it's nearer the final target than 2.2.x. I apprecate your point that most developer would roll their own, but I'd view it almost as a statement of intent. Maybe I'm getting irrational. For now, on with Potato! Paul -- Paul Sargent mailto: [EMAIL PROTECTED]
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Mon, Mar 13, 2000 at 03:04:26PM +, Paul M Sargent wrote: If the kernel isn't even in the archive then potential problems aren't going to be found. I wouldn't put that much `weight' in the fact that kernel is in the archive: kernel packages don't get upgraded to new upstream versions, so if you want a new kernel, you have to make the decision to install it, on your own. But don't you think it's good to have the base system in place as soon as possible for a new development cycle. It's putting a stake in the ground. If somebody sees kernel-image-2.3.58 in the archive then it suggests they should be giving it a go. Hm, yes, I agree, it has a psycological effect. OTOH, maybe we don't want to put that stake into the ground until potato has been released, for obvious reasons. -- enJoy -*/\*- don't even try to pronounce my first name
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
We should be making potato the best that it can be. Every release cycle, peoples obsession with this new thing or that latest beta is what makes the cycle so drawn out. All I was saying was that 'that new thing' should be included in the unstable tree as soon as possible. Add things early, not late in the release cycle. That way the most water is under the bridge by the time the release comes. I doubt every one is working on Potato. To those people who are working on Woody I would say 'don't wait for the upstream developers to say things are finished before you put them in.' If anything I'm trying to back you up, don't mess with Potato. Save it all for woody, but get it in early. But you are missing the point. You are encouraging people to work on woody, when in fact we should all be focused on potato. You are also encouraging another practice which tends to upset some upstream developers. By adding in packages of versions that upstream does not consider stable, they end up contending with luser bug reports on features that are incomplete. We've had this problem in the past, we don't want to get into again. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
Paul M Sargent wrote: On a side note. I'm really not sure that this 'release' stuff works on debian. Coordinating the development cycles of an infinite number of packages is impossible. What I would like to see is an unstable tree where all development is done. As packages reach maturity they 'graduate' to the stable tree. A snapshot of stable tree at any time works. The unstable tree just becomes a place for developers to share packages. What happened to the package pools proposal? It's as if Debian developers are suffering from amnesia. I guess the package pools, as an idea at least, had found a significant appeal in this list. According to some form of that proposal, what you've mentioned and even better release flexibility would be possible. The key point is a continually evolving release. As has been said before, Debian isn't commercial. It doesn't have to behave like it is with releases. With a proper package pools system, Debian will have decoupled its archive structure from its logical structure. Well, not that innovative but a *linux*.com company would certainly push it as a technological advantage. It would seem that the independence of releases from actual archive content would lead to the possibility of avoiding the current rock-stable-and-completely-outdated stable and scary-and-top-notch-unstable release cycle. People could then prepare debian releases at some point between the two extremes. What is more, I think developers could organize themselves as teams, who try to maintain sub-releases for sub-systems. I think that kind of a flexible, and *distributed* release management is pretty open-ended. That seems to be the right way to motivate 500+ people working on such a large thing. To make this work major changes would have to be coordinated, but there is no reason that a major Perl change has to impact a major X change. Base packages like libc become more tricky though. Absolutely. While debian stable has a great QA, people *who do not run it on their spacecraft* will eventually yearn for the latest software. However, they will find the unstable distribution dangling to their disappointment. For instance, I've had some months of insanity due to a mysterious breakage of printing tools in potato. Few would then dare to make an upgrade to unstable. That is, you would certainly like some consistency and reliability, but not at the cost of missing a huge proportion of good software out there. That's what distribution is all about, right? Giving people some choices. Paul -- Paul Sargent mailto: [EMAIL PROTECTED] __ exa Eray Ozkural, CS, Bilkent Univ.
