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 - > workflow. 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 this soon. 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 everybody." 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 bugs. 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 actively triaged. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
