| 1 |
In the spirit of finishing projects that I started long ago, and have |
| 2 |
been improving with age (hopefully we don't end up with any vinegar), I |
| 3 |
bring you yet another post about automatic bug assignment. |
| 4 |
|
| 5 |
Hopefully if this is accepted now, we can see about the integration needed when |
| 6 |
Bugzilla3 comes online. |
| 7 |
|
| 8 |
Previously: |
| 9 |
=========== |
| 10 |
http://thread.gmane.org/gmane.linux.gentoo.devel/48485 [v1] |
| 11 |
http://thread.gmane.org/gmane.linux.gentoo.devel/49601 [v2] |
| 12 |
http://thread.gmane.org/gmane.linux.gentoo.devel/57159 [v3] |
| 13 |
http://thread.gmane.org/gmane.linux.gentoo.devel/58575 [v4] |
| 14 |
http://thread.gmane.org/gmane.linux.gentoo.devel/59286 [v4a] |
| 15 |
|
| 16 |
Known prototypes: |
| 17 |
================= |
| 18 |
http://dev.gentoo.org/~rbu/assign.py |
| 19 |
- I believe this prototype is fully up to date, it just takes |
| 20 |
herds/metadata.xml as well as a string, and gives you the output the |
| 21 |
commandline. |
| 22 |
rbu: can you confirm that your prototype matches the proposal? |
| 23 |
|
| 24 |
How is it integrated into workflow? |
| 25 |
=================================== |
| 26 |
(This was raised by halcy0n at the v3 review, and replaces the previous section |
| 27 |
on triggering). |
| 28 |
1. Bugs are still filed as normal, with the same default assignees |
| 29 |
(bug-wranglers most commonly). |
| 30 |
2. In the wrangling process, we add a new button to the page, labelled: |
| 31 |
"Suggest assignment". |
| 32 |
3. Optionally, the wrangler edits the summary line right now, but does not hit |
| 33 |
'Submit' yet. |
| 34 |
4. The button causes a (javascript) query back to the server (also |
| 35 |
available as a web service for other usage). The only data sent is the |
| 36 |
'Summary' string. |
| 37 |
5. Javascript then appends the server results into the "Additional |
| 38 |
Comments" box: a suggested assignee and suggested CC values, with logic |
| 39 |
as to why. |
| 40 |
6. The wrangler can copy and paste the data into the fields, editing |
| 41 |
further as desired. |
| 42 |
|
| 43 |
(Putting the data into the comments allows the assignment tool to |
| 44 |
explain WHY it decided certain actions). |
| 45 |
|
| 46 |
Alternatively, the above can be accomplished with pybugz integration. |
| 47 |
|
| 48 |
Assignment/CC computing: |
| 49 |
======================== |
| 50 |
Step 1 - Summary line processing |
| 51 |
-------------------------------- |
| 52 |
1. If the summary line contains a package atom for a package that |
| 53 |
exists, use the metadata.xml for that package. |
| 54 |
2. If the summary line contains a package atom for a package that does |
| 55 |
not exist, but a category that does exist, use the metadata.xml for |
| 56 |
that category. |
| 57 |
3. Process ALL atoms in the summary line, using any after the first for CC |
| 58 |
only. (new in v4) |
| 59 |
|
| 60 |
Step 2 - Metadata.xml contains only a herd |
| 61 |
------------------------------------------ |
| 62 |
1. Take the herd element, and look up the herd in herds.xml to convert |
| 63 |
to an email address. This email address must be a valid bugzilla |
| 64 |
account. |
| 65 |
2. This email is treated as an implicit maintainer element after this |
| 66 |
point. "<maintainer><email>${HERD_EMAIL}</email></maintainer>" |
| 67 |
[See notes] |
| 68 |
|
| 69 |
Step 3 - <maintainer> element |
| 70 |
----------------------------- |
| 71 |
1. Add the maintainer element to an ordered list, in the order they are |
| 72 |
present in the file. |
| 73 |
2. If an element appears more than once, the later element overrides the |
| 74 |
earlier element. (This provides a route when the herd is assigned, |
| 75 |
but does not wish to receive email for a specific package). |
| 76 |
3. If a maintainer element contains the non-default 'ignoreauto=1' |
| 77 |
attribute AND a non-empty description element (describing why this |
| 78 |
maintainer should not be contacted), delete it from the list. |
| 79 |
|
| 80 |
Step 4 - Assignment |
| 81 |
------------------- |
| 82 |
1. Use the first email in the ordered list as the assignee. |
| 83 |
2. Place all remaining emails in the CC list. |
| 84 |
3. Include a short comment about the processing results. |
| 85 |
|
| 86 |
Notes: |
| 87 |
------ |
| 88 |
1. For handling <herd>no-herd</herd>, we should add an entry into herds.xml to |
| 89 |
catch it (maintainer-needed <at> g.o). Every herd listed in an ebuild MUST be in |
| 90 |
herds.xml. |
| 91 |
2. Herds that do not wish to be contacted for specific bugs should add an |
| 92 |
maintainer element stating that (and use 'ignoreauto' on the element). |
| 93 |
This case however should be very rare, as the package probably doesn't |
| 94 |
belong in the herd if the herd doesn't care about it. |
| 95 |
3. If "no-herd" is listed as a herd AND the metadata contains another herd or |
| 96 |
maintainer element, drop the "no-herd" entry from computation. |
| 97 |
4. If you want the default assignment to go to a maintainer, and NOT the herd, |
| 98 |
move the <herd> element further down in the metadata.xml! |
| 99 |
|
| 100 |
Differences to prior bug-wranglers policy |
| 101 |
========================================= |
| 102 |
(now included because every time I posted, somebody raised it. See [v4a]). |
| 103 |
- Bug wranglers (http://www.gentoo.org/proj/en/qa/bug-wranglers/) |
| 104 |
"When the file lists multiple entries, then you assign the bug to the first |
| 105 |
maintainer, and CC the other maintainer(s) and herd(s)." |
| 106 |
- The root problem with this is that various herds and maintainers want |
| 107 |
different behaviors on their bugs. |
| 108 |
1. Assign to herd, CC all others (eg: GNOME, base-system) |
| 109 |
2. Assign to first maintainer, CC herd and others (eg: net-mail) |
| 110 |
- Instead, the automatic policy would be summarized for the bug-wranglers |
| 111 |
policy as follows: |
| 112 |
"When the file lists multiple entries (either herds or maintainers), then you |
| 113 |
assign the bug to the first non-ignorable entry, and CC the other entries." |
| 114 |
- Using the order of herds and maintainers in the metadata.xml would be |
| 115 |
required even as a fallback to other optional XML attributes, and |
| 116 |
additionally makes sense when you just read the metadata. |
| 117 |
|
| 118 |
Effects on metadata.xml syntax |
| 119 |
============================== |
| 120 |
- Category metadata is now permitted to have herd and maintainer elements. |
| 121 |
- New attribute under maintainer, 'ignoreauto'. |
| 122 |
|
| 123 |
--- metadata.dtd 2007-11-20 10:07:33.000000000 -0800 |
| 124 |
+++ metadata.dtd.new 2008-10-18 23:22:55.000000000 -0700 |
| 125 |
@@ -1,7 +1,7 @@ |
| 126 |
<!ELEMENT packages ( pkgmetadata* )> |
| 127 |
|
| 128 |
<!-- Metadata for a category --> |
| 129 |
-<!ELEMENT catmetadata ( (longdescription)* )> |
| 130 |
+<!ELEMENT catmetadata ( (herd|maintainer|longdescription)* )> |
| 131 |
<!ATTLIST catmetadata pkgname CDATA ""> |
| 132 |
|
| 133 |
<!-- Metadata for a package --> |
| 134 |
@@ -13,6 +13,10 @@ |
| 135 |
|
| 136 |
<!-- One tag for each maintainer of a package, multiple allowed--> |
| 137 |
<!ELEMENT maintainer ( email, (description| name)* )> |
| 138 |
+ <!-- ignoreauto attribute specifies that a maintainer should not be used |
| 139 |
+ for automatic assignment computing. It must be combined with a |
| 140 |
+ non-empty description element. --> |
| 141 |
+ <!ATTLIST maintainer ignoreauto CDATA "0"> |
| 142 |
|
| 143 |
<!-- A long description of the package in freetext--> |
| 144 |
<!ELEMENT longdescription (#PCDATA|pkg)* > |
| 145 |
|
| 146 |
-- |
| 147 |
Robin Hugh Johnson |
| 148 |
Gentoo Linux: Developer, Trustee & Infrastructure Lead |
| 149 |
E-Mail : robbat2@g.o |
| 150 |
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 |
Archives