On Wed, May 14, 2003 at 02:22:05PM +0300, Chris Leishman wrote: > I care about security in testing, and I believe others do too. But I > don't think the process should be the same as with stable releases. > Testing should not become another psudo stable distribution....it's for > testing. So I don't think security management needs to be anywhere > near as comprehensive. > > *shrug* But maybe I'm wrong and it's just me who likes to run testing > (to help out with 'testing' the distribution) but doesn't really like > the idea of having to deal with known remote security problems. Maybe > nobody else cares and I should just shut up ;-)
Well, ideally, people could test packages in unstable. When I was first started experimenting with Debian, 4 years ago, I used to use unstable. But there was a time when I got bitten with a succession of bad uploads that trashed my system one way or another --- a buggy perl or lilo upload, that was not easy to repair. So that's why I jumped to testing --- because life was too short to have to stich my system together after a careless maintainer uploaded something that obviously couldn't have been tested before the upload, and that was happening too often. But after a while, I started noticing that way too many packages were never entering testing. In many cases, it was because they were stalled because of a platform-specific bug on another architecture, or because the package depended on a specific version of a very complicated package (such as glibc), and the complicated package was stalled for one or more reasons. If a large number of packages aren't entering testing, then obviously those packages can't get the benefit of wider testing by the people who use testing. In addition, some of my machines aren't necessarily behind firewires some or all of the time. A case in point is my laptop, where I actually do all of my mail reading and most of my developing these days. (With some help from distcc :-). Not being able to get security updates is a real problem those classes of machines where the administrator is willing to be run something bleeding edge, but for which security fixes are hung up because of RC bugs in the package or in some package dependency. I've solved the problem for myself by just simply biting the bullet and using unstable. I either have gotten lucky, or maintainers of core packages have gotten much more careful about testing their packages before uploading, so I haven't gotten screwed by updates as often as I did before. If that's the case, then maybe the testing distribution has outlived its usefulness. But if people feel otherwise, then it would make sense to think of ways in which testing might be able to be more true to its original goals --- which is to expand the number of people who can test out packages before a stable release. If that's the case, then for a giving platform: * it's silly to not let a package be tested by a greater number of people if it's being held up due to a failure on an unrelated architecture. * it's silly to not let a package be tested by a greater number of people while we noodle over the question of whether the GNU FDL meets the DFSG, or whether the documentation needs to be eventually split out and put into non-free. So let me make the following modest strawman proposal. Let us posit the existence of a new distribution, which for now I'll name "testing-x86". Let's set aside the question of whether there should be "testing-arch" for every single architecture, and whether this should supplant the existing "testing" distribution. Is the following feasiable operationally, from an implementation point of view, from a space on ftp servers point of view, etc? Let us assume that there is one or more human(s) in the loop, which server as the the master of the "testing-x86" distribution. Once the required time period has been met based on the priority of the upload, if there are no RC bugs, then the package enters testing-x86 immediately. If there *are* RC bugs, notification of this fact plus a list of the RC bugs are sent to the testing-x86 master(s). If the RC bugs are "not really critical for testing", then the human(s) in the loop can make a manual decision to allow that package to enter testing-x86. Since the testing-x86 distribution is, as the name suggests, specific only for the x86 architecture, RC bugs which are specific to other platforms needn't prevent the package from entering testing-x86. In practice, does this happen? Well, let's take a look at just one package as an example, glibc. Glibc currently has 4 RC bugs. But none of them would or should prevent the glibc in unstable from this proposed testing-x86 distribution: *) One bug is specific to sparc64 (#18838) *) One bug is specific to m68k (#184048) *) And two bugs are copyright issues; one is the GNU FDL issue (#181494), and the other one is a "does the Sun RPC code meet DFSG" (#181493). (The answer to the latter seems to be yes, but the bug still hasn't been closed.) Of course, copyright issues need to be addressed before Debian ships a stable release, but do they need to be addressed before the package goes into a testing distribution?!? If the copyright issue is *that* serious that it shouldn't be in testing, then we're in just as much trouble if we leave the package in unstable --- and I don't think anybody believes that we should remove glibc from unstable until the licensing questions surrounding the FDL are resolved! :-) And of course, it gets even worse if there are a lot of packages depending on a specific version of glibc. (This used happen all the case, but doesn't any more, mercifully.) So here are my questions. Is the "testing-x86 distribution" a crazy idea? How hard would it be to implement it? What would be the problems/obstacles inherent in trying to do somethign like this? If someone implemented it, would the FTP masters be willing to accept the additional (hopefully modest) increase in disk space required to house "testing-x86"? (The last question assumes that we would want to support both "testing-x86" and the x86 binaries in the traditional "testing" distribution, at least initially, and possibly indefinitely. On the other hand, if the divergence between testing and testing-x86 is relatively small, it won't take that much disk space, and if it *does* take a lot of disk space, then it probably means that there's actually quite a lot of extra value in testing-x86, because it means that testing has gotten pretty stale and so users aren't testing the packages that need to be tested.) - Ted