Annoying QA fails: NetworkManager

So, if you're running a 32-bit Fedora 15 install, you might notice that NetworkManager stopped working right with the NetworkManager-0.8.999-3.git20110526.fc15 update. Sorry about that.

So, aren't we supposed to have a procedure in place to stop completely broken upgrades of major critical packages going out? Well...yes. Did it work in this case? Why not? Click the link above: you can see the upgrade got five positive votes from non-anonymous users, including a proven tester. Are all these people on crack? Well, I can't vouch for Kevin, but I think the rest of them have been sober for a while now ;). The problem is that the update works great on 64-bit systems - and that's what all those testers are using. They tested diligently and gave an appropriate result, and the update still went out.

So, could we fix this? Well, it's tough. We could, of course, simply hold updates until they have positive responses from users of both architectures (this wouldn't be too crazy difficult to achieve technically) - but we're loath to make the requirements any more stringent, because we already have a problem with the more difficult-to-test critical path packages getting stuck in updates-testing for a while until they have the necessary karma to get out.

In the end, we have to remember the critpath process is a best effort: we can't really make it catch every bug without imposing too many restrictions on the update flow. It's a shame we missed this one, though.

There's a scratch build available which fixes the problem; I expect it'll go out as a proper update candidate soon.


Aidan wrote on 2011-05-31 20:39:
Is it possible to divide packages into two sets like the old core/else divide, but more of a high-qa/lower-qa divide? This would ensure that tighter qa procedures are followed for NetworkManager, GDM, kernel etc... but not for JimBobsTextEditor.
adamw wrote on 2011-05-31 21:27:
This is already the case; that's the mention of 'critpath' components. Critical path components have a higher bar than non-critpath. The thing is, some packages are critical path but are still somewhat difficult to test fully, so we still can't set the critpath standards too high.
[...] Annoying QA fails: NetworkManager [...]