Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs

[Alec Warner]

On Sat, Oct 18, 2008 at 11:01 PM, Robin H. Johnson <robbat2@g.o> wrote:
> Now into it's Nth great year, I bring you the fourth edition of the
> automatic assignment proposal. </truman-show>
>
> Previously:
> http://thread.gmane.org/gmane.linux.gentoo.devel/48485 [v1]
> http://thread.gmane.org/gmane.linux.gentoo.devel/49601 [v2]
> http://thread.gmane.org/gmane.linux.gentoo.devel/57159 [v3]
>
> Bleeding edge prototype:
> http://dev.gentoo.org/~rbu/assign.py
> MANY thanks to rbu.
>
> If there are no further changes or objections at this time, it would be
> nice to implement this by the end of November.
>
> How is it integrated into workflow?
> ===================================
> (This was raised by halcy0n at the v3 review, and replaces the previous section
> on triggering).
> 1. Bugs are still filed as normal, with the same default assignees
>   (bug-wranglers most commonly).
> 2. In the wrangling process, we add a new button to the page, labelled:
>   "Suggest assignment".
> 3. Optionally, the wrangler edits the summary line right now, but does not hit
>   'Submit' yet.
> 4. The button causes a (javascript) query back to the server (also
>   available as a web service for other usage). The only data sent is the
>   'Summary' string.
> 5. Javascript then appends the server results into the "Additional
>   Comments" box: a suggested assignee and suggested CC values, with logic
>   as to why.
> 6. The wrangler can copy and paste the data into the fields, editing
>   further as desired.
>
> (Putting the data into the comments allows the assignment tool to
> explain WHY it decided certain actions).
>
> Assignment/CC computing:
> ========================
> Step 1 - Summary line processing
> --------------------------------
> 1. If the summary line contains a package atom for a package that
>   exists, use the metadata.xml for that package.
> 2. If the summary line contains a package atom for a package that does
>   not exist, but a category that does exist, use the metadata.xml for
>   that category.
> 3. Process ALL atoms in the summary line, using any after the first for CC
>   only. (new in v4)
>
> Step 2 - Metadata.xml contains only a herd
> ------------------------------------------
> 1. Take the herd element, and look up the herd in herds.xml to convert
>   to an email address. This email address must be a valid bugzilla
>   account.

What if my herd email address is different from my bugzie address?
Can I have both in herds.xml?  What if my herd address *isn't* a
bugzie account, will the world end?  How can we automatically detect
when developers make mistakes in editing herds.xml?

> 2. This email is treated as an implicit maintainer element after this
>   point. "<maintainer><email>${HERD_EMAIL}</email></maintainer>"
> [See notes]
>
> Step 3 - <maintainer> element
> -----------------------------
> 1. Add the maintainer element to an ordered list, in the order they are
>   present in the file.
> 2. If an element appears more than once, the later element overrides the
>   earlier element. (This provides a route when the herd is assigned,
>   but does not wish to receive email for a specific package).
> 3. If a maintainer element contains the non-default 'ignoreauto=1'
>   attribute AND a non-empty role element (describing why this maintainer
>   should not be contacted), delete it from the list.
>
> Step 4 - Assignment
> -------------------
> 1. Use the first email in the ordered list as the assignee.
> 2. Place all remaining emails in the CC list.
> 3. Include a short comment about the processing results.
>
> Notes:
> ------
> 1. For handling <herd>no-herd</herd>, we should add an entry into herds.xml to
>   catch it (maintainer-needed <at> g.o). Every herd listed in an ebuild MUST be in
>   herds.xml.

You and I both know this is not going to be true.  Complicated
solution; make Repoman do it.  Certainly it is the 'correct' thing to
do; however I don't expect it to get implemented or deployed quickly.
Hacky solution: run script on osprey that tries to validate tree
metadata against herds.xml and annoy herds who forgot to add
themselves.

> 2. Herds that do not wish to be contacted for specific bugs should add an
>   maintainer element stating that (and use 'ignoreauto' on the element).
>   This case however should be very rare, as the package probably doesn't
>   belong in the herd if the herd doesn't care about it.
> 3. If you want the default assignment to go to a maintainer, and NOT the herd,
>   move the <herd> element further down in the metadata.xml!
>
> Effects on metadata.xml syntax
> ==============================
> - Category metadata is now permitted to have herd and maintainer elements.
> - New attribute under maintainer, 'ignoreauto'.
>
> --- metadata.dtd        2007-11-20 10:07:33.000000000 -0800
> +++ metadata.dtd.new    2008-10-18 23:22:55.000000000 -0700
> @@ -1,7 +1,7 @@
>  <!ELEMENT packages ( pkgmetadata* )>
>
>  <!-- Metadata for a category -->
> -<!ELEMENT catmetadata ( (longdescription)* )>
> +<!ELEMENT catmetadata ( (herd|maintainer|longdescription)* )>
>  <!ATTLIST catmetadata pkgname CDATA "">
>
>  <!-- Metadata for a package -->
> @@ -13,6 +13,10 @@
>
>   <!-- One tag for each maintainer of a package, multiple allowed-->
>   <!ELEMENT maintainer ( email, (description| name)* )>
> +         <!-- ignoreauto attribute specifies that a maintainer should not be used
> +                  for automatic assignment computing. It must be combined with a
> +                  non-empty description element. -->
> +      <!ATTLIST maintainer ignoreauto CDATA "0">
>
>   <!-- A long description of the package in freetext-->
>   <!ELEMENT longdescription (#PCDATA|pkg)* >
>
> --
> Robin Hugh Johnson
> Gentoo Linux Developer & Infra Guy
> E-Mail     : robbat2@g.o
> GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
>