From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-dev+bounces-33212-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1Kre19-0005hE-LN
for garchives@archives.gentoo.org; Sun, 19 Oct 2008 19:32:48 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id E6032E0292;
Sun, 19 Oct 2008 19:32:45 +0000 (UTC)
Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.191])
by pigeon.gentoo.org (Postfix) with ESMTP id B3086E0290
for <gentoo-dev@lists.gentoo.org>; Sun, 19 Oct 2008 19:32:45 +0000 (UTC)
Received: by rn-out-0910.google.com with SMTP id m36so712630rnd.14
for <gentoo-dev@lists.gentoo.org>; Sun, 19 Oct 2008 12:32:44 -0700 (PDT)
Received: by 10.100.95.15 with SMTP id s15mr7676271anb.20.1224444764330;
Sun, 19 Oct 2008 12:32:44 -0700 (PDT)
Received: by 10.100.94.12 with HTTP; Sun, 19 Oct 2008 12:32:44 -0700 (PDT)
Message-ID: <b41005390810191232j7ac94dafs46fd96b0da9fff92@mail.gmail.com>
Date: Sun, 19 Oct 2008 12:32:44 -0700
From: "Alec Warner" <antarus@gentoo.org>
Sender: antarus@scriptkitty.com
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs
In-Reply-To: <20081019060114.GA21785@curie-int.orbis-terrarum.net>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20081019060114.GA21785@curie-int.orbis-terrarum.net>
X-Google-Sender-Auth: 76cb06d3c38d70d1
X-Archives-Salt: abd372ee-7586-4f14-b8a5-9d0bf99aefa8
X-Archives-Hash: 08527f9c84e346477b9f5248862f5692
On Sat, Oct 18, 2008 at 11:01 PM, Robin H. Johnson <robbat2@gentoo.org> wrote:
> 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.
What if my herd email address is different from my bugzie address?
Can I have both in herds.xml? What if my herd address *isn't* a
bugzie account, will the world end? How can we automatically detect
when developers make mistakes in editing herds.xml?
> 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.
You and I both know this is not going to be true. Complicated
solution; make Repoman do it. Certainly it is the 'correct' thing to
do; however I don't expect it to get implemented or deployed quickly.
Hacky solution: run script on osprey that tries to validate tree
metadata against herds.xml and annoy herds who forgot to add
themselves.
> 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
>