On Tue, 2009-07-21 at 09:33 -0700, Adam Williamson wrote:
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
I would like to point out again for the record that it seems to me that
the primary reason bugzappers are altering the bug, in any way, is to
mark that they've been there, done that, and to avoid having duplicate
effort by other triagers on the same bug. I know it's not the only
reason, but it seems to be the most significant.
It's also worth pointing out that while there is an "official" meaning
of ASSIGNED, it's meaning has been contrived by the bugzappers crowd
whether or not the entire maintainer set agrees with it, and I think
it's abundantly clear that not all maintainers agree.
Given that we have a primary concern of marking the bug as having been
triaged, and we know already that the use of ASSIGNED is controversial,
I believe it is in the best interest of bugzappers to find a different
way of marking the bug, such as a keyword. This accomplishes the
primary (and other) goals, and completely side steps the arguments of
bug states. This allows maintainers and teams to manage their own
states as they see fit and still provides the information to them and
other zappers that the bug has indeed been triaged.
I appreciate that there will be churn, and a period of time where both
state and a keyword would indicate triaged or not. I also appreciate
that this issue should have been discussed better from the onset rather
than months and months into the effort. However as often with Fedora,
you don't get your complaints until you start acting upon your
decisions, and it's always good to review your decisions after those
effected by them have had a chance to witness first hand what is going
on. We have had swaths of packages/packagers completely opt-out of the
triage process due to disagreements of how things are going, and instead
of just accepting that and moving on, I'm trying to reach a happy medium
where triage efforts can cover more packages and packagers, and those
packagers are more willing to let the work be done, as they /do/ see
value in it. It really comes down to the execution, which can be
If it were just about one team, I'd agree, let that team do their own
thing, zappers move on ahead. It isn't though and that's why I've taken
an interest in seeing this work out. Complaints have bubbled up and
been over heard, and I'm representing those complaints, whether the
complainers want me to or not (:
Anyway that's my pitch, take it as you will.
Fedora -- Freedom² is a feature!