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 : [EMAIL PROTECTED]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgphKmphuF3VY.pgp
Description: PGP signature
