1 |
Hi all, |
2 |
|
3 |
On Mon, 1 Feb 2016 20:25:20 +0100 Justin Lecher (jlec) wrote: |
4 |
> Dear all, |
5 |
> |
6 |
> the Gentoo Council will meet again on Sunday, February 14 at 19:00 UTC |
7 |
> in #gentoo-council on FreeNode. |
8 |
> |
9 |
> Please reply to this message with any items you would like us to discuss |
10 |
> or vote on. |
11 |
|
12 |
I'd like to ask the Council on the matter of bugs assignment |
13 |
automation. The issue is discussed in the following thread: |
14 |
|
15 |
https://archives.gentoo.org/gentoo-dev/message/c9675f0359679007054b57de123c0bf3 |
16 |
|
17 |
The first question: Should we automate bugs assignment if one and |
18 |
only one valid "category/package" is present in the bug's title? |
19 |
|
20 |
1. Yes, automate assignment of all new bugs. |
21 |
2. Yes, but only allow such automation for users with bug |
22 |
assignment capabilities (e.g. put a button for bug-wranglers). |
23 |
3. No, keep current status quo. |
24 |
|
25 |
The second question (only if answers 1 or 2 were selected for the |
26 |
first question): Should we automate assignment for bugs with |
27 |
multiple maintainers? |
28 |
|
29 |
1. Yes, assign to the first maintainer, CC all other. |
30 |
2. No, leave this bugs to bug-wranglers. |
31 |
|
32 |
The third question (only if answer 1 was selected for the first |
33 |
question): For bugs that will be automated should automation be |
34 |
delayed so, that bug wranglers will have an opportunity to review |
35 |
such bugs? |
36 |
|
37 |
1. Yes, delay bugs assignment for N day(s). (N is to be |
38 |
determined by the Council as well.) |
39 |
2. No, assign them immediately. |
40 |
|
41 |
*************************************************************** |
42 |
|
43 |
Summary of opinions (excuse me if I missed something) (roman |
44 |
numerals stands for the question number, question/answer format): |
45 |
|
46 |
I/1 |
47 |
Pros: |
48 |
a) We save a lot of the manpower. |
49 |
b) Latency of bugs handling will be decreased. |
50 |
Cons: |
51 |
a) In some corner cases it is possible that bugs will be |
52 |
improperly assigned and due to inactive developers they may be never |
53 |
be properly assigned. |
54 |
b) Incomplete bug reports will be occasionally assigned to |
55 |
developers (e.g. with missing emerge --info or build logs), thus |
56 |
developers will have to request such information themselves. |
57 |
|
58 |
I/2 |
59 |
Pros: |
60 |
a) Human check of bugs will reduce error rate for corner cases |
61 |
or incomplete bug reports which automation can't handle properly. |
62 |
b) We still save some manpower (e.g. reduce load on |
63 |
bug-wranglers). |
64 |
Cons: |
65 |
a) We loose a lot of man-power. |
66 |
b) Latency of bugs assignment and thus handling is increased. |
67 |
|
68 |
I/3 |
69 |
Pros: |
70 |
a) Keep current well-known more-or-less working state of matters. |
71 |
Cons: |
72 |
a) A huge load on bug-wranglers, most (all?) of them are devs |
73 |
which can spend their time to actually fix bugs. |
74 |
b) Large latency of bugs assignment (may be more than a |
75 |
week for some bugs and several days in general) is kept. |
76 |
|
77 |
II/1 |
78 |
Pros: |
79 |
a) A large number of packages contains multiple maintainers, so |
80 |
including them into automation process will sufficiently increase |
81 |
effectiveness of the automation. |
82 |
b) This approach already works well for tinderbox ran by Toralf |
83 |
Förster (we have a lot of good bug reports by this tinderbox). |
84 |
Cons: |
85 |
a) It is rare but possible that first maintainer is not the |
86 |
recepient where bugs should be assigned, thus real assignee will be |
87 |
in the CC. |
88 |
|
89 |
II/2 |
90 |
Pros: |
91 |
a) Probability of bug assignment (versus CC'ing) to the wrong |
92 |
maintainer is eliminated. |
93 |
Cons: |
94 |
a) A whole lot of packages is excluded from the automation |
95 |
process. |
96 |
|
97 |
III/1 |
98 |
Pros: |
99 |
a) Probability of catching incomplete reports or wrong bug |
100 |
assignments by the human being is increased. |
101 |
Cons: |
102 |
b) Burden on bug-wranglers is increased considerably. |
103 |
c) Latency of bugs assignment and handling is increased. |
104 |
|
105 |
III/2 |
106 |
Pros: |
107 |
a) We save a lot of manpower for actual Gentoo development. |
108 |
b) Zero latency in assignment may lead to faster bugs resolving |
109 |
and improved user experience. |
110 |
Cons: |
111 |
a) In corner cases bugs may be misassigned. |
112 |
b) If bugs are not complete, developers will have to request |
113 |
required information themselves. |
114 |
|
115 |
Best regards, |
116 |
Andrew Savchenko |