Rethinking proventester and critpath

[Nils Philippsen]

On Mon, 2011-11-21 at 10:32 -0800, Adam Williamson wrote:

> red_alert (sandro mathys): critpath packages should have detailed test plans

Hm. The list of (implicitly labeled) critpath packages seems to have
proliferated recently: a few days ago I submitted an update for
sane-backends and then found out that it's on critpath, probably by way
of critical-path-gnome -> control-center -> colord ->
sane-backends-libs. On the one hand it would probably be a good idea to
notify maintainers of such packages being implicitly pulled in (in this
case when BR: colord-devel was added to control-center). On the other
hand, sane-backends is a particularly nasty case and a detailed test
plan would probably start with this:

0. Have a lot of scanners handy, or at least models affected by the
changes.

Not even I get past that point in most cases: I have one USB scanner in
the office, and two rather ancient SCSI models at home. The only thing I
can meaningfully test is these models/their drivers and the
HW-independent parts of the package, and I don't expect more from the
testers. With the package being critpath now, I fear that updates for
sane-backends might never see the light of day, depending on the HW
affected, unless Bruno's proposal (two weeks of wait for critpath
without needed and no negative karma) or enough (proven)testers are
content with only cursory testing :-/.

Don't get me wrong: I'd really like sane-backends to get as much testing
as possible before turning updates loose on the unsuspecting public. I
just don't see how it can be done right at the moment.

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils at redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011