From: "Robin H. Johnson" <robbat2@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] [v5] Planning for automatic assignment computation of bugs
Date: Mon, 3 May 2010 21:49:57 +0000 [thread overview]
Message-ID: <20100503214957.GA30113@orbis-terrarum.net> (raw)
[-- Attachment #1: Type: text/plain, Size: 6811 bytes --]
In the spirit of finishing projects that I started long ago, and have
been improving with age (hopefully we don't end up with any vinegar), I
bring you yet another post about automatic bug assignment.
Hopefully if this is accepted now, we can see about the integration needed when
Bugzilla3 comes online.
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]
http://thread.gmane.org/gmane.linux.gentoo.devel/58575 [v4]
http://thread.gmane.org/gmane.linux.gentoo.devel/59286 [v4a]
Known prototypes:
=================
http://dev.gentoo.org/~rbu/assign.py
- I believe this prototype is fully up to date, it just takes
herds/metadata.xml as well as a string, and gives you the output the
commandline.
rbu: can you confirm that your prototype matches the proposal?
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).
Alternatively, the above can be accomplished with pybugz integration.
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 description 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 "no-herd" is listed as a herd AND the metadata contains another herd or
maintainer element, drop the "no-herd" entry from computation.
4. 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!
Differences to prior bug-wranglers policy
=========================================
(now included because every time I posted, somebody raised it. See [v4a]).
- Bug wranglers (http://www.gentoo.org/proj/en/qa/bug-wranglers/)
"When the file lists multiple entries, then you assign the bug to the first
maintainer, and CC the other maintainer(s) and herd(s)."
- The root problem with this is that various herds and maintainers want
different behaviors on their bugs.
1. Assign to herd, CC all others (eg: GNOME, base-system)
2. Assign to first maintainer, CC herd and others (eg: net-mail)
- Instead, the automatic policy would be summarized for the bug-wranglers
policy as follows:
"When the file lists multiple entries (either herds or maintainers), then you
assign the bug to the first non-ignorable entry, and CC the other entries."
- Using the order of herds and maintainers in the metadata.xml would be
required even as a fallback to other optional XML attributes, and
additionally makes sense when you just read the metadata.
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, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]
next reply other threads:[~2010-05-03 21:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-03 21:49 Robin H. Johnson [this message]
2010-05-06 2:06 ` [gentoo-dev] [v5] Planning for automatic assignment computation of bugs Sebastian Pipping
2010-05-06 4:27 ` Robin H. Johnson
2010-05-07 17:06 ` Sebastian Pipping
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=20100503214957.GA30113@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