Blockers via flags?

[Adam Williamson]

On Mon, 2010-05-17 at 10:52 -0700, Jesse Keating wrote:
> On Sun, 2010-05-16 at 11:26 +0100, Adam Williamson wrote:
> > On Tue, 2010-05-11 at 10:31 -0700, Jesse Keating wrote:
> > 
> > > > What you'd loose with using flags is the "distro version" context.
> > > 
> > > Erm, the bug would be filed against a particular version.  EG the bug
> > > has to be filed against Fedora 14 in order to be able to use flags to
> > > mark it as a blocker for Fedora 14.  Bugs filed against rawhide wouldn't
> > > necessarily be able to set flags (although that's an interesting
> > > discussion to have)
> > 
> > This could give us a problem; remember, bugs in preupgrade and
> > livecd-tools in F(N-1) can block F(N) (as is the case with F13, and was
> > the case with F12).
> 
> Right, those are sticky situations, but as you'll see, we're not
> actually slipping the release or blocking it in anyway for this
> preupgrade issue.  We're just hoping that it gets fixed on F12 in time.

That certainly wasn't my understanding when we set it as a release
blocker, but we're getting off track; perhaps we should talk about that
in the F13 retrospective.

> > Overall, though, I'm fine with this idea. As I said last time we
> > discussed it, my principal objection is that it hurts our efforts to get
> > people to buy into the process in the short term, but I can live with
> > the idea that in the long-term the benefits will be enough to counteract
> > that.
> 
> How does it hurt again?

It's a new process for people to learn, just when we've more or less got
them trained to use the current one =) We definitely had more people
outside of QA nominating bugs as blockers in the 13 cycle than in 12. As
I said, it's not a huge problem, just worth a note. Of course, if we
switch to flags, we need to remember to update all documentation which
refers to the current process.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net