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?
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
