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