A strawman proposal: "testing-x86" (Was: security in testing)
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
Reply to: