<p>Solid idea. </p>
<p>+1</p>
<p>-AdamM (from Android )</p>
<p><blockquote type="cite">On May 10, 2010 10:23 PM, "Jesse Keating" <<a href="mailto:jkeating@redhat.com">jkeating@redhat.com</a>> wrote:<br><br>So, I know a lot of you out there hate bugzilla flags, but I think we<br>
have problem with the current way we manage release blocker issues, and<br>
flags offer a potential solution.<br>
<br>
First the problem:<br>
<br>
Right now, anybody can propose a release blocker bug. This is not the<br>
problem though, the problem is that developers (and testers) have no<br>
good queryable method to determine whether the proposed blocker has been<br>
accepted or not. Why is this important? Well some (all?) developers<br>
have finite time, and our release cycle is also finite. Therefor its<br>
important that they work on the issues we would actually stop the<br>
release for. As a reporter it's also worth knowing if the bug in<br>
question will delay the release or not, so that a workaround could be<br>
researched and documented.<br>
<br>
A second problem is that we (qa, releng, devel) spend a looong time<br>
processing all the proposed blockers. This is typically done during<br>
marathon Friday meetings that can last up to 6 hours or more. That's a<br>
long time to devote to the mind numbing action of going through bug<br>
after bug after bug.<br>
<br>
A solution, flags!<br>
<br>
(our?) Bugzilla already has a method for proposal and acceptance. This<br>
is done via flags. We currently use this for package reviews and CVS<br>
admin tasks. What I propose is that we introduce a new flag once we've<br>
branched a release and created a bugzilla version for a Fedora release.<br>
That flag would be release_blocker or just blocker, or maybe<br>
{alpha,beta,final}_blocker. Anybody who has rights to modify bugs could<br>
set this flag to ?. As far as acceptance, we already look to releng,<br>
QA, and development to agree on whether a bug is a blocker or not,<br>
therefor we can express this transparently as a QA ack, a releng ack,<br>
and a devel ack. Should a bug receive these acks, the blocker flag<br>
would automatically move from ? to + and we'd have ourselves a blocker!<br>
Some of you may find this familiar if you've dealt with RHEL products.<br>
<br>
Is this going to prevent work from being done? Absolutely not. Unlike<br>
that other product, we will not be blocking our source control and<br>
buildsystem on whether or not a bug has gotten all the acks it needs or<br>
not. If you have a fix for an issue, by all means get it committed and<br>
built and proposed as an update, don't let process stand in your way.<br>
<br>
How does it solve the problem(s)? We can query against flags and find<br>
the bugs that have been accepted as blockers, which will help developers<br>
find issues which are critical to be worked on. It'll help our testers<br>
find issues which are determined to be blockers and have a fix that<br>
needs to be verified. It'll help our qa/releng folks focus on issues<br>
that are proposed but not yet accepted as blockers. It will also allow<br>
us to process potential blockers as they come up asynchronously as<br>
opposed to waiting for the next Friday grind and spend hours working<br>
through the list synchronously. Ideally that will allow us to reach a<br>
conclusion about a proposed blocker faster and with less overhead, so<br>
that we can spend the meeting time discussing the truly interesting and<br>
difficult issues that require discussion.<br>
<br>
But why releng, QA, and devel acks? Good question. 3 might be wholly<br>
unnecessary, but I believe that it is important to have voice of at<br>
least the developer and QA involved. QA can help determine if an issue<br>
touches on release criteria, or at least form the opinion that an issue<br>
is worthy of slipping a release. At the same time, QA is not<br>
omnipotent, and thus they do require input from subject matter experts,<br>
such as the developer. The releng vote could probably get tossed,<br>
releng could always just state opinion and ask for reconsideration if<br>
the outcome isn't to our liking.<br>
<br>
Anyway, there are little bits of detail here and there to work out, but<br>
I wanted to float this idea while the current blocker process was still<br>
fresh in people's minds. And it would be nice to have a different<br>
discussion on this list. Please keep in mind that the idea behind this<br>
isn't to stifle work in any way; The intent is to help developers make<br>
decisions on what issues have higher priority than others, and to add<br>
more openness and transparency to one of the things we do which seems<br>
like a black hole to some people.<br>
<br>
What say you?<br>
<font color="#888888">--<br>
Jesse Keating<br>
Fedora -- Freedom² is a feature!<br>
<a href="http://identi.ca" target="_blank">identi.ca</a>: <a href="http://identi.ca/jkeating" target="_blank">http://identi.ca/jkeating</a><br>
</font><br>--<br>
devel mailing list<br>
<a href="mailto:devel@lists.fedoraproject.org">devel@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/devel" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/devel</a><br></blockquote></p>