On Thu, 2016-10-06 at 00:36 +0200, Kevin Kofler wrote: > > In fact, I would argue that this should even be done for blockers: A bug > should be a blocker if and only if a SIG/WG behind a release-blocking image > decides that it is important for it to be fixed in the release, no matter > whether it fits into any kind of global formal criteria. We base the criteria heavily on SIG/WG input. I prefer this to the idea of just letting SIGs/WGs declare whether bugs are blockers because the point of the criteria is to try to produce consistent and predictable decisions, so far as that's possible; if we just say 'blockers are whatever SIGs decide' we're either going to get inconsistent decisions, or we're going to have each SIG/WG having to do the work of implementing criteria and a blocker review process separately, which just seems like extra bureaucracy. If you're unhappy with any of the criteria from a KDE perspective, we absolutely can adjust them. We want the criteria to be agreed upon, they're not carved in stone and imposed upon you. Also, as a practical matter, the people who mainly actually show up to do the work of blocker review are QA, releng and 'management' folks (i.e. FPL and FPM). In theory blocker review is supposed to be done with equal input from QA, 'development', releng and 'management', but in practice we rarely get many 'development' folks showing up. sgallagh is usually there and could be counted as a Server rep, we sometimes get someone from Workstation, but there's rarely anyone from Cloud or KDE (apologies if I'm forgetting anyone). > And punting > blockers should also only be possible if the responsible SIG/WG agrees with > it. As long as the SIGs and WGs for all release-blocking images have not > signed off on the release, we should slip, even if it takes weeks (and to > avoid long freezes, a slip should consist of accepting ALL pending updates > and restarting the freeze process from scratch – that should also > singificantly reduce the need for freeze exceptions). I don't think this would be an improvement. As long as a 'Fedora release' is as big and messy of a thing as it is right now, involving a zillion deliverables and teams, I don't think it makes sense to declare that certain groups have a complete veto on shipping. The current process is pretty collaborative between all the stakeholder groups, I'd say. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
