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
-- To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
This archive was generated by hypermail 2b30 : Sat Jan 13 2001 - 15:00:51 CET