1 |
Now into it's Nth great year, I bring you the fourth edition of the |
2 |
automatic assignment proposal. </truman-show> |
3 |
|
4 |
Previously: |
5 |
http://thread.gmane.org/gmane.linux.gentoo.devel/48485 [v1] |
6 |
http://thread.gmane.org/gmane.linux.gentoo.devel/49601 [v2] |
7 |
http://thread.gmane.org/gmane.linux.gentoo.devel/57159 [v3] |
8 |
|
9 |
Bleeding edge prototype: |
10 |
http://dev.gentoo.org/~rbu/assign.py |
11 |
MANY thanks to rbu. |
12 |
|
13 |
If there are no further changes or objections at this time, it would be |
14 |
nice to implement this by the end of November. |
15 |
|
16 |
How is it integrated into workflow? |
17 |
=================================== |
18 |
(This was raised by halcy0n at the v3 review, and replaces the previous section |
19 |
on triggering). |
20 |
1. Bugs are still filed as normal, with the same default assignees |
21 |
(bug-wranglers most commonly). |
22 |
2. In the wrangling process, we add a new button to the page, labelled: |
23 |
"Suggest assignment". |
24 |
3. Optionally, the wrangler edits the summary line right now, but does not hit |
25 |
'Submit' yet. |
26 |
4. The button causes a (javascript) query back to the server (also |
27 |
available as a web service for other usage). The only data sent is the |
28 |
'Summary' string. |
29 |
5. Javascript then appends the server results into the "Additional |
30 |
Comments" box: a suggested assignee and suggested CC values, with logic |
31 |
as to why. |
32 |
6. The wrangler can copy and paste the data into the fields, editing |
33 |
further as desired. |
34 |
|
35 |
(Putting the data into the comments allows the assignment tool to |
36 |
explain WHY it decided certain actions). |
37 |
|
38 |
Assignment/CC computing: |
39 |
======================== |
40 |
Step 1 - Summary line processing |
41 |
-------------------------------- |
42 |
1. If the summary line contains a package atom for a package that |
43 |
exists, use the metadata.xml for that package. |
44 |
2. If the summary line contains a package atom for a package that does |
45 |
not exist, but a category that does exist, use the metadata.xml for |
46 |
that category. |
47 |
3. Process ALL atoms in the summary line, using any after the first for CC |
48 |
only. (new in v4) |
49 |
|
50 |
Step 2 - Metadata.xml contains only a herd |
51 |
------------------------------------------ |
52 |
1. Take the herd element, and look up the herd in herds.xml to convert |
53 |
to an email address. This email address must be a valid bugzilla |
54 |
account. |
55 |
2. This email is treated as an implicit maintainer element after this |
56 |
point. "<maintainer><email>${HERD_EMAIL}</email></maintainer>" |
57 |
[See notes] |
58 |
|
59 |
Step 3 - <maintainer> element |
60 |
----------------------------- |
61 |
1. Add the maintainer element to an ordered list, in the order they are |
62 |
present in the file. |
63 |
2. If an element appears more than once, the later element overrides the |
64 |
earlier element. (This provides a route when the herd is assigned, |
65 |
but does not wish to receive email for a specific package). |
66 |
3. If a maintainer element contains the non-default 'ignoreauto=1' |
67 |
attribute AND a non-empty role element (describing why this maintainer |
68 |
should not be contacted), delete it from the list. |
69 |
|
70 |
Step 4 - Assignment |
71 |
------------------- |
72 |
1. Use the first email in the ordered list as the assignee. |
73 |
2. Place all remaining emails in the CC list. |
74 |
3. Include a short comment about the processing results. |
75 |
|
76 |
Notes: |
77 |
------ |
78 |
1. For handling <herd>no-herd</herd>, we should add an entry into herds.xml to |
79 |
catch it (maintainer-needed <at> g.o). Every herd listed in an ebuild MUST be in |
80 |
herds.xml. |
81 |
2. Herds that do not wish to be contacted for specific bugs should add an |
82 |
maintainer element stating that (and use 'ignoreauto' on the element). |
83 |
This case however should be very rare, as the package probably doesn't |
84 |
belong in the herd if the herd doesn't care about it. |
85 |
3. If you want the default assignment to go to a maintainer, and NOT the herd, |
86 |
move the <herd> element further down in the metadata.xml! |
87 |
|
88 |
Effects on metadata.xml syntax |
89 |
============================== |
90 |
- Category metadata is now permitted to have herd and maintainer elements. |
91 |
- New attribute under maintainer, 'ignoreauto'. |
92 |
|
93 |
--- metadata.dtd 2007-11-20 10:07:33.000000000 -0800 |
94 |
+++ metadata.dtd.new 2008-10-18 23:22:55.000000000 -0700 |
95 |
@@ -1,7 +1,7 @@ |
96 |
<!ELEMENT packages ( pkgmetadata* )> |
97 |
|
98 |
<!-- Metadata for a category --> |
99 |
-<!ELEMENT catmetadata ( (longdescription)* )> |
100 |
+<!ELEMENT catmetadata ( (herd|maintainer|longdescription)* )> |
101 |
<!ATTLIST catmetadata pkgname CDATA ""> |
102 |
|
103 |
<!-- Metadata for a package --> |
104 |
@@ -13,6 +13,10 @@ |
105 |
|
106 |
<!-- One tag for each maintainer of a package, multiple allowed--> |
107 |
<!ELEMENT maintainer ( email, (description| name)* )> |
108 |
+ <!-- ignoreauto attribute specifies that a maintainer should not be used |
109 |
+ for automatic assignment computing. It must be combined with a |
110 |
+ non-empty description element. --> |
111 |
+ <!ATTLIST maintainer ignoreauto CDATA "0"> |
112 |
|
113 |
<!-- A long description of the package in freetext--> |
114 |
<!ELEMENT longdescription (#PCDATA|pkg)* > |
115 |
|
116 |
-- |
117 |
Robin Hugh Johnson |
118 |
Gentoo Linux Developer & Infra Guy |
119 |
E-Mail : robbat2@g.o |
120 |
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 |