Re: Re: Some observations regardig the progress towards Debian 3.1
On Sun, 16 Nov 2003 02:23:00 +0100, Adrian Bunk wrote: > You need a freeze at one point (unstable or testing) to get a base > where you can start to fix the remaining problems without new bugs > from new upstream versions. > The choices are: > - freeze testing and start then to backport all the bug fixes and > security fixes from unstable > - freeze unstable and try to get as many packages as possible from > unstable into testing (exactly the work you are currently doing, but > based on a more stable basis) > - freeze unstable and use unstable as a basis How about changing the way testing works? I mean, we've come to the point when we realize that the testing/unstable structure is not really working, so we added experimental. Now, I suggest: allow a way to add bug-fixes directly into testing, instead of having them go through unstable first. If there's a new (and very buggy) version in unstable, but there's an easy-to-fix bug in testing, why not allow developers to fix this bug without going through the unstable barrier? I'm not a developer, I consider myself a Debian bug-reporter. And I usually report bugs for testing, and many times I've received the reply "this is fixed in unstable", but then unstable never comes because there are LOTS of other bugs. So, why not allow the bug-fixes to go into testing, even if the new version does not come? I'm not talking about some manual security update, I'm talking about a systematic way of doing it. For sarge and for the next release as well. I don't know how to implement this, but I think it would be a great idea to allow it, so that testing packages would get less and less buggy, no matter what happens in unstable. Love, Margarita Manterola. PS: As a Debian user, I would really hate to see sarge released as it is right now. I consider an insult to the user that "Evolution" is not in the release (not even the old woody version). But this is outside my present suggestion.
Re: jack 0.75 mini-freeze
+++ Andreas Metzler [03-11-14 22:46 +0100]: > On Fri, Nov 14, 2003 at 01:51:30PM -0600, Steve Langasek wrote: > [...] > > What criteria are you using to classify this as a grave bug, given > > that the vast majority of sarge users will be running 2.4 kernels? > [...] > > I doubt the "vast majority". Who is running woody with 2.2? I was until 3 days ago.. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Re: Re: Some observations regardig the progress towards Debian 3.1
Margarita Manterola wrote: > Now, I suggest: allow a way to add bug-fixes directly into testing, > instead of having them go through unstable first. If there's a new (and > very buggy) version in unstable, but there's an easy-to-fix bug in > testing, why not allow developers to fix this bug without going through > the unstable barrier? Guess what testing-proposed-updates is for. > I'm not a developer, I consider myself a Debian bug-reporter. And I > usually report bugs for testing, and many times I've received the reply > "this is fixed in unstable", but then unstable never comes because there > are LOTS of other bugs. So, why not allow the bug-fixes to go into > testing, even if the new version does not come? Packages in unstable have dependencies in unstable which may not be met in testing, hence they cannot simply be included in testing. Unfortunately we need to take care of this. > PS: As a Debian user, I would really hate to see sarge released as it is > right now. I consider an insult to the user that "Evolution" is not in > the release (not even the old woody version). But this is outside my > present suggestion. Packages with similar depencency complexity pose the same problems, I'm sure. A lot of dependencies need to be fulfilled before they can be included. If somewhere in the chain there is a problem, the package cannot go in. Regards, Joey -- Given enough thrust pigs will fly, but it's not necessarily a good idea.
Re: Some observations regardig the progress towards Debian 3.1
On Sun, Nov 16, 2003 at 11:53:36PM -0500, Matt Zimmerman wrote: > On Sat, Nov 15, 2003 at 05:42:20PM +0100, Adrian Bunk wrote: > > > Today, it's only 17 days until the officially announced "aggressive goal" > > for the release of Debian 3.1 [1]. That's a date many users know about, > > but I don't see any real progress towards Debian 3.1 during the last > > months. > > I suppose you don't subscribe to debian-boot or debian-devel-announce, then? OK, I admit my mail was a bit too general. There are serious improvements in the installer, but Debian is still _far_ away from a new release that was announced as "aggressive goal" for December 1st (and see my note on debian-installer below). > > Yes, there's the common argument "Don't talk, fix bugs.". Unfortunately > > this doesn't work: Debian is too big. I might e.g. be able to fix 50 > > easy to fix RC bugs in unstable, but this would be lost in the noise, > > and wouldn't result in real progress. > > So instead, we have a system where people take individual (or small group) > responsibility for a particular piece of software, to take care of it and > fix its bugs. This way, we distribute the effort over a large number of > people. The problem is, this often chaotic development system doesn't scale to over 1200 developers (including many MIA developers). > > Debian 3.0 contains 7 CDs with binaries and Debian 3.1 might contain 10 > > or more CDs. How do you explain to a user why there are 10 CDs, but this > > popular package is not included, and that package he needs is not > > included? > > One of the nice things about not having customers and contracts is that we > don't need to answer these questions. If a package is missing, either there > were unavoidable problems preventing its inclusion, or no one cared enough > about it. I would very much rather have a package omitted than have to > support software that no one else cares about. > > > Saying "The maintainer didn't care enough about the package you need." > > only sounds like a good reason to switch to RedHat... :-( > > If Red Hat ships more of the software the user needs, maybe it is a better > choice. Choice is one of the great advantages of free software, after all. The question is perhaps a different one: What is the goal of Debian? This is not about "free software" or such goals, it's about what audiences and niches does Debian target at. Debian is usable for hackers [1] and as a base for projects like Knoppix and commercial distributions like Xandros and Lindows. Debian is usable as a server distribution and for desktops if you don't need the latest software. Noone forces you to support the latter uses, but if you don't support them, the only way for normal users to use Debian will be to buy Xandros or Lindows. I'm not saying this would be immoral or something like that, but e.g. a major release without Evolution [2] (currently ages away from reentering testing) might make Debian stable unusable for many users - and you should be aware of such consequences. > > Currently, many new upstream versions flood into unstable every day. > > Trying to get this or that package into testing is a Sysyphos task, since > > once this or that problem with moving packages into testing is solved, the > > next one pups up. For testing to work good, it's required to have unstable > > in a good state. Often new so-versions of libraries enter unstable, and > > e.g. KDE 3.2 might soon go into unstable. If testing should be frozen, > > it's needed to _freeze unstable_ (IOW: require RM approval for every > > upload to unstable). This doesn't need to be under a "no new upstream > > code" policy at the beginning, but at least beta versions, new so-names > > and major upstream releases (e.g. avoid KDE 3.2, but 3.1.5 is OK) should > > be avoided. > > I think this is more or less what was proposed in the last release timeline, > where major changes in certain packages were frozen at various dates. There are some problems with the release timeline: Debian stable is too outdated, it doesn't even reasonable support most available new hardware. At least one release [3] every year would be required. Releases are not predictable for the average user. For one year after the release of Debian 3.0 there was no statement when Debian 3.1 will be released, and the latest announcement that Debian 3.1 will be released on December 1st (spread via Debian developers to many users and the press) seems to be quite unrealistic - it seems even unrealistic to miss this date by only one or two months. > > Another problem for the release is the Debian installer. The vast > > majority of Debian installations is i386. If the new installer isn't > > ready on all architectures it might be an option to ship some > > architectures without installer in 3.1r0, and add the installer for > > these architectures in 3.1r1 or 3.1r2. This way Debian 3.1 might be > > released more early, and even for the affected architectures it
Attempted "testing propagation status" report
So, things look pretty good actually. KDE 3: Frustratingly slow. * Still waiting for kdebase 3.1.4 upload which is fully installable (including kdebase-dev, and therefore ksysguard). This is probably keeping other kde packages out indirectly; when their -dev Build-Dependencies are uninstallable, they can't build. * Also, kdemultimedia needs 3.1.4 uploaded (and will then wait for various other things). GNOME 2: All the libraries need to pass their 10-day wait times, and then most of it should go in at once, probably leaving only a couple of packages to fix. perl: Just waiting for its wait time to go. jack-audio-connection-kit & friends: * Waiting for gem, which is waiting for a glibc headers fix. * Also breaks pd-externals, which has the newest version in 'testing'. This is probably not a real issue (pd-externals depends on pd, which depends on jack-audio-connection-kit). (Also, pd Replaces: pd-externals.) pd-externals also FTBFS on hppa. Anyway, pd-externals might need a new upload; I don't know. mozilla: All the old RC bugs are stamped out, and now it's FTBFS on m68k and mipsel. * On mipsel this is due to a bug in nut. * On m68k it looks like it's just waiting for a bunch of other things to build. So it should hopefully go in soon (yay). postgresql: Waiting for perl. pilot-link: Waiting for perl. cyrus-sasl2, krb4, arla, heimdal: I still find these very hard to decipher. I still can't believe that they really break 56 packages when going in *together*. Supposedly they're waiting for postgresql, presumably because 'old' postgresql depends on something which is going away (although I cannot actually figure out what). But are they waiting for anything else? Is it possible to suggest that the testing scripts do a recur with this combo in order to see what still breaks when they go in together? Or does the Release Manager already know? ;-) After the above things get dealt with, it will probably be time to make a reassessment and see what (if anything) else involving complicated dependencies and version transitions really "ought" to go into sarge. I suspect that there won't be much more and it will become appropriate to try to figure out how to fix all the "uninstallable in sarge" bugs at that time. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
