1 |
On Tue, 2007-04-17 at 14:56 -0400, Doug Goldstein wrote: |
2 |
> I would like to take this time to note and re-affirm the proper bug |
3 |
> assignment policy and have it noted somewhere officially in Gentoo Policy. |
4 |
> |
5 |
> Bugs that are created for the purpose of getting arches to keyword or |
6 |
> stabilize a particular package should initially be assigned to the |
7 |
> herd/maintainer of said package with all requested arches being CCed. |
8 |
> Once all but the last arch has keyworded said package, it is acceptable |
9 |
> and proper for a bug wrangler and/or maintainer/herd to re-assign the |
10 |
> bug to the last remaining arch and they remove that arch from CC. They |
11 |
> should add their herd/maintainer to the CC of the bug. |
12 |
|
13 |
This has various possible issues. Let me list some: |
14 |
|
15 |
a) The bug moves from saved searches of "bugs assigned to my team" to |
16 |
"bugs my team is CC'ed to" - two saved searches that big teams have to |
17 |
differentiate bugs to their packages with bugs to someone elses packages |
18 |
that are requesting comments from the team. That moving of bug to a |
19 |
different list then happens through the actions of a third party |
20 |
|
21 |
b) Similarly, then keywording/stable bugs for a team are mixed up |
22 |
between "assigned directly to our team" and "our team is on the CC |
23 |
list", so there is no good overview (seeing both types at once could |
24 |
mean a bug list of 400, for example instead of 200 and 200) |
25 |
|
26 |
c) Arch teams have to look at both CC and assignee lists of them to find |
27 |
stabling bugs, while initial keywording bugs (by users of that arch) are |
28 |
usually always assigned directly to them. Having marking stable bugs as |
29 |
both assigned and CC'ed (depending on if they are last or not) means |
30 |
they need to look at all at once to grasp everything. I don't know if |
31 |
this is a potential problem or not as I'm not a member of any arch teams |
32 |
at this point |
33 |
|
34 |
d) (I think) The slacking arch gets a bug resolved count into GWN stats |
35 |
if they close the bug with them being the assignee (due to the |
36 |
reassignment as proposed) instead of the team managing that package. The |
37 |
quicker arches should have that benefit if any, not the last one. |
38 |
|
39 |
These are some of the things that bother me about this proposed policy, |
40 |
as a member of a big team with hundreds of open bugs - and not |
41 |
necessarily said team(s). |
42 |
|
43 |
> Once the last remaining arch has completed the bug, it is up to them to |
44 |
> close it. They know it's up to them to close it since the bug is |
45 |
> assigned directly to them. |
46 |
|
47 |
In practice the last arch in CC list already does that almost always if |
48 |
there are no other raised issues on the bug, so that is not a problem. |
49 |
|
50 |
> This helps keep bugzilla tidy and makes it easy to identify |
51 |
> stabilization/keywording requests which are a priority for that arch to |
52 |
> take care of. |
53 |
|
54 |
I wouldn't automatically consider stabilization bugs that have one last |
55 |
arch to do the job be more important than bugs that have multiple arches |
56 |
to take care of still. |
57 |
This is usually only important for cleanup of ebuilds, and that's |
58 |
cosmetical, while usually perceived very bothering by the maintaining |
59 |
team. |
60 |
|
61 |
I think the idea in a subthread about special keywords for these two |
62 |
types of things would be great, as then we can create saved searches |
63 |
that either include only bugs with one or both of these keywords, or |
64 |
that exclude bugs with any of these keywords. I'm not sure if this being |
65 |
a keyword, as opposed to a different bugzilla property is the best, |
66 |
though, especially when it comes to having people actually use it |
67 |
consistently. Perhaps a javascript button would help then, akin to the |
68 |
helper for arch CC'ing. |
69 |
|
70 |
-- |
71 |
Mart Raudsepp |
72 |
Gentoo Developer |
73 |
Mail: leio@g.o |
74 |
Weblog: http://planet.gentoo.org/developers/leio |