Re: Debian development and release: always releasable (essay)
Vincent Bernat <bernat@debian.org> writes:
> ❦ 9 mai 2013 21:49 CEST, Lars Wirzenius <liw@liw.fi> :
>> A package that is not included in one or more of the reference
>> installations is a package we want to include in the release, but we
>> will not delay the release for its sake. We should have a low threshold
>> for removing such a package from testing: it could perhaps even be
>> removed automatically one week after an RC bug is filed against it
>> (assuming the bug affects the version in testing).
> If a package is important, an RC bug will get noticed and someone will
> step to fix the RC bug or ask for a delay. This avoids unnecessary
> debate on what is important and what is not and people fighting to get
> their packages in the right list.
Personally, I think it's important to be more transparent and systematic
about how we designate packages as important or not important; it will add
clarity and it will let us be more efficient and encourage people to be
bold. The fact of the matter is that we already have those distinctions:
we will remove random leaf packages from testing as soon as the release
gets close, but we're not going to remove cron or bash. But the
distinctions are fuzzy and require people to make (and then argue about)
judgement calls. We can't eliminate the arguments entirely, but I think
we can approach the process in a cleaner way that will require less
constant debate.
Package sets for critical purposes are useful in their own right. They
make it clear why a package is important (and also why it may *cease* to
be important), and they also provide a basis for automated testing.
Personally, I'd be inclined to unify optional and extra (which at this
point don't really represent a meaningful difference) and possibly even
further simplify our use of priorities (it's not clear to me that standard
is really buying us anything any more), replacing most of that with
package sets for key use cases that we want to support.
One interesting possibly that this would also open up (and please
understand that I don't know if this would happen and I'm not positive
that it's a good idea; I'm just throwing it out there) is that the teams
who most care about a particular reference package set could also do some
of the release management duties for that package set. For example,
suppose we had a LAMP team of experts in that package set. Could they
possibly take on, not just maintaining the list of packages, but doing
freeze reviews and transition coordination for transitions that are
contained within that set?
To some extent, the desktop packaging groups (GNOME, KDE, etc.) already do
some of this for those desktop environments, and I think that's quite
helpful and might be useful to formalize further.
> Many people run unstable and a bug that would fail those kind of tests
> would get immediatly noticed and many bug reports are usually opened at
> once for each of those bugs. Maybe those tests would catch them one hour
> earlier but is it worth spending time to conceive those tests?
Yes, absolutely. Because when you have the tests, it opens up all sorts
of possibilities for automation. For example, you could, in the future,
put newly-uploaded packages in a holding area until the tests pass and not
allow them into the archive until they do.
Breakage bugs in unstable are very valuable, but they also represent
*breakage* and take someone's time and attention to write up. Anything we
can catch on an automated basis saves precious human resources.
>> These are trivial, even simplistic tests. However, if they pass, we
>> know that at least the basic, fundamental things in the system are not
>> horribly broken: networking, system administration, and the software
>> that is meant to start in that reference installation. Furthermore, we
>> know that the debian-installer works. That's a good foundation for
>> further hacking.
> Maybe the installer is less daily tested but did we already have a major
> bug (one that does not pass the test you described) gone unnoticed?
We've had system-breaking bugs in core packages like libc6 enter the
archive in the past. They don't make it through to testing, no, but they
do take up people's time and attention in unstable, and it's all more
resources that we can't spend on other things that are more useful. And,
over time, the tests can become more sophisticated. That's the great part
about building a testing framework: once you have a good framework in
place, it becomes much easier to add more tests, and you can build
something like Lintian (which is now quite extensive) from a modest
beginning.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: