On 5/10/2010 22:23, Jesse Keating wrote:
(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.
This sounds like a decent idea to me, but I have a couple
questions/suggestions.
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 ?.
Fedora only has one branched, yet unreleased release at a time. Can we
recycle the same tag(s) for every release instead of creating new ones
every time?
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.
I don't understand how using a flag instead of a tracking bug makes this
less work. Under the current system proposed blockers show up, get
discussed, then possibly shot down. Under your proposed system proposed
blockers will show up, get discussed, then possibly acknowledged as
such. Where is the time savings?