❦ 9 mai 2013 21:49 CEST, Lars Wirzenius <liw@liw.fi> : > * Remove RC buggy packages sooner rather than later. An RC buggy > package should be removed at soon as possible: when the bug > is identified, allow a bit of time for the bug to be verified > (was it actually an RC bug?), but after that, remove the package > from testing, preferably automatically. If the package has > reverse dependencies, remove those as well. This keeps testing > releasable. The removed package can and will re-enter testing once > it gets fixed. I think that's a very good idea. A threshold on the number of source packages that can be removed from testing due to an RC bug could be something like 10. The release team should be entitled to delay the removal if the bug is quite complex. I think that the other things you propose are too complicated: > 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. > Tests for running reference installation might include the following: > > * Basic networking setup works: System responds to ping from the outside. > * Mail server responds appropriate on the SMTP, submission, IMAPS, and POPS > ports. > * LAMP server responds on the HTTP and HTTPS ports. > * A desktop system that automatically logs in a test user has the right > processes running, and can start some common applications. > * In each case, it's possible to log in remotely with ssh and run > "sudo apt-get install hello". 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? > 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? -- /* * Should be panic but... (Why are BSD people panic obsessed ??) */ 2.0.38 /usr/src/linux/net/ipv4/ip_fw.c
Attachment:
pgpYnTpjCDfgN.pgp
Description: PGP signature