[Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1

[Adam Williamson]

On Wed, 2011-07-13 at 19:25 +0000, "Jóhann B. Guðmundsson" wrote:
> On 07/13/2011 07:17 PM, James Laska wrote:
> > Your ideas are consistent with how we've handled this before, I don't
> > think I could have articulated nearly as well though:)   My
> > understanding is that FESCO is the right place to discuss whether a
> > feature should block a release or not.
> 
> They already did and decided that what's on core + base + base-x would 
> become alpha blockers which later got extended to included services we 
> ship on the live cd.

I think we could still talk to them about tweaking that process, though.
I could easily be misinterpreted here, so I'll try to be precise...

We've set up this whole blocker bug process that works quite smoothly to
achieve what it sets out to achieve: validate the quality of the
release. We have the release criteria and the blocker bug SOP and the
system of bugs and meetings to carry it all out. That's great.
Ultimately what the process achieves is QA's sign-off on the release: if
there are no blocker bugs we say 'this release meets Fedora's quality
standards'.

Now, it should always be true that if there are any blocker bugs, the
release cannot go out. *But*, crucially, the converse is not true: it is
not inevitably be the case that if there are _no_ blocker bugs, the
release _must_ go out. All it means is that we - the QA group - sign off
on the release and say as far as we're concerned, it's okay to go out.
QA isn't the *only* group that signs off on releases. FESCo does too. As
I see it, it'd be perfectly fine for FESCo to say 'well, even though it
meets all the quality standards, we do not want to sign off on this
release until Feature X is done'. As I see it, that's a _separate_
process from the blocker bug / release validation process. FESCo does
not need to use the blocker bug process to manage its decision to sign
off on the release, and I think it would actually be better if they
didn't.

I'm dancing on pin heads here to some extent - the practical result is
going to be the same whether we use the blocker process to manage
FESCo's decisions on the feature process or whether we decide to come up
with a different process for that - but I think it helps to have
processes that are clearly and strictly defined: I think if we use
blocker bugs to manage some specific aspect of the feature process, it
dilutes both processes. I think it'd actually work out better if there
were a separate mechanism by which FESCo managed its choice of whether
or not to sign off on the release due to issues in the feature process.
Thoughts? Should I talk to FESCo about this?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw
http://www.happyassassin.net