Hello world,
Some questions for the DPL candidates...
...but first! The one common thing across all the candidates' platforms
was a level of dissatisfaction with the release process. I figure
it's probably appropriate and productive for me (the release manager,
dontchyaknow) to say something about that.
In advance, I should say that not all the candidates are on an equal
footing here. Bdale has two advantages that you might possibly consider
unfair when talking about the release process at the moment: that he was
fairly influential in the design of the current process [0], and that we
had a chance to meet and talk in February at linux.conf.au. Additionally,
Raphael asked for comments from me on the detailed design stuff in his
platform before it's release, but didn't get any. Actually, he doens't
get many here either. :)
[0] Erm. Yeah. The mailing list archives are all screwy.
http://www.debian.org/Lists-Archives/debian-devel-9805/msg01786.html
once worked. Somewhere in:
http://lists.debian.org/debian-devel/1998/debian-devel-199805.gz
is probably where you need to look now. Look for a message from Bdale,
in the "Debian development modem" (sic) thread. Hrm. Not sure how
long this'll keep working, but:
http://www.google.com/search?q=cache:5U4Nl71NoMEC:www.geocrawler.com/archives/3/216/1998/5/100/1143489/++site:www.geocrawler.com+%22debian+development+modem%22+bdale&hl=en
So. The first question is is this dissatisfaction justified? How long is
the woody release taking compared to other releases? Well, that's easy:
version codename freeze-date release-date development/freeze
1.1 buzz ? 1996/06/17
1.2 rex ? 1996/12/12 6 months
1.3 bo ? 1997/06/05 6 months
2.0 hamm 1998/02? 1998/07/23 8 + 6 = 14 months
2.1 slink 1998/11/03 1999/03/10 4 + 4 = 8 months
2.2 potato 2000/01/16 2000/08/15 3 + 7 = 10 months
3.0 woody - 2002/04? ~18 + ~2 = 20 months?
So, at twice the length of the potato release, yes, it seems pretty fair
to say this is taking an excessively long time. It certainly seems pretty
fair to want it to take much less time in future.
In which case the responsible thing to do is to ask what actually took
so long? What did we spend our time doing, and how could we have done
that more quickly? Let's have a look:
Refs relative to: http://lists.debian.org/debian-devel-announce/.
Is it just me, or does having the year and list name both appear twice
in these urls really suck?
Package pools / katie roll out:
2000/09 - 2000/10/19: 2000/debian-devel-announce-200010/msg00007.html
2000/11/24: 2000/debian-devel-announce-200011/msg00012.html
2000/12/13: 2000/debian-devel-announce-200012/msg00003.html
Testing roll out:
2000/12/18: 2000/debian-devel-announce-200012/msg00011.html
boot-floppies:
2001/02/16: 2001/debian-devel-announce-200102/msg00014.html
2001/04/07: 2001/debian-devel-announce-200104/msg00004.html
2001/04/08: 2.3.0: "first version for woody"
2001/04/11: 2.3.1
2001/05/07: 2001/debian-devel-announce-200105/msg00003.html
2001/05/17: 2.3.2, 2.3.3
2001/05/28: 2.3.4
2001/06/04: 2001/debian-devel-announce-200106/msg00001.html
2001/06/07,20: 2.3.5-6
2001/07/02,20: 3.0.7-8
2001/08/08,11,13,20,24: 3.0.9-13
2001/09/23: 3.0.14
2001/10/16,26: 3.0.15-16
2001/11/07: 2001/debian-devel-announce-200111/msg00006.html
2001/11/14: 3.0.17
2001/12/18: 3.0.18
2002/01/22: 3.0.19
2002/03/03: 3.0.20
RC bugs in base packages:
2001/07/01: 2001/debian-devel-announce-200106/msg00014.html
2001/07/10: 2001/debian-devel-announce-200107/msg00004.html
2001/07/28: 2001/debian-devel-announce-200107/msg00011.html
2001/08/08: 2001/debian-devel-announce-200108/msg00002.html
2001/08/21: 2001/debian-devel-announce-200108/msg00012.html
2001/11/01: 2001/debian-devel-announce-200111/msg00000.html
2001/11/07: 2001/debian-devel-announce-200111/msg00006.html
2001/11/19: 2001/debian-devel-announce-200111/msg00012.html
2001/11/29: 2001/debian-devel-announce-200111/msg00016.html
2001/01/28: 2002/debian-devel-announce-200201/msg00014.html
2002/02/16: 2002/debian-devel-announce-200202/msg00012.html
crypto in main:
2001/01/10: bug 81852 filed against policy to allow crypto in main
2001/02/14: bug 81852 delayed pending legal advice
2001/04/..: (late April/early May) crypto legal team formed
2001/05/02: postgresql moved to non-US
2001/06/01: final legal questions docco done up, basically
2001/07/01: 2001/debian-devel-announce-200106/msg00014.html
2001/07/31: response from HP lawyer (with followup questions)
2001/08/08: 2001/debian-devel-announce-200108/msg00002.html
2001/11/07: 2001/debian-devel-announce-200111/msg00006.html
2002/02/09: 2002/debian-devel-announce-200202/msg00006.html
?2002/03/08?: done?
So what's that say?
From potato's release, 'til early 2001, package pools and
testing were being rolled out and integrated and generally made
work. This was probably at least six months worth of work that
can't reasonably be done during any sort of freeze (since the
people doing it were the ones who make the freeze work).
From potato's release, 'til April 2001, boot-floppies were left to
die, and they did. In April, we finally had some success getting
them built again, and from then 'til around October we had over
a dozen releases gradually approaching usability. Since October
we've had a few improvements and a few changes to make because
of various things breaking. Which is to say, we had about seven
months lost, then another six or more months getting boot-floppies
in reasonable shape across all our architectures.
From when we started trying to freeze, it took seven and a half
months just to get the absolute core of our system in a reasonable
releaseable state. And considering things like the libdb2 problems,
we still haven't really managed that.
We took about twelve months trying to work out precisely how to
go about moving crypto non-US into main, after the US improved
their export regulations. After this, we've spent another three
or four months getting our archive software into appropriate
shape to do so, and we'll spend some more time actually moving
the software across once this is finished.
About the only thing here that could have been avoided is the
crypto-in-main issue. Unfortunately doing so wouldn't have been a huge
boon: boot-floppies and the RC base bugs alone have pushed the woody
release back until now, and are continuing to do so.
We certainly could have done better: boot-floppies could've been
working much earlier (well, in some fantasy world where dbootstrap is a
maintainable body of code that's pleasurable to work on), and I'm fairly
confident that with a bit of motivation we could've cut at least a few
months off the problems with base packages.
Such motivation is arguably my responsibility, so it's arguable that
these delays (in getting people to start working on boot-floppies
and fixing RC bugs in base) were mostly due to me focussing on the
pools/testing roll-out early in the piece. The candidates might have
some views on things that can be done about that, but at the very least
it seems unlikely there'll be any transitions on quite the same scale
for a while. OTOH, if Raphael's plan gets implemented, it might be a
problem again, and perhaps he'll want to comment on that aspect.
I don't really want to go into the level of detail that Raphael's
platform does on working out solutions to improving the release process
at the moment. I think that's much better left 'til *after* the release
is over. At the moment, the goals are simple:
* get boot-floppies working (particularly sparc and alpha)
* get the core system completely functional (libdb2 atm)
* get crypto-in-main done (nearly nearly)
* get rid of all the unreleasable garbage that's still in testing
(see d-d-a every week or so)
Once these things are done, we'll be releasing. Once that's done, we'll
have a nice relaxing flamewar about what happened and what we'll do
next time.
Or, at least, that's my theory. The candidates may have other ideas. If
so, that may just mean we'll have to bring the release slightly forward
to make sure they don't have a chance to implement them. Muahaha.
So! On to the actual questions! Candidates, riddle me this...
What do you consider the DPL's field?
- as an intelligent rubber stamp as per the constitution? (ie,
spending money, giving people who're already doing a job an
official "delegation", etc)
- poltical issues?
- technical leadership?
- design or implementation of technical changes?
- something else?
As DPL, how will you ensure the technical goals in your platform are
achieved?
Personally, I often find it difficult to get people to work
on important tasks like boot-floppies (I started whining about
them in February 2001, it took 'til April to get an activity;
I've been whining about sparc and alpha updates for a couple of
weeks now too without as much success as I'd like). I've also
had limited success in getting significant amounts of install
and upgrade testing happening. In many cases this seems to be
because there's only a limited pool of people competent to do
these things, and they're all already being worked to the bone.
For a number of the goals I've had for woody, I've had to spend
a fair amount of time chipping in myself: testing, tasksel, and
crypto-in-main, eg. It's not clear to me to what extent this is
an option for the DPL, nor what other effective options there are.
To be more concrete: Bdale, how will you ensure that "the benefits
of implementing caching proxy servers instead of mirrors" and
so forth are actually available to our users instead of just
talked about? Raphael, how will you ensure that the "second
security team" becomes more of a reality if you're elected, than
the similar thing Ben talked about last year [1] did? Branden,
given that there have been enough other things to work on and
difficulties with the implementation up until now that this
hasn't already been done, how will you ensure qmail is removed
from lists.debian.org?
[1] See the end of:
http://lists.debian.org/debian-vote-0102/msg00017.html
If you aren't elected DPL, what does that mean for the items in your
platform? Will you spend time over the next twelve months helping
motivate the project, or recruiting people to adopt packages, or trying
to ensure the developer base is active, or any of the other things in
your platforms anyway?
These next questions are related to the responses I got to "What do you
think are the three main achievements/problems for the next year?" when I
asked the DPL candidates (Ben Collins, Bdale Garbee and Branden Robinson;
Anand Kumria didn't respond) last year.
How well or poorly do you think we've gone at achieving each of the
following? Is there anything you'd have done differently as DPL to what
BenC's done? If so, why didn't you do it just as a developer, and why
would it have done any good?
1. Releasing woody [BenC, Branden, Bdale]
2. Getting control over our new maintainer process [BenC]
3. Getting a handle on our bugs [BenC]
4. "Fishing our cutting bait" on non-free [Branden]
5. Getting the US government to lift all restrictions on
crypto export [Branden]
How well or poorly do you think we've gone at _avoiding_ problems due
to each of the following? Same qualifications.
1. Accumulation of inactive maintainers [Branden]
2. Accumulation of unmaintained packages [Branden]
3. Inconsistent timliness of security advisories [Branden]
4. Version skew amongst architectures hamstringing testing [Branden]
5. Bandwidth consumed by our distribution methods [Bdale]
6. The number of packages in the distribution [Bdale]
7. The administration effort required to keep the project
running [Bdale]
Just for kicks, what did you think were the three big achievements
we actually had in the last year, and the three biggest problems we
actually faced? (If you haven't already been horribly biassed by the
list of problems at the start of this message, anyway)
Top three things you hope Debian will achieve during the next twelve
months? Top three problems you think Debian will face during the same
period? Are there any longer term goals or concerns we should be worrying
about, and, if so, what needs to be done about them in the next twelve
months?
Do you think there's anything that can or ought to be done about changing
the trend of the graph at http://bugs.debian.org/~ajt/graph.png ?
There are many purely technical subprojects within Debian that would
be useful if completed, but seem like they're not getting any closer
to being ready for production systems. Things like non-interactive
installations (debconf got it started, but we seem to have stalled),
IPv6 support (debian-ipv6@lists.d.o), the Hurd port (binary-hurd-i386),
and debian-installer, eg. What, if anything, can or should be done to
ensure these things actually get finished and released?
Do you think Debian should continue to support the LSB? If so, what do you
plan on doing to ensure issues like the bin uid and filetype detection are
resolved satisfactorily? If not, what, if anything, should we do instead?
Should Debian (or SPI) be involved in distributing data (as opposed to
programs) that can be distributed, and might be useful for Debian users,
eg the RFCs, the Bible, books from Project Gutenburg, desktop theme
packages, or game data files?
Is there anything that Debian (or SPI) can or should be doing (either in
the next twelve months or longer term) to promote more open media formats?
Is there anything that Debian can or should be doing (either in the next
twelve months or longer term) to make SPI more useful?
What directory should traceroute be in?
What's more important: being as open as possible about things,
getting them done in a timely manner, or avoiding making a decision on
controversial topics?
Will you be at the next linux.conf.au in Perth, January 2003?
Do you think any of these questions were biassed or prejudicial? If
so, don't you think you're being a bit overly sensitive for a pompous
blowhard?
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
We came. We Saw. We Conferenced. http://linux.conf.au/
``Debian: giving you the power to shoot yourself in each
toe individually.'' -- with kudos to Greg Lehey
Attachment:
pgp7nsVFwwlZd.pgp
Description: PGP signature