On 02/26/2010 01:16 PM, Kevin Kofler wrote: > 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! * Many (most) packages get pushed without testing. I consider people who believe package to see tested in "testing", to be in error. To me, "testing" isn't much more but a delay queue. * Some maintainers ignore feedback on "packages in testing". * Some packages will never be "100% stable" (e.g. the kernel, gcc, kde). * The bugs with the highest visibilty are packages adding broken package dependencies. The fact these make it into the repos is a defect of Fedora's infrastructure. * Banning direct pushes does not prevent Fedora from being hit by bad SW. > But even if you just agree with > me, please reply so the other FESCo members don't think it's just me! I think this FESCO is heading the wrong way. The real problem is not "broken updates", the problem is "badly maintained packages", "careless maintainers", "overzealous developerss" and defects of Fedora's infrastructure. Particularly delicate are cases when "upstream" and "maintainer" are identical. Ralf -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
