Hi, guys. Just a general issue mail for Bugzappers: I've recently been talking to Seth Vidal, who wants special treatment for bugs in components he maintains (yum and createrepo): he's happy for them to be triaged according to the usual process, but he doesn't want the bugs changed from NEW to ASSIGNED.
As a general principle, we should accept requests like this from the owners of components, because we're here for them and not vice versa; if our procedure doesn't work for them we should vary it so that what we do is helping them and not frustrating them. We have a regular triager for yum / createrepo who is aware of this (Jon Stanley), but anyone else who happens to touch yum / createrepo bugs in future, please follow this request.
We used to have a Special Procedures wiki page for exceptions like this; it seems to have got pretty much lost in the recent wiki re-design. For now I've revised https://fedoraproject.org/wiki/BugZappers/Components_and_Triagers#Set_Compon... to add a new 'Special' column where we can add special instructions like this - I think that should be a good way to do it, as it's a high-visibility page that everyone should be looking at before triaging any given component. I envisage that short requests (like this one) can go directly in the table, longer ones could be added as footnotes (or to a separate page) and linked from the table.
(I took out the statistics from it, as discussed at the last meeting, because they're obsolete and not helping anyone now, and the table would've been getting too wide with those in it).
Does this seem sensible to everyone?
Thanks!
Adam Williamson wrote:
Hi, guys. Just a general issue mail for Bugzappers: I've recently been talking to Seth Vidal, who wants special treatment for bugs in components he maintains (yum and createrepo): he's happy for them to be triaged according to the usual process, but he doesn't want the bugs changed from NEW to ASSIGNED.
As a general principle, we should accept requests like this from the owners of components, because we're here for them and not vice versa; if our procedure doesn't work for them we should vary it so that what we do is helping them and not frustrating them. We have a regular triager for yum / createrepo who is aware of this (Jon Stanley), but anyone else who happens to touch yum / createrepo bugs in future, please follow this request.
We used to have a Special Procedures wiki page for exceptions like this; it seems to have got pretty much lost in the recent wiki re-design. For now I've revised https://fedoraproject.org/wiki/BugZappers/Components_and_Triagers#Set_Compon... to add a new 'Special' column where we can add special instructions like this - I think that should be a good way to do it, as it's a high-visibility page that everyone should be looking at before triaging any given component. I envisage that short requests (like this one) can go directly in the table, longer ones could be added as footnotes (or to a separate page) and linked from the table.
(I took out the statistics from it, as discussed at the last meeting, because they're obsolete and not helping anyone now, and the table would've been getting too wide with those in it).
Does this seem sensible to everyone?
Thanks!
It does.
When I first read this I missed the part where you said you'd already removed the metrics, and the paged was cached for me. I didn't see the changes.
TK009
Adam Williamson said the following on 04/22/2009 03:00 PM Pacific Time:
Hi, guys. Just a general issue mail for Bugzappers: I've recently been talking to Seth Vidal, who wants special treatment for bugs in components he maintains (yum and createrepo): he's happy for them to be triaged according to the usual process, but he doesn't want the bugs changed from NEW to ASSIGNED.
How do you know which bugs you've triaged or not?
As a general principle, we should accept requests like this from the owners of components, because we're here for them and not vice versa; if our procedure doesn't work for them we should vary it so that what we do is helping them and not frustrating them. We have a regular triager for yum / createrepo who is aware of this (Jon Stanley), but anyone else who happens to touch yum / createrepo bugs in future, please follow this request.
We used to have a Special Procedures wiki page for exceptions like this; it seems to have got pretty much lost in the recent wiki re-design. For
We originally killed it because we thought there was no way to track every unique way of triaging bugs that each developer might want. After that we moved to the newer model whereby individual triagers triage bugs for specific components only.
John
On Mon, 2009-04-27 at 18:30 -0700, John Poelstra wrote:
Adam Williamson said the following on 04/22/2009 03:00 PM Pacific Time:
Hi, guys. Just a general issue mail for Bugzappers: I've recently been talking to Seth Vidal, who wants special treatment for bugs in components he maintains (yum and createrepo): he's happy for them to be triaged according to the usual process, but he doesn't want the bugs changed from NEW to ASSIGNED.
How do you know which bugs you've triaged or not?
Set keyword or whiteboard to Triaged.
We originally killed it because we thought there was no way to track every unique way of triaging bugs that each developer might want.
That is difficult, but I don't think we should decide not to try. We really need to be bending over backwards to help developers, because if we're not helping developers, we're not doing anything useful. Helping developers is the entire point of triage.
After that we moved to the newer model whereby individual triagers triage bugs for specific components only.
Significant divergences from the policy requested by maintainers should still be noted somewhere public and consistent, this is just good sense; it saves effort when a triager joins the group triaging a given component, or a handoff takes place, or whatever. "You and I just know about this but no-one else does" is never a good system...
On Mon, 2009-04-27 at 19:22 -0700, Adam Williamson wrote:
Set keyword or whiteboard to Triaged.
These are two different fields; it would be easier to do searches and maintenance if it were agreed that a particular one were to be used. (I thought "Keywords" was going to be it.)
-B.
Christopher Beland said the following on 04/27/2009 07:31 PM Pacific Time:
On Mon, 2009-04-27 at 19:22 -0700, Adam Williamson wrote:
Set keyword or whiteboard to Triaged.
These are two different fields; it would be easier to do searches and maintenance if it were agreed that a particular one were to be used. (I thought "Keywords" was going to be it.)
-B.
"Keyword" is the best choice because the integrity of the field is enforced by bugzilla and as Christopher notes, it is already present. The whiteboard field is free form and would be a bad idea.
If we go this route, we really should update the workflow diagram and description of our processes to explain this alternate route.
John
On Mon, 2009-04-27 at 20:58 -0700, John Poelstra wrote:
Christopher Beland said the following on 04/27/2009 07:31 PM Pacific Time:
On Mon, 2009-04-27 at 19:22 -0700, Adam Williamson wrote:
Set keyword or whiteboard to Triaged.
These are two different fields; it would be easier to do searches and maintenance if it were agreed that a particular one were to be used. (I thought "Keywords" was going to be it.)
-B.
"Keyword" is the best choice because the integrity of the field is enforced by bugzilla and as Christopher notes, it is already present. The whiteboard field is free form and would be a bad idea.
If we go this route, we really should update the workflow diagram and description of our processes to explain this alternate route.
I was only thinking of it being used for cases where the maintainer doesn't want the ASSIGNED state to be used, not generally.
Adam Williamson said the following on 04/27/2009 09:07 PM Pacific Time:
On Mon, 2009-04-27 at 20:58 -0700, John Poelstra wrote:
Christopher Beland said the following on 04/27/2009 07:31 PM Pacific Time:
On Mon, 2009-04-27 at 19:22 -0700, Adam Williamson wrote:
Set keyword or whiteboard to Triaged.
These are two different fields; it would be easier to do searches and maintenance if it were agreed that a particular one were to be used. (I thought "Keywords" was going to be it.)
-B.
"Keyword" is the best choice because the integrity of the field is enforced by bugzilla and as Christopher notes, it is already present. The whiteboard field is free form and would be a bad idea.
If we go this route, we really should update the workflow diagram and description of our processes to explain this alternate route.
I was only thinking of it being used for cases where the maintainer doesn't want the ASSIGNED state to be used, not generally.
Correct. If we are going to have a special work flow we should document it and explain it so people understand it as well as the regular one :)
On Mon, 2009-04-27 at 18:30 -0700, John Poelstra wrote:
How do you know which bugs you've triaged or not?
I'm adding "Triaged" in the Keywords field, and this is documented on the /Components_and_Triagers page.
I was told this keyword "already existed" in Bugzilla, but such keywords are only useful to the degree that people agree on what they mean and know to use them. Is there a central dictionary for such items? If so, I have not come across it.
-B.
We originally killed it because we thought there was no way to track every unique way of triaging bugs that each developer might want. After that we moved to the newer model whereby individual triagers triage bugs for specific components only.
It would be easier to perform system-wide tasks and recruit triage volunteers if there were universal procedures and definitions. I mean, it does make sense to vary procedure if doing so makes sense for a particular component, but I think not-particularly-necessary variations do have a cost.
-B.
Adam Williamson wrote:
Hi, guys. Just a general issue mail for Bugzappers: I've recently been talking to Seth Vidal, who wants special treatment for bugs in components he maintains (yum and createrepo): he's happy for them to be triaged according to the usual process, but he doesn't want the bugs changed from NEW to ASSIGNED.
As a general principle, we should accept requests like this from the owners of components, because we're here for them and not vice versa; if our procedure doesn't work for them we should vary it so that what we do is helping them and not frustrating them. We have a regular triager for yum / createrepo who is aware of this (Jon Stanley), but anyone else who happens to touch yum / createrepo bugs in future, please follow this request.
I think this is a step towards kaos. Even if exceptions are documented somewhere, that somewhere is something that triagers (especially new triagers) will overlook sometimes.
As far as possible, there should be a single, standard procedure that works reasonably well for everyone. That does not mean that everyone has to be entirely happy with what that procedure is - it will never happen that everyone is happy with everything, but whatever it is, everyone needs to accept that it is a reasonable compromise.
I don't propose that triagers should prescribe what that standard procedure is, by and large that should be decided by developers jointly, and considering triagers' points of view, and if needed, by arbitration.
If Seth has some concerns with triagers changing NEW to ASSIGNED, then those concerns need to be discussed with other developers, with a common approach being adopted. It might be that Seth's concerns are shared, it might be that another state, "REFERRED" might be appropriate, with the referee maybe choosing to adopt it, or to assign/refer it to someone else.
For purposes of discussion, I assume that most triagers are much less experienced than most maintainers. The triagers are the people least qualified for deciding on changes to procedures and software.
Proposing changes, yes.
Adam Williamson wrote:
Hi, guys. Just a general issue mail for Bugzappers: I've recently been talking to Seth Vidal, who wants special treatment for bugs in components he maintains (yum and createrepo): he's happy for them to be triaged according to the usual process, but he doesn't want the bugs changed from NEW to ASSIGNED.
Does he have a strong reason not to just use ON_DEV as "really assigned" ;-) ? (That's working well for us in KDE SIG.)
That said, it's unfortunate that we're abusing NEW as UNCONFIRMED and ASSIGNED as NEW (and have a nonstandard ON_DEV state which is being abused as ASSIGNED). It would make much more sense to use the standard Bugzilla terminology. This is also an artefact of sharing the RHEL Bugzilla with its nonstandard workflow. We end up trying to give meanings to the states defined by RHEL rather than defining the states we actually need and keeping close to upstream Bugzilla terminology.
Kevin Kofler
On Wed, 2009-04-29 at 02:08 +0200, Kevin Kofler wrote:
Adam Williamson wrote:
Hi, guys. Just a general issue mail for Bugzappers: I've recently been talking to Seth Vidal, who wants special treatment for bugs in components he maintains (yum and createrepo): he's happy for them to be triaged according to the usual process, but he doesn't want the bugs changed from NEW to ASSIGNED.
Does he have a strong reason not to just use ON_DEV as "really assigned" ;-) ? (That's working well for us in KDE SIG.)
I don't know, I'll try and remember to ask him.
That said, it's unfortunate that we're abusing NEW as UNCONFIRMED and ASSIGNED as NEW (and have a nonstandard ON_DEV state which is being abused as ASSIGNED). It would make much more sense to use the standard Bugzilla terminology. This is also an artefact of sharing the RHEL Bugzilla with its nonstandard workflow. We end up trying to give meanings to the states defined by RHEL rather than defining the states we actually need and keeping close to upstream Bugzilla terminology.
Yeah, we've been discussing that. It's a fairly big problem to try and get a hold of, though. I'd rather like a fix in which we can present one set of states and resolutions for Fedora bugs and another set for RHEL bugs, but I'm not sure if that's technically possible without excessive patching. I need to talk to the Bugzilla maintainer.
On Tue, 2009-04-28 at 17:21 -0700, Adam Williamson wrote:
That said, it's unfortunate that we're abusing NEW as UNCONFIRMED and ASSIGNED as NEW (and have a nonstandard ON_DEV state which is being abused as ASSIGNED). It would make much more sense to use the standard Bugzilla terminology. This is also an artefact of sharing the RHEL Bugzilla with its nonstandard workflow. We end up trying to give meanings to the states defined by RHEL rather than defining the states we actually need and keeping close to upstream Bugzilla terminology.
Yeah, we've been discussing that. It's a fairly big problem to try and get a hold of, though. I'd rather like a fix in which we can present one set of states and resolutions for Fedora bugs and another set for RHEL bugs, but I'm not sure if that's technically possible without excessive patching. I need to talk to the Bugzilla maintainer.
Couple of updates here: I've summarised this thread as it currently lies at rest for the next issue of FWN, so keep an eye out for that tomorrow. Also, on the above - I talked to David, and unfortunately for now it's not technically possible to show different statuses and resolutions for Fedora and RHEL bugs within the single Bugzilla instance. It is a feature that's previously been requested and one David is interested in, but Bugzilla itself doesn't yet have the infrastructure to make it possible. So we may have to wait a while on that one :(
Adam Williamson wrote:
Couple of updates here: I've summarised this thread as it currently lies at rest for the next issue of FWN, so keep an eye out for that tomorrow. Also, on the above - I talked to David, and unfortunately for now it's not technically possible to show different statuses and resolutions for Fedora and RHEL bugs within the single Bugzilla instance. It is a feature that's previously been requested and one David is interested in, but Bugzilla itself doesn't yet have the infrastructure to make it possible. So we may have to wait a while on that one :(
Yet another argument for a separate Fedora Bugzilla.
Kevin Kofler
On Mon, 2009-05-04 at 22:50 +0200, Kevin Kofler wrote:
Adam Williamson wrote:
Couple of updates here: I've summarised this thread as it currently lies at rest for the next issue of FWN, so keep an eye out for that tomorrow. Also, on the above - I talked to David, and unfortunately for now it's not technically possible to show different statuses and resolutions for Fedora and RHEL bugs within the single Bugzilla instance. It is a feature that's previously been requested and one David is interested in, but Bugzilla itself doesn't yet have the infrastructure to make it possible. So we may have to wait a while on that one :(
Yet another argument for a separate Fedora Bugzilla.
I sorta agree that it may be a good idea, but I don't want to make the proposal since I can't commit to doing the work it involves.
On Wed, 2009-04-29 at 02:08 +0200, Kevin Kofler wrote:
Adam Williamson wrote:
Hi, guys. Just a general issue mail for Bugzappers: I've recently been talking to Seth Vidal, who wants special treatment for bugs in components he maintains (yum and createrepo): he's happy for them to be triaged according to the usual process, but he doesn't want the bugs changed from NEW to ASSIGNED.
Does he have a strong reason not to just use ON_DEV as "really assigned" ;-) ? (That's working well for us in KDE SIG.)
Just to follow up on this: Seth says -
<adamw> skvidal: kevin kofler had a suggestion for your bugzilla situation: https://www.redhat.com/archives/fedora-test-list/2009-April/msg01671.html <skvidal> adamw: um okay <skvidal> adamw: since the 'triaging' has, in the past, not really helped with most yum bugs - I'm disinclined to change my habits in order to help the triagers adamw: so, option2: if it is possible how about yum and createrepo (and yum-utils) just opts out of being triaged, at all. <adamw> that can be done too. i don't have a problem with your option 1 either, just promised kevin i'd send that along to you.
-
Adam Williamson -
Christopher Beland -
John Poelstra -
John Summerfield -
Kevin Kofler -
TK009