Solid idea.
+1
-AdamM (from Android )
On May 10, 2010 10:23 PM, "Jesse Keating" <jkeating@xxxxxxxxxx> 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.
Anyway, there are little bits of detail here and there to work out, but
I wanted to float this idea while the current blocker process was still
fresh in people's minds. And it would be nice to have a different
discussion on this list. Please keep in mind that the idea behind this
isn't to stifle work in any way; The intent is to help developers make
decisions on what issues have higher priority than others, and to add
more openness and transparency to one of the things we do which seems
like a black hole to some people.
What say you?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
