Blocker Bug Voting and Conversation

[Adam Williamson]

On Tue, 2012-12-04 at 11:42 -0700, Chris Murphy wrote:

> > Anyhow, helpful thoughts would be appreciated. Hopefully we can improve
> > the process so that it's less painful for everyone and maybe even more
> > useful (at the very least, less difficult to understand).
> 
> I think the release criteria needs to define which bugs can be
> determined entirely by QA to be blockers. A significant minority of
> bugs don't need to be voted on, when they obviously cause release
> criteria to not be met, for many users, and maybe another parameter or
> two go in there. If the bug is in that category, dink, it's a blocker
> and doesn't need to be voted on. I call this delegation to and trust
> in QA, and the process. So the process needs parameters to allow for
> this.

I've thought about this too, it's clearly the case there's a bit of
unnecessary bureaucracy overhead on certain bugs. The problem is that
any time I sit down and try and find a way to fix it that won't lead to
any problems, it gets tricky. On an 'ad hoc' basis the system we used
this week - have someone go through the list and 'bin' the reports -
isn't bad, but it's relying on there being a person to do that, and
that's one more job that will probably inevitably fall to an RHian since
we can be guaranteed to be around, which increases our workload and the
perception that Fedora is just a cipher for RH, neither of which I'm
super happy with encouraging...so it's a tricky problem. Ideas welcome,
though. =)

There are a few slam dunks like 'any failure of the repoclosure test on
the DVD is a blocker', but we don't save _that_ much time with those,
because we're already fairly accustomed to them and we pretty much just
wave them through at meetings - or discuss how to fix them, which is
valuable discussion that will have to happen even with auto-approval...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net