On Mon, Dec 04, 2000 at 12:00:05AM -0500, mshupp@happypuppy.com wrote: > In closing, I'd like to ask another (related) question. Is there some > particular piece of software that you think Woody is waiting for that > will be here in a years time? This isn't really the right question to be asking. Here are a few better ones that you might like to try. * Hey, woody's pretty good, why can't we release it right this instant? - Mainly, we have a lot of known bugs that we consider unacceptable: things don't work at all, they have security issues, they don't build on all architectures, they have broken dependencies, they're new and untested, etc. - "testing" is designed to avoid these problems by simply ignoring packages that have such issues until they're fixed. At the moment, "testing" is ignoring the new libc, the new perl, and the new X. So releasing it might work, but it wouldn't be much of an achievement. - We have a fairly high number of open unresolved bug reports, and while they may not mean we won't release, they'll certainly make the release a lot less useful and fun. - We also don't have current boot-floppies, that is woody cannot be installed. The boot-floppies maintainer expects a minimum of six weeks' development time simply to port potato's boot-floppies to woody, with essentially no new features added. * What were potato's problems, and have they been addressed in woody yet? - Potato had quite a few problems. Probably the most obvious is that the install still isn't up to scratch: the boot-floppies don't report errors all that well, they're a little unintuitive to use, there are problems with dependencies in packages included in the "simple" install, autodetection isn't very thorough, package priorities and sections are poortly organised, install time configuration, even with debconf, is fairly inconsistent and there seem to be a number of cases where questions will get asked repeatedly for no good reason... The install seems to be the main focus of criticism of Debian and we're a way off having any solution, still. - Another significant problem from potato is the length of time it took to release when we eventually decided we wanted to. Some of the ideas towards addressing that are almost implemented (in the form of the "testing" distribution), but a fair number remain: task packages look like being equally awkward during the freeze, some good ideas about removing the coordination problems involved in boot-floppies are being worked on but are a long way from being done... - Almost a direct result of the above is that a fair number of packages are out of date. The rules of the freeze ("no new features") and its length (seven months officially, plus a month or two of "we'll freeze real soon now, so don't start anything") essentially dictated this. As such, woody has fairly quickly acquired a fair number of Neat New Toys. * Where are we trying to go with Debian anyway? - This is a pretty naive question, really. Everyone involved has their own idea of what Debian's good for. But at least one description of Debian I've seen is as `the Universal Operating System', so it might at least be worth thinking about how well we're doing at some of those goals. Possibilities include: + Making a completely free OS (whatever happened to that non-free GR anyway...) + Making a top quality server OS (weren't we going to have non-interactive installs by now...) + Making a good, free, general purpose desktop OS (hey, we've got Gnome and KDE and Mozilla, and OpenOffice, why not? Oh, but wait, you need a PhD to do an install) + Making a top quality secure OS (the security team are working great, but whatever happened to package signing, and shouldn't we think about doing proactive audits...) + Making an embeddable distribution (this is still on the drawing board really, more than something plausible for woody) Of course, the only question that's really worth asking is: * What can I do to help? And there're a whole heap of answers to that. Probably two of the more useful ones are: - Don't stress about what you can't do, stress about what you can do. You don't need to be a maintainer to diagnose bugs ("here's a fix for this bug", "this bug is caused by this, dunno how else you could do it though", "these bugs are the same", "this bug is fixed"), you don't need to be a coder to write documentation. Maybe more importantly, you don't need to be a supergenius hax0r to do any of these things: it's much more helpful to both you and Debian if you spend a couple of hours fixing a problem, even if it'd only take some guru five minutes, since that guru's probably spending an hour fixing some other problem that's harder. - Realise that fixing problems and writing long missives on mailing lists are almost always completely different things. Follow the example of people who send lots of neat patches to the BTS, or who make uploads of their packages every other day and have a response time to feature requests and bug reports measured in hours instead of months. If you want some more explicit suggestions: - Go throught the BTS, submit patches whenever you can, test and reproduce any bugs that don't seem clear, add bug tags (moreinfo, patch, unreproducible) where they're clearly appropriate. You don't need to be the package's maintainer, or even a developer to do any of this, but do be careful you're helping the maintainer rather than getting in their way. - Find packages that have lots of bugs that are easy to resolve, and check with the maintainer, and make an NMU, or submit patches to the maintainer. The most important thing here is to check and double check what you're doing, and make sure the maintainer doesn't end up with more bugs as a result of you stuffing up. You do need to be a developer for this. - Start testing upgrades from potato to unstable with an eye to making it as seemless as possible. This is pretty easy to do, although you need to have a good eye for which bugs actually need fixing, and which ones will resolve themselves anyway (say when the ftpmasters get around to removing an obsolete package, or installing a new one from incoming). You don't need to be a developer for this, but it probably won't be too effective while woody is completely unstable. - Work on tidying up the install process. For woody, we've got two possibilities: use the existing boot-floppies code, which at least works, but isn't likely to resolve any of the complaints about the install we've had; or use the new debian-installer code, which isn't likely to be ready for some time yet and will push the freeze back by a while. - Work on documenting the system: replacing all the links to the undocumented(7) manpage with real manpages; writing better descriptions for packages; heck, even writing upstream info/html docs would be fairly helpful. You can make up your own, too. But the more directly beneficial to the distribution (ie, what you get on CD), the better. Writing a patch to some problem that annoys you is probably better than a 200 line email to -devel telling everyone what they could do to help if they felt so inclined. > (1) Kernel 2.4 (early test versions are in Woody already) If you want to help out with this, it's probably still worthwhile running a 2.4 test kernel, and seeing which bits of Debian break. Does the USB fs get mounted properly? Does devfs get handled properly? How can these be handled differently to make them more convenient for people upgrading? Similar things apply to some of the other upgrades too: how can this be made as smooth as possible? How well tested is it? > iv. FHS compliance and other Linux standardization efforts (are we > REALLY going to see a convergence of deb, rpm, and tar-ball packages?) We're still a fair way away from having an LSB standard to comply with. As far as the FHS is concerned, whatever happened to that /usr/share/doc transition? A few NMUs for that probably wouldn't go astray. There are probably a few policy changes since potato that could use NMUs in fact. To go back to the original question in the other thread, which was something like `when are we going to freeze?', the answer depends on all of the above. I'm inclined to give the debian-installer people a bit more time to see if they can possibly be viable for woody, personally. Cheers, a ``Think locally, act globally: scratch your itch today'' j -- Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001
Attachment:
pgptRpoA71uCX.pgp
Description: PGP signature