Re: Crazy idea: removing version numbers from debian
Previously Thomas Guettler wrote: > Eric: > >Better yet, don't put packages into stable until we release. "Stable" > >has a fairly well-defined meaning; I don't see much benefit from changing > >it. We already do that. > I am new to debian-dev, why not release stable packages daily? > Why in a single step? Because you can't test the new complete system that way. > That's true. One solution would be to give the boot-floppies and related > things the version number 2.2. The rest could be floating. That won't help much, you still have an essentialy completely floating system except for a really smart part. > BTW, I even think the CD-Vendors would sell more CDs with a floating > system. Maybe, but their margins would be too small to make it viable. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Crazy idea: removing version numbers from debian
Thank you for your answers. Some misunderstood my idea, I don't want to remove version numbers from packages. Bernd: >How do u call slink? "Old Stable"? :) Yes, "old_stable" or "past" Bernd: >No i think it is not a bad idea to have a version number. The only question >is if the Version number should cover the whole distribution (including >contrib, non-free, non-US,...) or only the base section (like with FreeBSD). Yes, that what I had in mind, too. I would apply 2.2 only to the base section and the other packages should keep their version numbers. Vincent: >New packages would not be allowed into stable until x days had passed in >unstable status without a Release Critical Bug. What about a doing things like this on a feedback basis? After a package was installed on your computer successfully, you get asked if you want to send a sucess-feedback. After N positiv feedbacks the package gets stable. Vincent: >Finally the idea I like the best is no numbers, only named updates I think you still need to distinguish between foo_pack1.2-stable1 foo_pack1.2-stable2 Eric: >Better yet, don't put packages into stable until we release. "Stable" >has a fairly well-defined meaning; I don't see much benefit from changing >it. I am new to debian-dev, why not release stable packages daily? Why in a single step? Colins: >Those who do not understand ajt's "testing" distribution are doomed to >reinvent it, poorly. :) OK, I will RTFM, I hope there is some. Wichert: >Also, having versioned released is something that CD vendors want to >have. If we only had an ever changing semi-stable they could only sell >snapshots, which means they can't produce a large number of CDs, costs >will go up and they will switch to selling CDs of other distributions >instead. That's true. One solution would be to give the boot-floppies and related things the version number 2.2. The rest could be floating. BTW, I even think the CD-Vendors would sell more CDs with a floating system. I ordered Debian 2.2 in january, now it's nearly september. If I would have got them at once, I would maybe buy my next CDs now (don't like downloading netscape with a modem connection). -- Thomas Guettler Office: www.interface-business.de Private: http://yi.org/guettli (Replace _NoSpam_ with @)
Re: Crazy idea: removing version numbers from debian
On Wed, Aug 30, 2000 at 11:58:22AM -0500, Vincent L. Mulhollon wrote: > Perhaps any package can live in unstable, but any package that has a > release critical bug older than 1 week is zapped from stable and placed back > in unstable. Upon next package upload, it will be reinstated into stable. That wont help very much because the users who have installed the package will have the buggy version anyway. On the other hand disappearing and reappearing packages (especially in the stable distribution) will confuse the users and break dependencies. Bugs in stable packages are bad, but as long as they are no security related or data corrupting bugs we have to live with them. For security or data corrupting bugs we have to use out of band methods for pushing fixes/warnings anyway. Of course in that case it might be wort to actually plug the unfixed packages from the distribution to avoid bad informed/educated usrs to run into a trap. Greetings Bernd
Re: Crazy idea: removing version numbers from debian
"Vincent L. Mulhollon" <[EMAIL PROTECTED]> wrote: >I had a similar thought this weekend. > >Perhaps any package can live in unstable, but any package that has a >release critical bug older than 1 week is zapped from stable and placed back >in unstable. Upon next package upload, it will be reinstated into stable. > >New packages would not be allowed into stable until x days had passed in >unstable status without a Release Critical Bug. [etc.] Those who do not understand ajt's "testing" distribution are doomed to reinvent it, poorly. :) -- Colin Watson [EMAIL PROTECTED]
Re: Crazy idea: removing version numbers from debian
Previously Thomas Guettler wrote: > Debian is evolving constantly, not in single steps. True. > But I am interested > what you think about this crazy idea to remove > version numbers (like debian2.2) from debian? Won't work. Users demand a know really stable system, and with a dynamic system we can't guarantee the same stability as we can with a release that has been tested for a while without any updates which might mess up testing. Also, having versioned released is something that CD vendors want to have. If we only had an ever changing semi-stable they could only sell snapshots, which means they can't produce a large number of CDs, costs will go up and they will switch to selling CDs of other distributions instead. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgp5OPPLqc8ZM.pgp Description: PGP signature
Re: Crazy idea: removing version numbers from debian
[EMAIL PROTECTED] (Vincent L. Mulhollon) writes: > Perhaps any package can live in unstable, but any package that has a > release critical bug older than 1 week is zapped from stable and placed back > in unstable. Upon next package upload, it will be reinstated into stable. Ack! Can you imagine what would happen under that system with a package whose bugs are not handled that quickly? The version in stable would be $foo, next week it's $foo.1, a week later it's $foo again because of a RC bug filed in week 1, another week passes and the bug is fixed, so it's $foo.1 again. Not to mention we'd have to start supporting downgrades as well as upgrades (although I'm a new developer, I'm fairly sure we don't do that). > New packages would not be allowed into stable until x days had passed in > unstable status without a Release Critical Bug. Then someone files one when the maintainer's on vacation, nobody has time to do a NMU, and it pops back into unstable. Ick. > Or perhaps any package can live in unstable, and every package has a copy of > itself in unstable, but on the last day of the month it is kicked out of > stable if it has an open RCB. If you are picky about RCBs, only apt-get > stable on the first of the month. What if a RC bug is filed the day before the deadline? Last day of the month hits, users apt-get dist-upgrade and then are faced with having to downgrade their software. > If you need a buggy package anyway, get it out of unstable. Better yet, don't put packages into stable until we release. "Stable" has a fairly well-defined meaning; I don't see much benefit from changing it. > In theory this would complicate support because there would be so many > "versions" of debian, yet developers survive with "daily" versions... But because those "daily" versions are numbered, we know that the version we're getting is the latest (or not, as we choose). How do you tell somebody "I know that was fixed in the version I uploaded last week; don't download today's though, as it's known buggy" without using version numbers? You could use dates, but that can get hideously complicated very quickly. > Finally the idea I like the best is no numbers, only named updates. See above. Numbers make a lot of things easier. > And we'd have a goal for the name. Like the goal for "whiskey" release > would be every package that needs it supports debconf, or the goal for > "vodka" is every package supports kernel 2.4 and IPv6, or the goal for > "scotch" is every package supports perl 5.6 or whatever. A great idea. But can't we do that now? -=Eric -- Any philosophy that can be put in a nutshell belongs there. -- Sydney J. Harris
Re: Crazy idea: removing version numbers from debian
Thomas Guettler wrote: > But I am interested > what you think about this crazy idea to remove > version numbers (like debian2.2) from debian? It's really crazy. Removing version numbers mean that the dependency graph must be synchronized globally which is impossible AFAIK. In addition to this, it renders the package pools idea essentially useless, which is the sane thing that is needed. :) A better idea would be to perhaps indicate symbolically the usability level of the package in the binary format. That might give users some convenience, I dunno. I have a lot of crazier ideas about distribution, release management and package classification so keep these mental inventions coming. :) This is exactly the place to discuss these. Thanks, -- -+++-+++-++-++-++--+---++- --- -- - - + Eray "exa" Ozkural . . . . . . + CS, Bilkent University, Ankara ^ . o . . | mail: [EMAIL PROTECTED]. ^ . .
Re: Crazy idea: removing version numbers from debian
> A Debian package is either unstable, (testing) or stable. > And everybody should use the package that fits his needs. > > Debian is evolving constantly, not in single steps. > > But I am interested > what you think about this crazy idea to remove > version numbers (like debian2.2) from debian? > I had a similar thought this weekend. Perhaps any package can live in unstable, but any package that has a release critical bug older than 1 week is zapped from stable and placed back in unstable. Upon next package upload, it will be reinstated into stable. New packages would not be allowed into stable until x days had passed in unstable status without a Release Critical Bug. Or perhaps any package can live in unstable, and every package has a copy of itself in unstable, but on the last day of the month it is kicked out of stable if it has an open RCB. If you are picky about RCBs, only apt-get stable on the first of the month. If you need a buggy package anyway, get it out of unstable. Or perhaps any package lives in unstable, and instead of kicking packages out of stable if it has a RCB, the BTS would interact such that the author or "someone trusted" can specify the newest "old" version that does not have the bug. There are events like libc upgrades where pretty much everything needs to be recompiled. This issue must be dealt with. In theory this would complicate support because there would be so many "versions" of debian, yet developers survive with "daily" versions... Finally the idea I like the best is no numbers, only named updates. And we'd have a goal for the name. Like the goal for "whiskey" release would be every package that needs it supports debconf, or the goal for "vodka" is every package supports kernel 2.4 and IPv6, or the goal for "scotch" is every package supports perl 5.6 or whatever.
Re: Crazy idea: removing version numbers from debian
On Wed, Aug 30, 2000 at 05:05:58PM +0200, Thomas Guettler wrote: > But I am interested > what you think about this crazy idea to remove > version numbers (like debian2.2) from debian? How do u call slink? "Old Stable"? :) No i think it is not a bad idea to have a version number. The only question is if the Version number should cover the whole distribution (including contrib, non-free, non-US,...) or only the base section (like with FreeBSD). But since we do not have yet another distribution schema, I think our current practice ov giving version and release numbers is the best. This is especially for CD Manucatureres and Security Admin important. It is also important if you want to talk about events in the past. Greetings Bernd
