So this is now the third revision of this proposal. The first two editions are available here. http://thread.gmane.org/gmane.linux.gentoo.devel/48485 http://thread.gmane.org/gmane.linux.gentoo.devel/49601
Comments are welcome, as are offers to implement it.
Implementations should be a small python or perl script that take a
single CP atom an resolve it to an assignee, along with one or more CC
entries. They may assume that an rsync tree exists at $PORTDIR (not
/usr/portage, but $PORTDIR). Additional data files are welcome as well
for special assignment rules.
This is mostly the same as the v2 proposal, with just further changes
from bangert.
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 (this may be a
new or misspelt package), try to figure out which team might want it. Use
the category-level metadata.xml file.
5. A developer may also enter an atom manually on the text input field
for doing a re-assignment.
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>"
[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 reassignment processing results.
Notes:
------
1. For handling <herd>no-herd</herd>, we should add an entry into herds.xml to
catch it ([EMAIL PROTECTED]). 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!
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : [EMAIL PROTECTED]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpnB3DRjshae.pgp
Description: PGP signature
