Re: Debian doesn't have to be slower than time.
On Fri, Feb 15, 2002 at 02:27:42PM -0700, Joel Baker wrote:
> * Why does Debian take so long to release?
> * Why does it *matter* that Debian takes so long to release?
> * How do we avoid putting out buggy releases, while going faster?
> * How do we avoid running out of toy names?
> * How do we know when we've done a major-version release?
> * Why should we bother with any of this?
It was tough to read all this thread through, but it was worth it, there
are some valid (and constructive) ideas from it that I agree with. I
think it would be useful to put them together and hammer on them a
little more, until some decisions can be agreed upon, and someone is
motivated enough to sit down and make it work (don't even look at me
like that, I was just passing by :).
1. Fine-grained release planning
================================
That was main point of Joel Baker's post. All proposed changes to the
Debian should undergo thorough discussion, and during discussion they
should be split into reasonably small and strictly defined (as in
"number of RC bugs is equal to 0") subtasks. XP's recommended 2 weeks
are too short for volunteer effort, but 2 months that Joel proposed look
like a reasonable time cap.
Yes, there are some kinds of projects that can't be finished in 2
months, but if given a choice of either push back the whole release, or
push the feature back to the next release, latter should be chosed with
no hesitation. In order to be able to make such decisions, main trunk of
Debian should not adopt large features until their development and
testing outside of the pool is finished.
Standard template for step-wise adoption of major changes may be of help
here. Something along the lines of:
1) Feature X support infrastructure is provided in Debian.
2) X development infrastructure is provided in Debian, developer can
build packages using/supporting X. Most of the time can be combined with
previous stage.
3) All base/essential packages work correctly with X enabled.
4) All standard packages work correctly with X. If fulfilling this or
previous requirement depends on the upstream (like Unicode support in
bash), all we can do is wait and occasionally lend a hand/patch to the
upstream.
5) No packages in Debian break when X is enabled, optionally (if next
step is planned) drop packages that don't comply.
6) X is enabled by default.
In addition to that, you can fine-grain definition of "work correctly".
It may go as: a) don't break if X is enabled; b) take advantage of X
being enabled; c) work out of the box if X is enabled by default. Or you
can split packages affected by feature X into a) related to X; b) able
to take advantage of X; c) unrelated to X.
With detailed development and adoption plan in place, introduction of
new features into Debian can spread to as much releases as we want, with
changes in each release isolated one from another, thus less potential
bugs and testing per each release, and more intermediate releases for
the same amount of changes.
2. Raise entry barrier for packages
===================================
In short, more intensive package validation on entry should reduce
number of bugs discovered in testing. At least, package should build for
all targeted architectures and pass lintian test.
Unfortunately, I can't think of any universal regression testing for all
kinds of packages in Debian, but still we should come up with new ways
of ensuring that any given package upload doesn't break anything, at
least within set of functionality provided by previous upload. It won't
help against most difficult bugs (like bugs that are sitting there from
last stable release), but it will significantly reduce the more stupid
majority of bugs.
If package has regression test suite (like postgres), it should be
invoked via standardazed interface like "/usr/bin/regress-package
postgresql". And I know it's a resource hog, but I've seen people in
this thread who are likely to donate hardware to this cause :)
It looks like there are some efforts going on in that direction, and we
should support those, at least by understanding how important is that:
it is a stupid thing to let in bugs that can be detected automatically.
3. Increase maintainer resposiveness
====================================
Define minimal amount of work and strict feedback deadlines expected
from DD before he is MIA and his packages are orphaned/taken
over/removed. Like, drop packages with RC bugs after a month, as Brian
White suggested. I think, BTS should be more aggressive in handling
timeouts in general, beginning with first responce of DD to a non-wish
bug, and ending with adoption of NMUs.
Volunteer doesn't mean no responsibility, it just means Debian can't
take back from you more than it has given to you. You are given a right
to manage a part of Debian (packages you maintain), and you were given
responsibility to actually work on that part of Debian. The package is
not your property, it's Debian's commons, if you are not working on it,
you can be disposessed of it.
Having multiple maintainers for a single package can also help with this
problem. Subscribing to package bugs or loosening NMU procedures is
helpful, but I think we need to go one step further. The missing piece
is a collaboration area for several people working on a single package,
where they can share the code that is not ready for incoming yet. I'm
not sure Experimental is good enough for that.
Note that I am against requiring that packages are signed by more than
one developer: in my opinion, it trades too much time lost for
negotiation in exchange for too little quality gained from review.
Package entry barrier should be as automated as possible, let's rather
think how can we fit more automated testing in new incoming system.
--
Dmitry Borodaenko
Reply to: