FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 07-01-2008, 06:07 AM
"Robin H. Johnson"
 
Default Planning for automatic assignment of bugs

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 (maintainer-needed@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 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 : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
 
Old 07-01-2008, 02:16 PM
Mark Loeser
 
Default Planning for automatic assignment of bugs

"Robin H. Johnson" <robbat2@gentoo.org> said:
> 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.

My main question to this entire proposal is do we actually want to give
bugs that possibly have no useful information to maintainers? No script
will be able to replace people looking at a bug and trying to get the
user to supply information that will be useful for the maintainer of a
package. The whole goal of the bug-wranglers project should be to
provide bugs to maintainers that they can actually do something with
when they receive them. (Yes yes, you can say that this doesn't happen
all the time today, and you would probably be right, but that doesn't
mean we can't fix that problem. A dedicated group of people that follow
guidelines that we set up for bug-wrangling should improve the quality
of bugs going to maintainers.) Also, does anyone know of any other open
source project that does automatic assignment like this? I'd be
interested to see how they implemented it and how it works for them.

Maybe no one else agrees with me, but I think auto-assignment might make
more work for people that don't want to deal with bugs that say:
"sys-devel/gcc is br0ken!!!" and provide nothing useful to help us
figure out the problem. Its a good idea, but since our users don't
always provide useful reports, it seems like we are just shifting work
around.

Just my 2 cents,

--
Mark Loeser
email - halcy0n AT gentoo DOT org
email - mark AT halcy0n DOT com
web - http://www.halcy0n.com
 
Old 07-01-2008, 03:29 PM
Jim Ramsay
 
Default Planning for automatic assignment of bugs

Mark Loeser <halcy0n@gentoo.org> wrote:
> Its a good idea, but since our users don't
> always provide useful reports, it seems like we are just shifting work
> around.

I'd suggest that this would /spread/ work around - Instead of a few
folks wrangling bugs, everyone would be doing it.

That said, I have no idea how many duplicate / incomplete bugs I have
never seen due to the wonderful work of the wranglers. In some ways it
would be a shame to lose that quality pre-reading of the bugs.

--
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm)
 
Old 07-02-2008, 12:30 AM
Duncan
 
Default Planning for automatic assignment of bugs

Jim Ramsay <lack@gentoo.org> posted 20080701112956.143dbd22@vrm378-02,
excerpted below, on Tue, 01 Jul 2008 11:29:56 -0400:

> Mark Loeser <halcy0n@gentoo.org> wrote:
>> Its a good idea, but since our users don't always provide useful
>> reports, it seems like we are just shifting work around.
>
> I'd suggest that this would /spread/ work around - Instead of a few
> folks wrangling bugs, everyone would be doing it.
>
> That said, I have no idea how many duplicate / incomplete bugs I have
> never seen due to the wonderful work of the wranglers. In some ways it
> would be a shame to lose that quality pre-reading of the bugs.

Perhaps the best solution is to get the implementation in place, but not
completely automate it. Put the tools there so if it looks right, all
the wrangler needs to do is a single click, and it's auto-assigned, but
that single click is still necessary so that a human actually gets to
review things before doing the assignment.

That would make it /much/ easier for the wranglers.

If desired, a cron script or some such could then be setup to go thru and
automatically assign anything that wasn't assigned yet and that hadn't
been touched (no comments asking for more info, etc) for some period, say
a week, just to catch anything that fell thru the cracks or if the
wranglers all disappeared or went on strike/vacation/whatever. Then if
folks ever suddenly find themselves inundated with "raw" bugs, it'd be a
serious indication that the wranglers needed some help.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

--
gentoo-dev@lists.gentoo.org mailing list
 
Old 07-03-2008, 02:17 AM
Ryan Hill
 
Default Planning for automatic assignment of bugs

On Mon, 30 Jun 2008 23:07:03 -0700
"Robin H. Johnson" <robbat2@gentoo.org> wrote:

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

I wonder how often this will do the right thing. Not to mention many
categories don't have a team (eg. app-doc) and many have multiple teams
(eg. media-libs). In fact, I don't see anyone using category-level
metadata.xml for anything but category descriptions right now.
Assigning bugs that don't have a valid package name to bug-wranglers
for some human intervention might work better.


--
gcc-porting, by design, by neglect
treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
 

Thread Tools




All times are GMT. The time now is 05:15 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org