[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debian-devel:15903] Forward: Bits from the RM

sarge Release ManagerのAnthonyから、sargeの現状の状況と、より一層の作
業をうながすアナウンスが出ています。
--- Begin Message --- 
Hello world,

So as most will have realised, we're not going to be releasing on December
1st. For those who didn't, hopefully you have now.



Before we get into the details of why we haven't made that date, let's do
a quick summary of some of the progress we've made.

	* debian-installer HOWTO available, with betas available on i386
	  and powerpc, and some pre-alpha (?) versions hacked up for
	  mips s390, and alpha.

	  (after a long time without any visible activity, we've had a
	   dedicated hacking camp, and a bunch of status reports, and
	   have gone from d-i being barely usable even by its developers
	   anywhere, to being about 20% done. Sweet. And the last 80%
	   usually takes 20% of the time, too, right?)

	* glibc 2.3.2 bugs fixed, hppa supported again, and NPTL
	  support added

	  (the "minor" upstream update from 2.3.1 to 2.3.2 ended up
	   causing significant problems, like not working at all on hppa,
	   that took quite a while to fix; NPTL support has also been
	   added. The remaining bugs are straight forward to fix, and no
	   more major changes are expected)

	* KDE hit testing

	  (KDE hadn't updated in testing since woody's release, due to a
	   mix of its own bugs and glibc bugs -- until recently there hadn't
	   been a time when one or the other wasn't broken in unstable)

	* Python 2.3 hit testing

	  (Python's been doing fairly well, but this was a fairly major
	   update (all Python modules getting recompiled) that happened fairly
	   late)

	* Perl, Postgresql, Krb4, Heimdal, etc almost ready to hit testing

	  (The perl updates have had some upstream problems which've
	   required a reversion, and then have had problems building,
	   causing quite the morass; that should be about ready to be
	   fixed when the archive opens up again)

	 * LSB 1.3 compatibility mostly achieved

	   (LSB non-compliance issues are now Release Critical; bugs
	    should be filed and addressed by the LSB team, which hangs
	    around the debian-lsb mailing list. Only one compliance
	    issue remains unfixed in sid. LSB 2.0 compliance will be
	    trickier, but will hopefully be being worked on well before
	    the next release.)

One of the things we haven't achieved, and aren't aiming to achieve,
is a purge of non-free documentation from Debian. Appropriate licensing
for documentation has been a concern for the free software community
for a long term, and the controversy over the _GNU Free Documentation
License_ has resulted in a number of members of the Debian Project forming
the opinion that we should hold documentation to the same standard as
programs. While this is natural enough, contrary to some claims, it is
not a continuation of existing Debian standards, and making significant
changes to our standards isn't what we aim to do while we're trying
to release. You may already have noticed the use of the "sarge-ignore"
tag on bugs filed about the freeness of various documentation licenses,
such as GFDL documents, RFCs, and others. These bugs will remain at the
"serious" severity, but will not be considered "release critical" for
sarge. If you wish to ignore them until sarge is released, you may. If you
wish to remove the documentation from your packages, you may, although
you're encouraged to repackage them for non-free instead. Packages with
distributable documentation that doesn't satisfy the DFSG may be uploaded
to either main or non-free at the maintainer's discretion.



Basically, although we're not operating at the "aggressive" level we
were aiming for, we're not in terribly bad shape.

As such, a number of people have been asking for roadmaps and updated
timelines recently. Unfortunately, we're not in a position to offer
one. To understand why and to figure out what to do about it, we need
to have a look at the shape our progress has taken recently.

One of the better measures is the RC bugs graph, at 

	http://bugs.debian.org/release-critical/graph.png

Interesting periods are mid-July to early August, which coincides with
the Oslo debcamp, and mid-August to mid-September, which coincides with
the "0-day NMU period". These periods both coincided with significant drops
in the RC bug count, that have so far been roughly sustained. 

But outside these periods maintaining the bug count has been the best
we've managed, and for most of the year (January until debcamp) the
bug count has been rising fairly consistently, although with a fair bit
of noise.

Without having evaluated null hypotheses or done exhaustive analyses,
the correlation nevertheless seems fairly convincing. To put it bluntly,
our regular package maintainers are doing such a bad job that without
significant assistance from NMUs, about 6% of the archive fails to meet
even our _absolute minimum_ expectations.

That's bad.

It would be bad even if the 6% was random junk that no one uses or cares
about, or was a bunch of packages that were so complicated no one knows
how to fix them, which is probably what you're thinking. Unfortunately,
it's even worse than that. Consider the following examples:

	* #215930 - bzflag - Tim Riker
	  various lintian bugs, patch filed a month ago,

	* #169264 - discover - Progeny Debian Packaging Team
	  postinst fails if /cdrom mounted, filed a year ago, patch filed
	  early this month

	* #216078 - exim - Mark Baker
	  multiline "Conflicts:", filed a month ago, unfixed

	* #203339 - freeswan - Rene Mayrhofer
	  FTBFS, patch in the bug log since July, no further activity

	* #216658 - gdm - Ryan Murray
	  broken when "broadcast" is true, no response from the maintainer
	  in a month

	* #208646 - grep-dctrl - Antti-Juhani Kaijanaho
	  unspecified problems with version in unstable, should take
	  "a couple of days" to fix, no activity since September

	* #188924 - hostname - Adam Heath
	  doesn't like missing info from /etc/hosts, patch from June, no
	  activity since July

	* #213028 - initscripts - Miquel van Smoorenburg
	  bootlogging doesn't work "right" in single user mode, no obviously
	  correct solution yet, no activity since September

	* #208025 - kaffe - Ean Schuessler
	  misplaced man page, patch since September, no activity since then

	* #211985 (etc) - kde - Christopher Cheney and others
	  ksysguardd needs a recompile, hasn't been since September

	* #208288 - libggi - Martin Albert
	  libtool update needed, instructions since September, no activity
	  from the maintainer

	* #175858 - libvorbis-dev - Christopher Cheney
	  "128" needs to be "128000", filed in January with patch, fixed
	  upstream a month ago, new upstream release a couple of days ago

(I got bored by the time I got to "m". Sue me.)

Now, I'm certainly not meaning to imply that any of the people listed
above aren't valuable contributors to the project, or that their
contributions to the above packages aren't appreciated -- in both cases,
they are. And it's almost certainly true that in every case above,
the given maintainer has had more important things to worry about the
above bugs.

But while all that's true, it's also true that the above doesn't meet our
expectations, or our users' expectations. 

Having critical, grave or serious bugs open for an extended period is simply
not acceptable.

Nor is it excusable. While it's possible that you mightn't have the skill
required to fix some security bug, or mightn't have the time to respond
to a bug report, you _do_ have both the time and the skill required
to file a bug report either orphaning the package, or requesting its
removal from the archive. 

Nor *should* it be excused. You might think the exim bug's not worth
worrying about -- after all, exim4's what people should be using, and
multiline Conflicts work with most tools at least, and hey shouldn't we
think about fixing the things that don't work anyway? So who cares? The
reporter of the bug for one. The people affected by it for another. The
people who look at the RC bug list and decide "Oh, there are so many
bugs already, there's no point filing another, it won't ever be fixed",
and all the people affected by those bugs. The people who look at the RC
bug list and decide that there's too much crap their to ever hope to make
a dent in. The people who would be willing to fix that bug, but don't want
to have to deal with annoying the maintainer by doing an unauthorised NMU,
or waste their time waiting for months for a an answer that'll probably be
"no", and who spend their time doing things other than Debian work.

So, seriously, if you're inclined to think of the current state of much
of the software we're distributing as anything but a mortifying shame,
please correct your outlook.



From how we're going at the moment, the best timeline we can produce
is something like this. We'll need to reduce the RC bug count to 0 for
at least major pieces of software like KDE, glibc and X. Each of those,
or their dependencies, have had various RC bugs open almost continually
since woody was released, so from that basis we can extrapolate to those
packages continuing to have RC bugs for the next year and a half, and
thus that we won't release for at lesat that long. Worse, those packages
are the ones that most people like to avoid NMUing, so there's not much
we can do on that score, either.



Now, I don't think that's acceptable. So what are the alternatives? One
is that we can re-introduce "0-day NMUs", or some similar policy to get
non-maintainers to fix maintainers' mistakes, and keep it going until
we actually release. 

Unfortunately, that has a few problems. One is that it probably doesn't
work that well over extended periods -- otherwise we wouldn't need
bugsquash parties and other special events, since you can already NMU
any time you like. Even the 0-day NMU thing that went for less than
a month petered out towards the end. Another issue is that people who
aren't familiar with a package aren't likely to be able to do as good
a job as people who are familiar with it -- and NMU policies tend to
both encourage the former (obviously) and discourage the latter (it's
no fun having some neophyte muck up your package fixing some stupid
bug). The spike immediately after the 0-day NMU period ended might be
a partial indication of the extent of that sort of problem, although
differentiating it from the noise is tricky.

Another possibility is to just drop packages that aren't maintained well
enough. While this is somewhat attractive, it doesn't really serve our
users any better than saying "Why don't we just lower our standards?"

Which is another possibility of course, and one that a number of
maintainers seem to like when some of our policies cause problems that
they don't want to bother fixing. It's certainly possible, and we have a
procedure for it: argue your case on the -policy list. But concurrently
with that, you *still* need to fix your packages -- if you're convincing,
you can then remove the fix later, if you feel the package is better
off without it. In general, arguments that certain classes of RC bugs
shouldn't be considered RC but should still be considered bugs aren't
going to be taken very seriously unless you've demonstrated that you're
not just trying to be lazy -- generally by fixing all such bugs first.



The other alternative is to do a better job maintaining our packages on a
continuous basis. I think that's both worthwhile and possible. 

First, let's review what we should be expecting of ourselves. In the
normal case -- when you're not on holidays, or having family crises,
or overloaded with work, or, for that matter, fixing compromised Debian
servers -- do you think it's desirable and possible to:

	* do whatever it takes to fix or work around security bugs within
	  a few days or at most a week of their discovery -- even if
	  that means disabling some important features entirely

	* for confirmed bugs with a known fix, upload a fixed package
	  within a day or two of the patch been sent to the bug log

	* respond to bug reports within a day or two indicating whether
	  you understand the bug, or need more information, or what

	* acknowledge NMUs within a few weeks, and integrate the changes
	  into your own source

	* rather than simply compiling upstream sources and putting the
	  result in a .deb, make sure that the resulting package fits
	  into a Debian system -- that it has the right directory layout,
	  that the programs are documented with manpages, that it's
	  internationalised, that it works out of the box, etc

I have no idea how to argue that those things are desirable because I
can't imagine why anyone would think otherwise -- if you really think
some of them aren't (and you're a Debian developer, not a random crackpot
of course :), talk about it on -devel.

Whether they're *possible* or not is another matter. But given that
they're desirable, we should certainly try to achieve them, rather than
make excuses so that we don't feel guilty about not achieving them.

So what approaches can we take?

First, I don't really have the answer to this -- while you won't find my
packages in the RC bug list, I do have plenty of open bugs, and plenty
of my packages have had NMUs at various times. So with the proviso that
you should be careful to not make things /worse/ than they already are,
it's definitely worthwhile thinking about other things that could keep
our packages well maintained all year.

That said, let's get on with it.

One approach is to deal with your packages more frequently. If you don't
do an upload for a while you let two bad things happen -- one is you let
a bunch of bugs accumulate and feel obliged to fix them all at once, which
is more work, and just encourages you to procrastinate more; the other is
that you become less familiar with the code, especially if you get NMUed a
few times, and changes become harder to do. 

A similar approach is to fix things quickly -- if you get a bug about some
spelling mistakes, or a simple patch to apply, do them straight away.
If some changes you make cause some bugs, fix them as soon as they're
reported, so you can forget about the package for a while with a good
conscience, rather than having it sit in the back of your mind distracting
you. It's not that hard, doesn't take that much time, and is a lot more
fun when you can tell yourself "ha, I bet Microsoft wouldn't have fixed
that bug within ten minutes of it being reported". And it's even better
when users tell you.

Another idea on the motivational front is to make sure you remember why
you're involved in Debian -- presumably for most of us it's because
it's fun, or because we think it's the best of all possible ways of
developing a good operating system. If so, you might want to look
into doing some things that are fun or impressively useful, rather
than primarily focussing on bugs and policy conformance. You might
want to look into managing your packages with arch or subversion (see
{arch,scn}.debian.org), or you might like to look into managing your
package's configuration files with ucf, or you might like to look into
setting up SELinux, and including a SELinux policy with your packages,
or writing some automatic test suites that get run from debian/rules, or
anything else which is new and interesting (and doesn't actually *detract*
from the quality of your packages, of course!). If you're here because
you think Debian's fun, remember to make sure you're actually enjoying
yourself, and there's a good chance that your bug count, RC and otherwise,
will drop as a side-effect.

The final suggestion for maintainers I'll add here is to get help.

Okay, the fifteen year olds in the audience can stop snickering
now. Thankyou.

We've often downplayed asking for help in favour of encouraging people
to *offer* to help, but since we're having problems, it's important to
try everything we can to overcome them. One of the more effective way
of getting useful help (as opposed to someone who says they'll help,
then does absolutely nothing), is to find some specific areas (or tasks)
that could use help, and then be specific in your request. There are
plenty of ways to do this, but at the moment, I think the best way is to
file a RFA (which we're redefining as "Request For Assistance" instead
of just "Request For Adoption") report against wnpp, with some decent
information as to what assistance do you want (someone to take over the
package entirely? a co-maintainer? someone to work on some particular
area? someone to fix some particular bugs? what skills are required?).

And on the other hand, when you're offered help that is actually useful,
try to encourage it, rather than complaining that the help wasn't perfect
in every possible way. Also, make sure that you're using the help in
a useful way -- if you've got a team working on a package, make sure
everyone knows what they're meant to be working on, make sure everyone's
got something interesting and worthwhile to work on, and make sure that
everything that needs to be worked on is being worked on. Generally,
this doesn't "just happen", so one of the jobs needed on most teams
is a leader (or a captain, or a manager, or even a secretary) just to
make sure everyone knows what they need to do. If you don't have this,
make sure you get it, even if no one wants the job.



Now, if we were able to leave all this stuff up to maintainers, we
probably wouldn't have this problem in the first place. So, we also
probably need to make we've got better support from behind the front-lines
than what we do at the moment.

First, the air support: 0-day NMUs will be open again from next weekend,
'til the start of the new year; that is to say from 2003-12-06 00:00:00
UTC to 2004-01-12 00:00:00 UTC. Same rules as always: make sure your
upload is correct, change the minimal amount of stuff possible, work
with the maintainer if at all possible (ie, file the patches in the BTS,
help the maintainer do the upload rather than doing it yourself, make sure
your patches would be approved by the maintainer), make sure you support
your NMU afterwards and fix any new bugs that appear as well. Hey, why
not sum it up in a poem? "Get it right, be polite, but upload tonight."

Second, artillery. Over the next little while, we'll hopefully have
a bunch of "RFA" bugs being filed. Please make sure you help on these
wherever you can -- and this applies to people in the new-maintainer
queue as well as people who are already developers. We often focus more on
ensuring that everything that's been made a .deb can get put in Debian,
rather than that everything in Debian is maintained at the highest level
possible. That's akin to fighting a war on many fronts, and it seems
to have resulted in us spreading ourselves a bit too thin. So let's
thicken ourselves up -- as well as having people hop around fixing RC
bugs in different packages every day, it's helpful to have people stick
around and help particular maintainers on a longer term basis: whether
as user support, a patch bunny, a backup maintainer, a co-maintainer,
or whatever else is appropriate.

Third, personnel deployment. As a complement to the "Request For
Assistance" stuff, we're also creating a new wnpp heading, OTA for "Offer
To Assist". The usual way to "offer to assist" a maintainer is by sending
a private email, and if you prefer, you can still do that. The reasons to
use an OTA bug instead are: (1) to track the maintainer's responses -- if
the maintainer doesn't respond to either accept the offer, or to indicate
why it's not needed or what is needed, then it's easy to see that there's
a problem; (2) to distinguish areas where plenty of assistance has been
offered, and where not much has been so people can work out where their
help is more likely to be appreciated; (3) so people see other people
offering help and it getting accepted and follow suit, rather than it
happening behind closed doors as some unfathomably mysterious process.
OTA bugs should be closed when the offer's accepted, or the submitter is
no longer willing or able to make the offer; but not when the offer is
rejected. OTAs are *offers*, not demands, if the offer is rejected, you
should aim to figure out what you can do that will be accepted, not pressure
the maintainer into changing his/her mind.

Fourth, morale. There's no point making a small contribution to a
package, then annoying the maintainer so much that he gets fed up with
Debian and quits, thus removing all possible future contributions he
might make. Similar things, of a lesser scale can suck too. Sure, have
disagreements, be passionate, stand up for what you believe is right,
etc, but do try to make sure the people your trying to help -- users,
fellow developers, etc -- actually enjoy your company most of the time.



The key issue here isn't one of ability -- we have more than enough
skillful, dedicated hackers to stomp the bugs in the BTS -- it's one
of action versus inaction. The above tries to avoid any really drastic
changes to how we operate, but I'm hopeful that it will still be enough
to increase our regular tempo so that we don't need multi-week rounds
of NMUs to keep our bug count under control.

Fallback plans are important though, and in this case if we're not able
to get in a position where maintainers are able to keep control of their
RC bug count (which is to say, keep it at zero), we'll have to consider
more drastic measures. An obvious one is to transfer packages that aren't
being maintained at an acceptable level to new maintainers, whether the
existing maintainer likes it or not. Some simple measures for this are
things like "has this package had any RC bug open for more than a month or
two", or "has this package had an RC bug open for more than a week or so
without any response". Even if you ignore all of the preceeding message,
you might like to ensure that those two criteria never apply to you.



So, some ideas to focus on:

	* Make sure you're having fun.
	* Make sure your RC bugs are resolved.
	* Make sure your packages are amazingly impressive:
		- current with the latest upstream release
		- easy to configure, setup and use
		- work everywhere out of the box
		- well integrated into Debian
		- any known fixes have been applied
		- feature requests and patches have been forwarded upstream
		- you're managing your package with "best of breed"
		  tools, you've got test suites, whatever else
		- all your bug reports are dealt with (reply to them,
		  verify them, forward them, fix them, close them as
		  appropriate)
	* Do some development instead of just maintenance. Fix some bugs
	  instead of doing development. Change things around a bit.
	* File RFAs to ask for help if you need/want it. Respond to OTAs
	  if you have any.
	* Make sure any packages you use or rely on don't have any RC bugs.
	* Respond to any RFAs you can help with. Send out OTAs if there's
	  something you could usefully work on that the maintainer would
	  appreciate.

And, briefly, the two things we need to focus on in order to release are
(as always):

	* a reliably working installer for all our architectures
		- debian-boot@lists.debian.org

	* releasable versions for almost all our packages
		- http://bugs.debian.org/release-critical

Cheers,
aj

-- 
Anthony Towns <ajt@debian.org>
Debian Release Manager

Attachment: pgppqfXOlpYTU.pgp
Description: PGP signature


--- End Message ---