On Sat, Oct 18, 2008 at 11:01 PM, Robin H. Johnson <[EMAIL PROTECTED]> 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 : [EMAIL PROTECTED]
> GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
>
