[gentoo-dev] Automatic Bug Assignment

[gentoo-dev] Automatic Bug Assignment

[Alex Brandt]

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]

Hey Guys,

I've oft wondered why we don't automatically assign bugs to the 
ebuild maintainer (if a CPV is in the subject).  Would there be an 
issue with adding a bug modification hook to bugzilla or a daily 
job to re-assign bugs to ebuild owners (if a CPV is in the 
subject)?

Just curious not trying to incite anything.

Regards,

-- 
Alex Brandt
Software Developer for Rackspace and Developer for Gentoo
http://blog.alunduil.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Automatic Bug Assignment

[Kent Fredric]

On 31 January 2016 at 06:45, Alex Brandt <alunduil@gentoo.org> wrote:
> Would there be an
> issue with adding a bug modification hook to bugzilla or a daily
> job to re-assign bugs to ebuild owners (if a CPV is in the
> subject)?


I would argue the reason this probably isn't already in place might be
related to how users can't assign bugs themselves manually either.

It typically requires the skills and understanding a bug wrangler has
to identify that the bugs data is sufficient to actually have a clear
understanding of who is actually responsible.

Prematurely assigning bugs to ebuild owners based on the CPV in the
subject thus risks bothering developers of projects that are unrelated
to the problem because the person who reported the issue didn't
understand what they were reporting.

And so bug wranglers stand in between making sure that in the event a
bug is reported with so low quality that the natural assignee could
never solve it, that the natural assignee is not assigned until the
bug is at least good enough to confirm the responsibility is
warranted.


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Automatic Bug Assignment

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]

On Sat, Jan 30, 2016 at 9:45 AM, Alex Brandt <alunduil@gentoo.org> wrote:

> Hey Guys,
>
> I've oft wondered why we don't automatically assign bugs to the
> ebuild maintainer (if a CPV is in the subject).  Would there be an
> issue with adding a bug modification hook to bugzilla or a daily
> job to re-assign bugs to ebuild owners (if a CPV is in the
> subject)?
>

There was previously a fair amount of bikeshedding, both in how to parse
the CPV, and who to assign the bug to.

Its not always the maintainer, sometimes the maintainer is a project and
not an individual; prior to de-herdification there was not always a clear
mapping from herd => bugzie account for assignment, etc..

I find that often in schemes like this people get caught up designing the
optimal / perfect solution (which is often tricky) as opposed to using a
nice solution that works 95% of the time; but 5% of the time is wrong.

-A


>
> Just curious not trying to incite anything.
>
> Regards,
>
> --
> Alex Brandt
> Software Developer for Rackspace and Developer for Gentoo
> http://blog.alunduil.com
>

[-- Attachment #2: Type: text/html, Size: 1792 bytes --]

Re: [gentoo-dev] Automatic Bug Assignment

[Rich Freeman]

On Fri, Feb 5, 2016 at 12:41 PM, Alec Warner <antarus@gentoo.org> wrote:
>
> I find that often in schemes like this people get caught up designing the
> optimal / perfect solution (which is often tricky) as opposed to using a
> nice solution that works 95% of the time; but 5% of the time is wrong.
>

++

I'd be all for automated bug assignment.  Usually when this comes up a
bunch of hero bug wranglers step up and say it isn't needed, because
we have hero bug wranglers.  As long as people keep stepping up to do
that I'm not going to tell them that they can't.  However, if the bug
queue ever does go out of control I'd be all for just auto-assigning
them.  If they rarely get assigned to the wrong people, then they can
just reassign them.  And nothing stops us from having a bugzilla query
for "new bugs filed in last 24h" for people who want to take a quick
look at recent bugs for trends or to help clean them up across
projects.

-- 
Rich

Re: [gentoo-dev] Automatic Bug Assignment

[Kent Fredric]

On 6 February 2016 at 07:19, Rich Freeman <rich0@gentoo.org> wrote:
> 'd be all for automated bug assignment.  Usually when this comes up a
> bunch of hero bug wranglers step up and say it isn't needed, because
> we have hero bug wranglers.  As long as people keep stepping up to do
> that I'm not going to tell them that they can't.  However, if the bug
> queue ever does go out of control I'd be all for just auto-assigning
> them.  If they rarely get assigned to the wrong people, then they can
> just reassign them.  And nothing stops us from having a bugzilla query
> for "new bugs filed in last 24h" for people who want to take a quick
> look at recent bugs for trends or to help clean them up across
> projects.


Hm, or alternatively, you could have a scheme where things defaulted
in the bug queue, and were auto-assigned where possible after no
feedback for a time, or maybe it would be defaulted only when the
queue is over a certain size.

At least that way the hero's can provide as much quality as they like,
and if they get tired and stop triaging bugs, a sensible fallback
that's not perfect can fill the gaps.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Automatic Bug Assignment

[Rich Freeman]

On Fri, Feb 5, 2016 at 1:27 PM, Kent Fredric <kentfredric@gmail.com> wrote:
> On 6 February 2016 at 07:19, Rich Freeman <rich0@gentoo.org> wrote:
>> 'd be all for automated bug assignment.  Usually when this comes up a
>> bunch of hero bug wranglers step up and say it isn't needed, because
>> we have hero bug wranglers.  As long as people keep stepping up to do
>> that I'm not going to tell them that they can't.  However, if the bug
>> queue ever does go out of control I'd be all for just auto-assigning
>> them.  If they rarely get assigned to the wrong people, then they can
>> just reassign them.  And nothing stops us from having a bugzilla query
>> for "new bugs filed in last 24h" for people who want to take a quick
>> look at recent bugs for trends or to help clean them up across
>> projects.
>
>
> Hm, or alternatively, you could have a scheme where things defaulted
> in the bug queue, and were auto-assigned where possible after no
> feedback for a time, or maybe it would be defaulted only when the
> queue is over a certain size.
>

That was my thought around having a query for bugs filed in the last
24h.  Basically they'd be auto-assigned, but people could choose to
review recent bugs to see if any were mis-assigned, and no action is
necessary if they're OK.

The main problem I see with auto-assignment is that some asignees end
up being black holes for bugs.  If two active devs get their bugs
crossed it isn't a big deal since they'll just reassign them to each
other.  If an active dev gets their bug assigned to an inactive dev,
they might never hear about it.

-- 
Rich

Re: [gentoo-dev] Automatic Bug Assignment

[Kent Fredric]

On 6 February 2016 at 09:47, Rich Freeman <rich0@gentoo.org> wrote:
> That was my thought around having a query for bugs filed in the last
> 24h.  Basically they'd be auto-assigned, but people could choose to
> review recent bugs to see if any were mis-assigned, and no action is
> necessary if they're OK.


The idea with /delayed/ auto-assignment was to give humans opportunity
to see and triage the bug /before/ auto-assignment took place.

Specifically to give an incentive to prevent potential assignment blackholes =).

And the "no interaction" grace period was so that if a bug-wrangler
saw a bug report and saw that it was too poorly detailed to classify
it _at all_, the interaction would prohibit subsequent
auto-assignment.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Automatic Bug Assignment

[Michael Orlitzky]

On 02/05/2016 03:47 PM, Rich Freeman wrote:
> The main problem I see with auto-assignment is that some asignees end
> up being black holes for bugs.  If two active devs get their bugs
> crossed it isn't a big deal since they'll just reassign them to each
> other.  If an active dev gets their bug assigned to an inactive dev,
> they might never hear about it.
> 

We already trust users to tell us what went wrong and put bugs in the
right component. I think we can trust the package atom if one exists in
the summary. How about, if there's (exactly) one portage-compatible atom
in the summary and that package has (exactly) one maintainer, we
auto-assign it? Otherwise, leave it to the bug wranglers.

That's easy and won't create any problems we don't already have.

Re: [gentoo-dev] Automatic Bug Assignment

[Kent Fredric]

On 6 February 2016 at 10:10, Michael Orlitzky <mjo@gentoo.org> wrote:
> How about, if there's (exactly) one portage-compatible atom
> in the summary and that package has (exactly) one maintainer, we
> auto-assign it? Otherwise, leave it to the bug wranglers.


One of my conceptual misgivings is in practice, there's a lot more to
bug wrangling than that.

In the last 6 months, here are a list of bugs that were never
reassigned from bugwranglers, and were closed due to being invalid,
incomplete, or duplicate.

All of these bugs would be now assigned to the individual bug maintainers.

And I see that as a sizeable quality regression.

https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&chfieldfrom=6m&chfieldto=Now&email1=bug-wranglers%40gentoo.org&emailassigned_to1=1&emailtype1=substring&f0=OP&f1=OP&f3=CP&f4=CP&list_id=3059742&query_format=advanced&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&resolution=CANTFIX&resolution=NEEDINFO



-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Automatic Bug Assignment

[Michael Orlitzky]

On 02/05/2016 04:34 PM, Kent Fredric wrote:
> On 6 February 2016 at 10:10, Michael Orlitzky <mjo@gentoo.org> wrote:
>> How about, if there's (exactly) one portage-compatible atom
>> in the summary and that package has (exactly) one maintainer, we
>> auto-assign it? Otherwise, leave it to the bug wranglers.
> 
> 
> One of my conceptual misgivings is in practice, there's a lot more to
> bug wrangling than that.
> 
> In the last 6 months, here are a list of bugs that were never
> reassigned from bugwranglers, and were closed due to being invalid,
> incomplete, or duplicate.
> 
> All of these bugs would be now assigned to the individual bug maintainers.
> 
> And I see that as a sizeable quality regression.
> 

Some of those were closed WORKSFORME when maybe the maintainer would
have recognized the problem that the user is seeing (auto-assign would
be an *improvement*). Others were closed by the user when he realized
his error (no regression there). Then there are the ones that were
closed by the maintainer/project, but never reassigned. No regression
there either.

There are also some that would have wound up assigned to the wrong
person, like 573846. But your list isn't a long list of regressions --
many would be an improvement or no change.

You also have to take into consideration how many of them have a valid
package atom in the summary, and how many of those would have exactly
one maintainer. That's a very-sub subset of the full list.

Re: [gentoo-dev] Automatic Bug Assignment

[Kent Fredric]

On 6 February 2016 at 11:19, Michael Orlitzky <mjo@gentoo.org> wrote:
>
> You also have to take into consideration how many of them have a valid
> package atom in the summary, and how many of those would have exactly
> one maintainer. That's a very-sub subset of the full list.


Yeah. Now that I've gotten most of my objections out of the way, I'm
going to assume the approach will be a maintainer bot of some kind,
not a native hook in bugzilla itself.

Like I would very much like it if it were possible for the bugzilla UI
to have a bit of JavaScript that runs as an optional helper that:

- Parses your subject string
- Warns you if your subject string lacks a recognizable cat/pkg
- Shows the recognised cat/pkg if one is present
- When a match is present, shows the suggested maintainer list and bug
category values and allows you to go "Yep, that's what I wanted".

Because assuming the access to the metadata about packages could be
deemed fresh enough, that would also improve the bugzilla workflow for
developers who know what they're doing, not just novices who don't
know how to assign bugs.

But I'm guessing that's a bit outside the scope of what can be done
with bugzilla.


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Automatic Bug Assignment

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]

On Fri, 5 Feb 2016 16:10:48 -0500 Michael Orlitzky wrote:
> On 02/05/2016 03:47 PM, Rich Freeman wrote:
> > The main problem I see with auto-assignment is that some asignees end
> > up being black holes for bugs.  If two active devs get their bugs
> > crossed it isn't a big deal since they'll just reassign them to each
> > other.  If an active dev gets their bug assigned to an inactive dev,
> > they might never hear about it.
> > 
> 
> We already trust users to tell us what went wrong and put bugs in the
> right component. I think we can trust the package atom if one exists in
> the summary. How about, if there's (exactly) one portage-compatible atom
> in the summary and that package has (exactly) one maintainer, we
> auto-assign it? Otherwise, leave it to the bug wranglers.

Automation can go further: if there are multiple maintainers,
assign bug to the first one and CC others.

As long as a package have a valid CP, maintainers will see them via
a simple bugzilla query. Afaik this is a good idea to loop through
all open package bugs before stabilization or version bump.

Most (all?) bug wranglers are devs, so their time can be spent for
better use, e.g. fixing actual bugs. Anyway bug wranglers will
still have job: many bug reports doesn't contain a valid CP.

The only concern I have with this: sometimes bug title reference
multiple packages and it is possible that it will contain one valid
CP and another one will be incomplete/invalid, e.g. "mplayer fails
to build with dev-libs/openssl". In this case bug may be improperly
auto assigned. But such cases should be quite rare thus tolerable.

Another note: atom validity check should be performed for CP, not
CPV, since many bugs affect all versions of a package in the tree, I
often file such bugs myself :)

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Automatic Bug Assignment

[Toralf Förster]

On 02/06/2016 10:35 AM, Andrew Savchenko wrote:
> Automation can go further: if there are multiple maintainers,
> assign bug to the first one and CC others.
Which is exactly what I'm doing in my tinderbox:


  # get assignee and cc, GLEP 67 simplifies it
  #
  m=$(equery --no-color meta -m $curr 2>/dev/null | grep '@' | xargs)
  if [[ -z "$m" ]]; then
    m="maintainer-needed@gentoo.org"
  fi
  echo "$m" | cut -f1  -d ' '               > $issuedir/assignee

  echo "$m" | grep -q ' '
  if [[ $? -eq 0 ]]; then
    echo "$m" | cut -f2- -d ' ' | tr ' ' ','  > $issuedir/cc
  else
    echo "" > $issuedir/cc
  fi


:-D

-- 
Toralf
PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7

Re: [gentoo-dev] Automatic Bug Assignment

[NP-Hardass]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/05/2016 03:47 PM, Rich Freeman wrote:
> On Fri, Feb 5, 2016 at 1:27 PM, Kent Fredric
> <kentfredric@gmail.com> wrote:
>> On 6 February 2016 at 07:19, Rich Freeman <rich0@gentoo.org>
>> wrote:
>>> 'd be all for automated bug assignment.  Usually when this
>>> comes up a bunch of hero bug wranglers step up and say it isn't
>>> needed, because we have hero bug wranglers.  As long as people
>>> keep stepping up to do that I'm not going to tell them that
>>> they can't.  However, if the bug queue ever does go out of
>>> control I'd be all for just auto-assigning them.  If they
>>> rarely get assigned to the wrong people, then they can just
>>> reassign them.  And nothing stops us from having a bugzilla
>>> query for "new bugs filed in last 24h" for people who want to
>>> take a quick look at recent bugs for trends or to help clean
>>> them up across projects.
>> 
>> 
>> Hm, or alternatively, you could have a scheme where things
>> defaulted in the bug queue, and were auto-assigned where possible
>> after no feedback for a time, or maybe it would be defaulted only
>> when the queue is over a certain size.
>> 
> 
> That was my thought around having a query for bugs filed in the
> last 24h.  Basically they'd be auto-assigned, but people could
> choose to review recent bugs to see if any were mis-assigned, and
> no action is necessary if they're OK.
> 
> The main problem I see with auto-assignment is that some asignees
> end up being black holes for bugs.  If two active devs get their
> bugs crossed it isn't a big deal since they'll just reassign them
> to each other.  If an active dev gets their bug assigned to an
> inactive dev, they might never hear about it.
> 

As an alternative to bug assignment, which does carry the risk of
"black holes," what about automatic bug CC'ing?  That gives the likely
party the heads up, and if they don't take it, wranglers take over and
determine what to do with it.  This gives us some degree of automation
(automatic notification, but not sorting), and leaves in the space for
the wranglers, who I believe are important to getting things where
they need to be effectively.

- -- 
NP-Hardass
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWtb6SAAoJEBzZQR2yrxj7n6IQAIcEmhkIUUie4u6DsodgCRSc
qnP5cqR9C/0EyXZwQwbntX6Zh18MoFS9/VqQt9kHwFiuqsJaNoxZVMaofM58dwq+
BZN5kq4qVO3TI9gp3D4Y4PlzjnYvOg7eiEPRyHy02ZTvJ/Hjhq4wC2VhIKoTF3EF
L5NKqWebwOre62xCHWeCM0EJGrTj/j/ggSrTjMMrpF/iRJM880IA4j+Nqr3CwLkB
jH7uM2b2fgjDiyztwKdk90yspax/CBBG0F/XGyuj2bO4BaCCHFD8xDj8lLALkneJ
D/ihRjNMkgHW6gHRXhrUfABPFEGULadpXKFt/G7RWi0hcn5fjuoRpaoA8k0z/8wl
YxhQFPdTtfgiQhiL2q5wogSzwXbiliWQDeonBnboC+CKqxByEumOYi05jXgGbBx7
mPUcdjKmePbbM4SW/WPbr57HTdMZ2G70EFlg5UNGNN4phvX7T2tz3fiCRLqiO1nm
UTbykpwACnVTcWmNFgWD11xg4oISr8kxcoql86bwFJdT3fVGedLNwOE3f6YRryZC
mxt/PbqVHiVuFsZTgLHC/NdV52DD9QQhBDaBxZnQKazPDaqVbNyM6fbwf54xDRbZ
fO+ZrKix2n+n+aE8bUBmJQ66v8+upBKOSzIu741bW4eKAYdF8+9iJKRVKEhT6Mx2
efg+xYoIkEtrJTKTdKNG
=iylA
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Automatic Bug Assignment

[Kent Fredric]

On 6 February 2016 at 06:41, Alec Warner <antarus@gentoo.org> wrote:
> ; but 5% of the time is wrong.

Just here, in the "5% are wrong" case, instead of the problem being
resolved by bug wranglers, ... the problem has to be resolved by
whoever got assigned.

And they might not even be around in the next 2-3 weeks.

Which means while it may make an improvement of 5% for the 90-95% of
cases, the detriment might be 50% worse for the residual 5-10%.

Is that a fair compromise? Can't say.

Its the sort of thing I'd have to see in practice in a limited
capacity with a promise that we can just get rid of it if it turns out
to be more trouble than its worth.


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Automatic Bug Assignment

[Patrick Lauer]

On 01/30/2016 06:45 PM, Alex Brandt wrote:
> Hey Guys,
>
> I've oft wondered why we don't automatically assign bugs to the 
> ebuild maintainer (if a CPV is in the subject).  Would there be an 
> issue with adding a bug modification hook to bugzilla or a daily 
> job to re-assign bugs to ebuild owners (if a CPV is in the 
> subject)?
>
> Just curious not trying to incite anything.
>
> Regards,
>
Maybe we could add a "Assign to maintainer(s)" button visible only to
certain groups of users, so that a bugwrangler who decides this bug is
valid just has to hit one button instead of figuring out the details of
assignment?

There seems to be valid criticism about fully automating the workflow,
but partial automation can still save huge amounts of time ...

[gentoo-dev] Re: Automatic Bug Assignment

[Duncan]

Patrick Lauer posted on Sat, 06 Feb 2016 09:09:13 +0100 as excerpted:

> Maybe we could add a "Assign to maintainer(s)" button visible only to
> certain groups of users, so that a bugwrangler who decides this bug is
> valid just has to hit one button instead of figuring out the details of
> assignment?
> 
> There seems to be valid criticism about fully automating the workflow,
> but partial automation can still save huge amounts of time ...

Talking about which, I've toyed with asking for bug-assignment privileges 
for awhile, but haven't known who to ask, or if the privilege model is 
fine grained enough to give me that without giving me stuff I probably 
shouldn't have.

Such a button that could be made available to selected users, or even in 
general, since we already trust users with setting CC, adding archs, and 
even (controversially) with setting importance.  Arguably, even making 
this button available to all users would be but a small extension from 
that.

Meanwhile, lately I've started ccing the maintainer, based on equery 
meta's results for the package.  So far for this try I've had good 
results and faster bug resolution as I effectively bypassed wrangling, 
but awhile back I tried that on a bug and when wranglers did assign, they 
didn't take the CC out so the dev was getting two notices on changes and 
was a bit cranky about that.  So I make it a point to mention the CC now, 
so hopefully if a wrangler gets to it before the CCed dev, they can unCC 
at the same time they assign.

Too bad most of the components aren't fine grained enough to do direct 
assignment, as they do for kde and (IIRC) portage bugs, for instance.  I 
always thought gentoo's bz organization there was buggy, as it made a lot 
more sense to me to have say applications or libraries at the product 
level, and the cat/pkg at the component level, or even category as the 
product and package as the component.  But it was already too late to 
change that when I became a gentooer in 2004, let alone now.

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

Re: [gentoo-dev] Re: Automatic Bug Assignment

[NP-Hardass]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/06/2016 04:43 AM, Duncan wrote:
> Talking about which, I've toyed with asking for bug-assignment
> privileges for awhile, but haven't known who to ask, or if the
> privilege model is fine grained enough to give me that without
> giving me stuff I probably shouldn't have.

Currently, there exists one method, the editbugs privilege.
Basically, a developer sets their Bugzilla to watch the user's and the
developer is responsible for making sure the privilege is not abused.
 As it is right now, it's an all or nothing priv (as far as editing is
concerned, still restricted by ACLs out of private bugs, etc)
https://bugs.gentoo.org/show_bug.cgi?id=editbugs

- -- 
NP-Hardass
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWtcHuAAoJEBzZQR2yrxj7msMP/A1QtPS0saGRovQJZgwk5GTW
vNLxOsqd7w3jwel5sDcnsar9BARj04PdbYmF2baPg8N6rfFmJ+nD47olvym0maI/
JgEVJNiy2H1gJfR7Hz3UGDPeiYUnuQTpFe+fpIRU6yfqTGEIOt96wPX9bhKbp8+y
qbkaDfjmFLtvCQDPevvu/UuZHRZWBVvE4yrifOqHoAPeyD13qb3+1+yQdMLFCLxc
ZiC25qsHyRuPamzIgPK3CMBHaegGzRmuZ7bhhs90jndyc5OvSaE4E/dsO3PrG69f
vacCMY2WTRtbugyVTKKOzoROAd0PWYMvlFQvjJHG6ZQgswd2rlkaYkd4zzL1h2xl
l+ToDbZpL3/S9mBjjwObJ3rCGnU8HMdIFy9TRfeJpELdXj9P/6dczhgcsT6Fy3Wl
KFSREh7SGPLqc9A4Uddx++uJq/TTcvBRgddc26GEaXbrAra6BfaYqd8mswDCCIM1
H5CE4I0KlISsI2LUpMtRh0RxoqMJ7XwKxyflLvsTM2SkMb9naipriuFJGZZZsApB
6NAuZWhtqtvqa9PT9QdLK5mm1K/XYKqZRZPDzAAs70zcoCEPKqhczPIP3D/e1IHq
I/h54ns7OjINRXsY99mGx9ZUSYvKGgD5voxkfQD+sNeBf7HTPAbzyy5+8ZY0juKB
xdzySoZX2Vyik7ArQr6Y
=iHA4
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Automatic Bug Assignment

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

On Sat, Feb 06, 2016 at 09:09:13AM +0100, Patrick Lauer wrote:
> On 01/30/2016 06:45 PM, Alex Brandt wrote:
> > Hey Guys,
> >
> > I've oft wondered why we don't automatically assign bugs to the 
> > ebuild maintainer (if a CPV is in the subject).  Would there be an 
> > issue with adding a bug modification hook to bugzilla or a daily 
> > job to re-assign bugs to ebuild owners (if a CPV is in the 
> > subject)?
> >
> > Just curious not trying to incite anything.
> >
> > Regards,
> >
> Maybe we could add a "Assign to maintainer(s)" button visible only to
> certain groups of users, so that a bugwrangler who decides this bug is
> valid just has to hit one button instead of figuring out the details of
> assignment?
> 
> There seems to be valid criticism about fully automating the workflow,
> but partial automation can still save huge amounts of time ...

One concern I see with making this part of the web ui for Bugzilla is
that Bugzilla would have to be able to parse the metadata.xml files in
our portage tree to find the maintainers.

Something like this could be done pretty easily though with an external
program, a python script for example, using Bugzilla's web services API. [1]

William

[1] https://www.bugzilla.org/docs/5.0/en/html/api/Bugzilla/WebService.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] Automatic Bug Assignment

[Kent Fredric]

On 7 February 2016 at 04:26, William Hubbs <williamh@gentoo.org> wrote:
> One concern I see with making this part of the web ui for Bugzilla is
> that Bugzilla would have to be able to parse the metadata.xml files in
> our portage tree to find the maintainers.


You could simplify it with  a cron job that parses metadata.xml and
creates a quick lookup table of:

cat/pn  => {
    maintainers => [ ],
    bgo_category => $N
}

And then Bugzilla would just have to query some endpoint/index and
fetch the matching result.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Automatic Bug Assignment

[Patrice Clement]

[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]

Saturday 30 Jan 2016 11:45:48, Alex Brandt wrote :
> Hey Guys,
> 
> I've oft wondered why we don't automatically assign bugs to the 
> ebuild maintainer (if a CPV is in the subject).  Would there be an 
> issue with adding a bug modification hook to bugzilla or a daily 
> job to re-assign bugs to ebuild owners (if a CPV is in the 
> subject)?
> 
> Just curious not trying to incite anything.
> 
> Regards,
> 
> -- 
> Alex Brandt
> Software Developer for Rackspace and Developer for Gentoo
> http://blog.alunduil.com

Alex

I like your idea (I tought about it a while ago but never bothered raising the
issue on the gentoo-dev ML). So I looked around on the Internet to see if
there's another open source project like Gentoo who ran into a similar issue
with Bugzilla.

And it turns out there is (!).

Context: the FreeBSD project recently ditched GNATS in favour of Bugzilla [1].

FreeBSD devs now make heavy use of the bug tracker and like us, they try to
optimise Bugzilla and fine-tune it as best as they can. And like us, they ran
into this similar issue: how to automatically assign bugs. So they put together
a Bugzilla extension to fix this problem. Code is available here [2]. Since
it's already been implemented, no need to reinvent the wheel, we can find
inspiration through their code.

However, I'm not familiar at all with this code. If you have questions or want
to find out more, don't ask me, ask them! FreeBSD devs hang out in
#freebsd-bugs on freenode (at least the Bugzilla team). They've been really
helpful so far and are a delight to talk to. 

[1]: https://lists.freebsd.org/pipermail/freebsd-announce/2014-June/001559.html
[2]: https://github.com/freebsd/bugzilla/tree/freebsd-local/extensions/FBSDAutoAssign

Cheers,

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]