Re: how about a real unstable?
On Thu, Mar 30, 2000 at 01:30:58PM -0600, Zed Pobre wrote: This started me thinking. Someone earlier lamented the difficulties in using experimental. I would like to see experimental moved into the same tree as stable, frozen, unstable and have a Packages file generated. experimental already has a Packages file generated, and where it is in the tree is more or less irrelevant. New packages (and perhaps all new upstream releases) would be autoinstalled into experimental until they had been there for a month This gets rid of the main use of experimental which is to distinguish packages that'll probably destroy your system, against ones that shouldn't but might because, well, anything's *possible*. (or someone could get to the overrides file for unstable, whichever is longer), and packages with Grave or worse bugs open longer than a week (or maybe 2 weeks) would be moved there. A different way of doing it is to leave unstable as it is (ie, new packages get lumped into unstable whether they work or not, assuming they're not /likely/ to trash your system), and instead add a new distribution inbetween stable and unstable, that has some of the properties of stable (ie, packages have more or less stabilised, they've been tested for a while, they've got few/no RC bugs, they work on all architectures, packages don't have huge dependency problems). Particularly the latter of these is a fairly complicated technical problem to solve. Exercise to the interested reader: try it at home. Implement your solution. Time it. Try to optimise it. (20pts) For the less interested reader, point your browser at http://auric.debian.org/~ajt/. For the reader who doesn't give a stuff and just wants to cut to the chase, point apt at, hopefully, deb http://auric.debian.org/~ajt/ testing main . It's still very alpha, and relies heavily on the autobuilders being up to date against woody, which isn't the case while we're frozen. As such, please be wary of mirroring this: when we think it's really worth the effort of mirroring it'll probably go into /pub/debian/dists, and until then, it's quite probably a waste of bandwidth. Source is theoretically available, but only by ssh'ing to auric and poking around in my home directory. This would allow lintian checks to become a prerequisite for unstable, especially now that developers can write their own overrides for special cases. Someone would need to go through all the lintian checks and see which ones are actually worth making RC. Not all of them are by a long shot. personally, i'm not going to hold my breath waiting for the stable release cycle to speed up. it's a big job, and one that grows enormously for every release. we had around 2000 packages for slink. we now have approx 4000 for potatoand already nearly 5000 for woody - and potato isn't even out the door! One of the things that might help this would be continuous freeze. As soon as a release is made, whatever is in unstable at that moment is frozen for the next release. This will become more feasable as package graduation becomes more refined, I think. Note that I at least, refuse to fork my packages during the freeze. It's just too painful to work with. I've been around for less than half that, but I do remember a nasty bash/libreadline bug that flattened a number of systems that I would not have wanted to encounter on a production system, as well as a few X problems. Furthermore, I would not want to deal with an application server running unstable. While I admit that the quality of Debian packages is generally quite high even in unstable, I would remain rather wary of recommending it for production servers. There was a cute grep bug a while ago too, that made grep simply not work if you specified the files to grep on the command line (or the other way around, I forget). There are lots of cute bugs around in unstable now and then, but they're generally easy to recover from if you have a clue. If you don't want to have to have a clue for production servers (and I for one don't), well, that's what stable's for. Possibly, it'll also be what `testing' will be for, up to a point, when and if it actually works. BTW, I've been thinking recently. The original point of `testing' was to make it easier for us to release (you've got a whole semi-unstable distribution that's up-to-date and more or less bugfree from the word go. No more bug horizons, just a few finishing touches, some organised testing on the final product, and voila!), and hence make it easier for us to release more often. I wonder, though, if that's really a good idea. At some point, frequent releases are just a downright pain, even with Debian's fetish towards in-place and partial upgradability. Maybe it'd be better to just keep releasing once-a-year or so (with any extra security-fixes), and let people who really want new packages upgrade to testing. As opposed to making a release every three,
Re: how about a real unstable?
John Haggerty [EMAIL PROTECTED] writes: Plus integrating the e2compr kernel patch into the standard kernels provided with debian would also be a plus. As an alternative, I'll release a kernel-patch-e2compr package in a couple of days. Put the following in /etc/apt/sources.list (if you don't already have one of the other e2compr apt sources there): deb http://e2compr.memalpha.cx/e2compr/ftp/apt binary-i386/ deb-src http://e2compr.memalpha.cx/e2compr/ftp/apt source/ pjm.
Re: how about a real unstable?
On Tue, Mar 28, 2000 at 02:14:39PM -0500, Elie Rosenblum wrote: On Tue, Mar 28, 2000 at 09:09:43AM -0800, Andrew Lenharth wrote: It is the unstable branch, lets take advantage of it and make it unstable to start out with. The sooner we can find problems and fix them, the shorter our release cycles will be, and the more upto-date our main packages will be. This is what experimental is for, no? Unstable is for unstable Debian, not necessarily unstable software. The experimental distribution is much more appropriate for unstable upstream software. i agree. the proposal would do nothing for 'stable', it would only make 'unstable' unusable - so we'd be left with an ancient and obsolete 'stable' release and a useless 'unstable'. the stable release cycle is slow because it's a big job to test thousands of packages. deliberately making unstable more dangerous isn't going to solve that problem, it's going to make it worse - and at the same time increase the pressure on the release team. the only thing that is likely to speed up the release cycle is the rolling release part of the package-pools ideawhich, if you examine how it is supposed to work, actually works by making unstable MORE stable, not less - packages only get promoted from incoming/holding to unstable when they pass certain tests (e.g. lintian test, all dependancies met, no bug reports for XX days)...and they only get promoted from unstable to frozen when they pass more tests. in other words, it automates as much of the job as is possible. personally, i'm not going to hold my breath waiting for the stable release cycle to speed up. it's a big job, and one that grows enormously for every release. we had around 2000 packages for slink. we now have approx 4000 for potatoand already nearly 5000 for woody - and potato isn't even out the door! i'm glad i don't have to wait. unstable is more than good enough for use on production servers (and has been the entire time i've been using debian - almost 5 years now) craig -- craig sanders
Re: how about a real unstable?
On Tue, Mar 28, 2000 at 01:48:01PM -0800, Sean 'Shaleh' Perry wrote: This is what experimental is for, no? Unstable is for unstable Debian, not necessarily unstable software. The experimental distribution is much more appropriate for unstable upstream software. experimental is for *really* unstable software. Software that's actually likely to wreck your system to the point you'll need to actually use those backup things everyone regularly makes. The new XFree probably fits here, since for a lot of people wrecking X is more than enough to wreck their system, subjectively. Things like netfilter or kernel-2.3.99, probably aren't, since at worst you can just setup lilo (or whatever) to boot back to your old kernel, and keep using all your old tools. Whether people have the time and inclination to package these things, though, is another matter. agreed with the addition that experimental must also be apt'able. Erm, it is though. deb http://some.debian.mirror/debian project/experimental/ IIRC, it's even setup so that if you add that to your sources.list, apt-get dist-upgrade *won't* automatically choose packages from there when you tell it to do an apt-get dist-upgrade; it'll only use it for packages you specifically select with apt-get install. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds pgpRAkxrlnm1A.pgp Description: PGP signature
Re: how about a real unstable?
On Tue, Mar 28, 2000 at 01:48:01PM -0800 , Sean 'Shaleh' Perry wrote:
This is what experimental is for, no?
Unstable is for unstable Debian, not necessarily unstable software. The
experimental distribution is much more appropriate for unstable upstream
software.
agreed with the addition that experimental must also be apt'able. Getting
it is.
Petr Cech
--
Debian GNU/Linux maintainer - www.debian.{org,cz}
[EMAIL PROTECTED]
Re: how about a real unstable?
On Wed, Mar 29, 2000 at 08:19:18AM +0200, Petr Cech wrote: This is what experimental is for, no? Unstable is for unstable Debian, not necessarily unstable software. The experimental distribution is much more appropriate for unstable upstream software. agreed with the addition that experimental must also be apt'able. it is. grep experimental /etc/apt/sources.list, please? -- Digital Electronic Being Intended for Assassination and Nullification
Re: how about a real unstable?
On Wed, Mar 29, 2000 at 12:13:45PM +0200 , Josip Rodin wrote:
grep experimental /etc/apt/sources.list, please?
deb http://samosa.debian.org/debian/project/experimental/ /
Petr Cech
--
Debian GNU/Linux maintainer - www.debian.{org,cz}
[EMAIL PROTECTED]
Re: how about a real unstable?
On Wed, Mar 29, 2000 at 12:08:31PM +0200, Petr Cech wrote: grep experimental /etc/apt/sources.list, please? deb http://samosa.debian.org/debian/project/experimental/ / Here's a prettier one, as discussed on IRC :) deb http://ftp.debian.org/debian/ project/experimental/ -- Digital Electronic Being Intended for Assassination and Nullification
Re: how about a real unstable?
I second this. I can't tell you how many times I have had to get the source to something try to get it to compile and bang my head on the computer for 10 hours trying to get it to work. Having say the newest version of blackbox would be nice as well as some of the newer kernels, the newest Xemacs and other aditions. Plus integrating the e2compr kernel patch into the standard kernels provided with debian would also be a plus. On Tue, 28 Mar 2000, Andrew Lenharth wrote: I know others have expressed this, but a big reason we wind up with slower release cycles is we have a stable unstable. i.e. unstable is rather stable. Most of the other distributions start with the software that will be released by the time they release and start working with it early. What I really mean: unstable should (as soon as work on potato is finished), have the new perl, xfree, apache, kernel, etc. Even if they are still release canidates. the sooner we have everything working with the new packages, the sooner we can release. For example, to wait till perl 5.6 is out to try to integrate it could take longer that to start the integration process with a perl release canidate. It is the unstable branch, lets take advantage of it and make it unstable to start out with. The sooner we can find problems and fix them, the shorter our release cycles will be, and the more upto-date our main packages will be. Andrew Lenharth Remember, never ask a geek why; just nod your head and back away slowly... -- Given infinite time, 100 monkeys could type out the complete works of Shakespeare. Win 98 source code? Eight monkeys, five minutes. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how about a real unstable?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew == Andrew Lenharth [EMAIL PROTECTED] writes: [...] Andrew It is the unstable branch, lets take advantage of it and make it unstable Andrew to start out with. The sooner we can find problems and fix them, the Andrew shorter our release cycles will be, and the more upto-date our main Andrew packages will be. Two reasons why this is generally not a good idea: + I'd guess for many developers their working machine is also their development machine. So, if they can't run unstable (because it is) on their working machine, they can't run unstable, period. Which would likely cause them to have to quit... + What if the release candidate of, say, perl 5.6 is *still* a release candidate when *we* want to release? Because we'd have adapted the whole system to perl 5.6... we couldn't release until 5.6'd be stable. This would cause us to be tied to the release schedules of external projects. Which'd be a bad thing. On the other hand, Debian's already working like that *in some areas*... like, for a long time the `zsh' package was the unstable development version; it still is, but there's a zsh30 package which contains the stable release. What I mean is: we can *start* integration of unstable packages early... but we cannot tie the system to these unstable releases, we still have to build on the stable releases. All this depends on the respective maintainers ability (mostly in terms of time available) and willingness to do the work, that's about all there is to it... Bye, J - -- Jürgen A. Erhard eMail: [EMAIL PROTECTED] phone: (GERMANY) 0721 27326 My WebHome: http://members.tripod.com/Juergen_Erhard George Herrimann's Krazy Kat (http://www.krazy.com) Windows NT is an acronym for Windows? No thanks. -- Russ McManus -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Use Mailcrypt and GnuPG http://www.gnupg.org/ iEYEARECAAYFAjjiJoIACgkQN0B+CS56qs2KlACfUOYF3C81+kObOp1GfdFNaZPn Hm4An2l02Aq5saYObdA7FhVowdutXR8r =RNl1 -END PGP SIGNATURE-
Re: how about a real unstable?
On Tue, Mar 28, 2000 at 09:09:43AM -0800, Andrew Lenharth wrote: I know others have expressed this, but a big reason we wind up with slower release cycles is we have a stable unstable. i.e. unstable is rather stable. Most of the other distributions start with the software that will be released by the time they release and start working with it early. What I really mean: unstable should (as soon as work on potato is finished), have the new perl, xfree, apache, kernel, etc. Even if they are still release canidates. the sooner we have everything working with the new packages, the sooner we can release. For example, to wait till perl 5.6 is out to try to integrate it could take longer that to start the integration process with a perl release canidate. It is the unstable branch, lets take advantage of it and make it unstable to start out with. The sooner we can find problems and fix them, the shorter our release cycles will be, and the more upto-date our main packages will be. This is what experimental is for, no? Unstable is for unstable Debian, not necessarily unstable software. The experimental distribution is much more appropriate for unstable upstream software. -- Elie Rosenblum That is not dead which can eternal lie, http://www.cosanostra.net And with strange aeons even death may die. Admin / Mercenary / System Programmer - _The Necronomicon_
Re: how about a real unstable?
This is what experimental is for, no? Unstable is for unstable Debian, not necessarily unstable software. The experimental distribution is much more appropriate for unstable upstream software. agreed with the addition that experimental must also be apt'able. Getting software from the bottomless pit that is experimental is nearly impossible right now. There is no information on what a package is for, depends on, or otherwise.
