Adam Williamson said the following on 07/16/2009 04:41 PM Pacific Time:
I had interesting discussions with Andy Lindeberg and jlaska today about
the semantics of our current Bugzilla - and particularly triage -
workflow.
We were thinking about the NEW / ASSIGNED dichotomy, and Andy and I came
to the conclusion that it doesn't really make a lot of sense.
Right now, Bugzappers uses it one way, Andy uses it another for
anaconda. In the Bugzappers process, ASSIGNED just means, really,
Triaged: you set a bug to ASSIGNED once the triage process is complete.
For Anaconda, Andy sets bugs to ASSIGNED once they're assigned to the
correct anaconda maintainer (whether or not the rest of triage is yet
fully completed).
Neither case is really terribly problematic, but they also don't make a
whole lot of sense, really. Having 'triage completed' as a status is a
bit arguable; it's not quite in the flow of the statuses, as a bug could
be at a point 'beyond' ASSIGNED but not yet have been triaged, for
instance. And it's also just semantically wrong - the word 'assigned'
does not mean 'triaged'.
In the anaconda case, we just thought about it and decided the use of
ASSIGNED isn't really _achieving_ anything: you can tell whether the
bug's been assigned or not just by looking at who it's assigned to.
We sort of came to the conclusion that it'd probably make the most sense
to have a 'Triaged' keyword that's used to affirm that a bug's been
triaged (in fact there already is one, but it's not officially used in
our current process), and abandon the distinction between NEW and
ASSIGNED. Ideally, the ASSIGNED state would just be removed, but we
could keep it and just note in our workflow / policy that it's not
really used to mean anything in particular.
This could, I think, be implemented quite quickly if desired; I think we
could rig something up to set all bugs in ASSIGNED state (except
anaconda ones) to have the 'Triaged' keyword, that shouldn't be
impossible.
We'd be interested in thoughts - negative, positive, whatever - on the
idea. Thanks!
This has been discussed at length before. I believe the initial
reluctance was changing the set process for a handful of people that
wanted to do things differently and then trying to keep track of that.
One major reason for not changing the state definitions was that the
Fedora usage of the bug states was the same as RHEL.
At one time I thought the "keyword" approach was a good idea and it
still seems to make a lot of good sense... I can't remember why we
didn't move forward with it, but as you explain, it seems like a good
compromise.
John
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
