Hi,
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).
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!)
I would like to collect feedback on this issue. If you want to disable
direct stable pushes, why? Could there be a less radical solution to that
problem (e.g. a policy discouraging direct stable pushes for some specific
types of changes rather than a blanket ban)? On the other hand, if (like me)
you DON'T want that feature to go away, please provide valid use cases.
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.
* 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.
* 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 you can think of more, please post them! But even if you just agree with
me, please reply so the other FESCo members don't think it's just me!
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
