public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Robin H. Johnson" <robbat2@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs
Date: Sat, 18 Oct 2008 23:01:14 -0700	[thread overview]
Message-ID: <20081019060114.GA21785@curie-int.orbis-terrarum.net> (raw)

[-- Attachment #1: Type: text/plain, Size: 5080 bytes --]

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.
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.
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@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 329 bytes --]

             reply	other threads:[~2008-10-19  6:25 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-19  6:01 Robin H. Johnson [this message]
2008-10-19 13:29 ` [gentoo-dev] [v4] Planning for automatic assignment computation of bugs Robert Buchholz
2008-10-19 19:13   ` Robin H. Johnson
2008-10-19 13:47 ` Jeremy Olexa
2008-10-19 19:16   ` Robin H. Johnson
2008-10-19 13:49 ` Ulrich Mueller
2008-10-19 19:43   ` Robin H. Johnson
2008-10-19 19:51     ` Robin H. Johnson
2008-10-19 19:32 ` Alec Warner
2008-10-19 19:47   ` Robin H. Johnson
2008-11-13 20:22     ` Thilo Bangert
2008-11-13  6:04 ` Donnie Berkholz
2009-01-04 16:52 ` Robert Buchholz
2009-01-04 17:02   ` Mike Auty
2009-01-04 17:06     ` Jeroen Roovers
2009-01-04 17:15       ` Mike Auty
2009-01-04 17:57         ` Robert Buchholz
2009-01-04 18:12           ` Mike Auty
2009-01-06 12:54             ` Robin H. Johnson
2009-01-06 14:19               ` Mike Auty
2009-01-06 10:11           ` Peter Volkov
2009-01-07  7:53             ` [gentoo-dev] " Steve Long
2009-01-07  6:01       ` [gentoo-dev] " Tiziano Müller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081019060114.GA21785@curie-int.orbis-terrarum.net \
    --to=robbat2@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox