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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
