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 - > > 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. > 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 adjusted. 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. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
