FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

[Adam Jackson]

On Fri, 2010-02-26 at 13:16 +0100, Kevin Kofler wrote:

> at the FESCo meeting on Tuesday, everyone except me seemed to be set on 
> wanting to disable the possibility to queue updates directly to stable in 
> Bodhi. The only reason this was not decided right there (with no outside 
> feedback) is that Matthew Garrett (mjg59) wants to write down a precise 
> policy (which may end up even more restrictive, like some arbitrary minimum 
> time period of testing).

This is needlessly inflammatory.  Matthew argued that it was premature
to take the issue to vote before knowing exactly what we were voting
for.  Three other fesco members agreed, by my reading of the logs (not
including myself, though I didn't voice it at the time as the discussion
was entirely too noisy already).  I'm also not really seeing consensus
in the logs that all direct stable pushes are inherently bad.  It was
certainly _mooted_ as an idea; that's not the same as agreeing. Finally,
you've accused the (not yet written) proposal of potentially being even
more odious than you've already made out.

By my count, that's three misrepresentations in one paragraph.  I
certainly hope they were not deliberate.

> He also noted that doing so "gives us an opportunity to discuss various 
> consequences with affected teams". But sadly, the people driving this 
> proposed change haven't used this opportunity to discuss this issue in a 
> transparent way as I would have expected (and I've been waiting for almost 3 
> days!), so I am doing it now. (We really need more transparency in decision 
> making!)

Here you're making the accusation that the proposal not being written
yet is due to some intentional opacity in constructing it.  That may
certainly be true, but I'd love to see your evidence for it.

A more parsimonious explanation is that Matthew's simply been busy the
last few days and hasn't gotten around to it yet.  Again, this may or
may not be true, but Occam's Razor suggests it's more likely.

> Some situations where I and others have used direct stable pushes in the 
> past and where I think they're really warranted and should be used:
> * A new package which doesn't replace anything, and which I verified to work 
> fine for me. It's clearly not a completely broken package and there's no way 
> it can break anybody's existing setup as nobody has that package yet.

Just to be ragingly pedantic: utterly false.

You create package A.  Someone else has created package B, with a
triggerin script on A, unbeknownst to you, and you don't have B
installed.  Your testing of A will not reflect the experience of anyone
with B installed.  B's triggerin script might rm -rf /, for example.

Yes, this is a pathological example.  Software, like humanity, is
occasionally pathological.

> * A regression which causes big breakage at least for some people slipped 
> through testing for whatever reason. We urgently want the fix to get out 
> ASAP.
> * A regression slipped through testing for whatever reason and the patch is 
> trivial. We want the fix to get out ASAP, and the risk of breakage is very 
> low.

"Slipping through testing" is itself the problem.  It means that testers
aren't using testing!  We should fix the technical and UX problems that
make testing hard to consume.

> * A trivial bugfix (like a one-line diff), tested and confirmed to fix the 
> bug by at least one person. The risk of breakage is extremely low.

If I had a dollar for every obviously correct one-line fix that broke
something, I could probably quit this software game.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100226/fd2e2216/attachment.bin