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