Blockers via flags?

[James Laska]

On Mon, 2010-05-10 at 20:23 -0700, Jesse Keating wrote:
> So, I know a lot of you out there hate bugzilla flags, but I think we
> have  problem with the current way we manage release blocker issues, and
> flags offer a potential solution.
> 
> First the problem:
> 
> Right now, anybody can propose a release blocker bug.  This is not the
> problem though, the problem is that developers (and testers) have no
> good queryable method to determine whether the proposed blocker has been
> accepted or not.  Why is this important?  Well some (all?) developers
> have finite time, and our release cycle is also finite.  Therefor its
> important that they work on the issues we would actually stop the
> release for.  As a reporter it's also worth knowing if the bug in
> question will delay the release or not, so that a workaround could be
> researched and documented.
> 
> A second problem is that we (qa, releng, devel) spend a looong time
> processing all the proposed blockers.  This is typically done during
> marathon Friday meetings that can last up to 6 hours or more.  That's a
> long time to devote to the mind numbing action of going through bug
> after bug after bug.
> 
> A solution, flags!
> 
> (our?) Bugzilla already has a method for proposal and acceptance.  This
> is done via flags.  We currently use this for package reviews and CVS
> admin tasks.  What I propose is that we introduce a new flag once we've
> branched a release and created a bugzilla version for a Fedora release.
> That flag would be release_blocker or just blocker, or maybe
> {alpha,beta,final}_blocker.  Anybody who has rights to modify bugs could
> set this flag to ?.  As far as acceptance, we already look to releng,
> QA, and development to agree on whether a bug is a blocker or not,
> therefor we can express this transparently as a QA ack, a releng ack,
> and a devel ack.  Should a bug receive these acks, the blocker flag
> would automatically move from ? to + and we'd have ourselves a blocker!
> Some of you may find this familiar if you've dealt with RHEL products.
> 
> Is this going to prevent work from being done?  Absolutely not.  Unlike
> that other product, we will not be blocking our source control and
> buildsystem on whether or not a bug has gotten all the acks it needs or
> not.  If you have a fix for an issue, by all means get it committed and
> built and proposed as an update, don't let process stand in your way.
> 
> How does it solve the problem(s)?  We can query against flags and find
> the bugs that have been accepted as blockers, which will help developers
> find issues which are critical to be worked on.  It'll help our testers
> find issues which are determined to be blockers and have a fix that
> needs to be verified.  It'll help our qa/releng folks focus on issues
> that are proposed but not yet accepted as blockers.  It will also allow
> us to process potential blockers as they come up asynchronously as
> opposed to waiting for the next Friday grind and spend hours working
> through the list synchronously.  Ideally that will allow us to reach a
> conclusion about a proposed blocker faster and with less overhead, so
> that we can spend the meeting time discussing the truly interesting and
> difficult issues that require discussion.
> 
> But why releng, QA, and devel acks?  Good question.  3 might be wholly
> unnecessary, but I believe that it is important to have voice of at
> least the developer and QA involved.  QA can help determine if an issue
> touches on release criteria, or at least form the opinion that an issue
> is worthy of slipping a release.  At the same time, QA is not
> omnipotent, and thus they do require input from subject matter experts,
> such as the developer.  The releng vote could probably get tossed,
> releng could always just state opinion and ask for reconsideration if
> the outcome isn't to our liking.

I like the idea of having multiple flags, however am concerned that it
is a significant documentation/training challenge.

Is there benefit in rolling this out in phases?  Part#1 would involve
adding only a 'blocker' flag to allow for improved query and 3 blocker
request states (requested, accepted, rejected).  Part#2 would add the
team specific blockers (devel, releng and qa) and an automated mechanism
to approve/reject 'blocker' requests based on these new flags.

Thanks,
James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100518/8388703c/attachment.bin