[gentoo-dev] [v2] Planning for automatic assignment of bugs

[Robin H. Johnson]

Hi folks, 

This got sidetracked originally, and I got busy.

I've greatly revised this to take into account the various feedback on
both the original thread as well as the later 'Irregular Metadata Check'
thread by bangert. 

I sided with bangert's arguments after thinking about the processing.
This means in a couple of cases that folks will receive duplicate emails
where they don't want them, until they edit the metadata, but no bugs
will be lost because the email went to the wrong person.

Comments etc welcome.

Assignment process, triggering:
====================================================
Auto-assignment will be be applied/available in the following cases:
1. New bugs created with the guided process, having a Product equal to
   'Gentoo Linux' and a component not equal to 'Eclasses and Profiles'.
2. Open bugs will have a new action available: 'Reassign by metadata',
   with a text input field. The text field will be auto-filled with a
   package atom $CAT/$PN by parsing the summary line. Using the action
   will provide the package atom to the next stage.
3. If multiple package atoms are present in a summary line, the first
   one wins.
4. If we have a valid category name, but no valid package atoms, try to
   figure out which team might want it. Use the category-level
   metadata.xml file.

Assignment process:
====================================================

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. Stop after the first
   atom.
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.

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>"

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 '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 comment about the reassignment processing.

Notes/Changes from before:
====================================================
- The herd element is always used.
- The 'contact' attribute is now called 'ignoreauto'.
- The 'ignoreauto' is the logical opposite of the original 'contact'
  attribute.
- The 'ignoreauto' attribute defaults to false.
- Any usage of the 'ignoreauto' attribute requires the role element to
  be present.
- Herds that do not wish to be contacted for specific bugs should add a
  maintainer element stating that (and use 'ignoreauto' on the element).
- Category level metadata.xml is now used for fallback if this is a bug
  about a new package in an existing category.
- Category level metadata.xml may contain herd and maintainer elements.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Council Member
E-Mail     : robbat2@g.o
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85