Vincent Bernat <ber...@debian.org> writes: > ❦ 9 mai 2013 21:49 CEST, Lars Wirzenius <l...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8761yrn9sf....@windlord.stanford.edu
