Bugzilla semantics: marking bugs as triaged
awilliam at redhat.com
Tue Jul 21 16:33:08 UTC 2009
On Thu, 2009-07-16 at 16:41 -0700, Adam Williamson wrote:
> I had interesting discussions with Andy Lindeberg and jlaska today about
> the semantics of our current Bugzilla - and particularly triage -
So, this was discussed at the meeting this morning, and there was some
significant movement. This email is intended to summarize the current
status and provide some options for discussion.
One concern brought up was bug mail spam. I am currently testing exactly
what changes on a bug produce an email, and what don't. I'll report on
Aside from that, Jesse Keating and Josh Boyer stated that teams they
work with use the ASSIGNED state with a different meaning from the
official one defined in the bug workflow page. For them, ASSIGNED is
used to mean that a specific person has accepted the bug and will work
on it soon.
The proposal to use a Triaged keyword to indicate that a bug has been
triaged would certainly address this issue.
Another option proposed during the meeting was that the ON_DEV state
should be used to indicate this, as its official definition is much
closer. The bug workflow page states: "This optional state is used to
show that someone is working on fixing this bug. This is especially
useful if there exists a team of maintainers for a package."
An option not discussed during the meeting but which I should add, is
that no state is actually needed to indicate this. AFAIK, all cases
where this usage is pertinent involve components owned by teams. When
bugs are first filed on these components, they are assigned to a mailing
list which represents the entire group. I contend that the simple act of
changing the assignment from the mailing list to an individual developer
is enough to indicate that the bug has been accepted by that individual
developer; no state change is needed to make this clear. Searching can
also be done on this distinction: you can search for bugs filed on a
given component and assigned to a specific developer, bugs filed on a
given component and assigned to the mailing list for that component, or
for bugs filed on a given component and *not* assigned to the mailing
list (hence, by implication, assigned to _any_ specific developer). That
gives you all the search granularity you can achieve with a state.
Matej Cepl objects to the proposed change on the grounds that it
achieves nothing (in light of the fact that there are other ways to
address the 'problem' which do not involve any change to our current
workflow definition, or mass changes to Bugzilla) and is a disruptive
and potentially damaging change to make to a large number of existing
bugs. In his words:
"Moreover, I don't believe for a second that conversion from ASSIGNED to
something else would be that simple as you would like to see it ...
there are tons of tiny shifts in meanings of individual components which
could be lost and make even bigger mess than it is.
So, if the only reason for this is to include anaconda to the crowd,
then I would say, it's better to make some huge exception for them, than
to make earthquake which would make a life more difficult for
I think we can accept Matej's framing: the question is whether changing
the official definitions, and possibly adjusting all current bugs to use
the keyword, provides a significant enough advantage to outweigh the
disadvantage of disruption and potential errors introduced in current
I present three options:
1) Leave everything unchanged, both in Bugzilla and in the workflow
definition. Encourage components which currently use ASSIGNED in a
non-standard way to use ON_DEV or no state change, as discussed above.
2) Change practice for Bugzappers going forward: from some date forward,
all triaged bugs should have the Triaged keyword set rather than being
changed to ASSIGNED. Do not change anything about any existing bugs.
3) Change practice for Bugzappers going forward, as in proposal 2), and
also attempt to convert existing bugs by adding the 'Triaged' keyword to
all bugs in ASSIGNED status on all components which are currently
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
More information about the fedora-test-list