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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
