[gentoo-dev] Bug wrangling
Christian Faulhammer
please be careful when assigning new bugs. Today I changed several
bugs where the wrong maintainer was used or where the main maintainer
has been forgotten. This only occured since we have no full-time
bug-wrangler anymore. Was anyone successful to contact him, yet?
V-Li
--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
Ferris McCormick
On Mon, 2008-05-12 at 10:20 +0200, Christian Faulhammer wrote:
> Hi,
>
> please be careful when assigning new bugs. Today I changed several
> bugs where the wrong maintainer was used or where the main maintainer
> has been forgotten. This only occured since we have no full-time
> bug-wrangler anymore. Was anyone successful to contact him, yet?
>
> V-Li
I am told he should be back sometime soon, like today. Apparently
someone is in contact with him.
Regards,
Ferris
--
Ferris McCormick (P44646, MI) <fmc...@gentoo.org>
Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees)
Denis Dupeyron
> This only occured since we have no full-time
> > bug-wrangler anymore. Was anyone successful to contact him, yet?
> someone is in contact with him.
That he comes back or not is of no importance to bug wrangling. Or at
least it should be. It is a mistake to solely rely on a developer for
such a task. Developers come and go without warning, he just proved
it, so ideally we need a team of 2 or 3 to handle bug wrangling. Also,
one single developer handling this puts him/her in such a prominent
position that it is bad for him/her, our users, other developers and
the entire project. We had too many examples of this.
Denis.
--
gento...@lists.gentoo.org mailing list
Markus Ullmann
> That he comes back or not is of no importance to bug wrangling. Or at
> least it should be. It is a mistake to solely rely on a developer for
> such a task. Developers come and go without warning, he just proved
> it, so ideally we need a team of 2 or 3 to handle bug wrangling. Also,
> one single developer handling this puts him/her in such a prominent
> position that it is bad for him/her, our users, other developers and
> the entire project. We had too many examples of this.
Fully with you, yet the other people who do bug wrangling occasionally
didn't do it as good as him mainly because he followed all major
mailinglists and knew the common issues around. I have nowhere an idea
how much time he put into his bugwrangling but I bet that reaches at
least 5-6 hours a day. Replacing that is simply hard work and nothing
else and I'd love to see people stepping up to help with that task.
-Jokey
--
gento...@lists.gentoo.org mailing list
Mark Loeser
> That he comes back or not is of no importance to bug wrangling. Or at
> least it should be. It is a mistake to solely rely on a developer for
> such a task. Developers come and go without warning, he just proved
> it, so ideally we need a team of 2 or 3 to handle bug wrangling. Also,
> one single developer handling this puts him/her in such a prominent
> position that it is bad for him/her, our users, other developers and
> the entire project. We had too many examples of this.
Making an actual bug wrangling team (subproject of QA) is something
I've been toying around with in my head. I'd love to get an actual team
set up so we can encourage users to help us get the information we need
in bugs so it is less work for us. Several other distributions have
such projects, so we have something we can use as a template.
--
Mark Loeser
email - halcy0n AT gentoo DOT org
email - mark AT halcy0n DOT com
web - http://www.halcy0n.com
Duncan
excerpted below, on Mon, 12 May 2008 15:49:30 +0200:
> Fully with you, yet the other people who do bug wrangling occasionally
> didn't do it as good as him mainly because he followed all major
> mailinglists and knew the common issues around. I have nowhere an idea
> how much time he put into his bugwrangling but I bet that reaches at
> least 5-6 hours a day. Replacing that is simply hard work and nothing
> else and I'd love to see people stepping up to help with that task.
Yes. He knows his stuff and puts in quite a bit of time. Theoretical
problems with relying on one person or not, that just can't be easily or
well substituted, in practice, however much it might be a good idea not
to rely solely on one person. Like it or not, he is a central enough cog
in the machine that when he stops working, even with other cogs in place
to try to do the same duty, the entire machine gets glitchy.
So thanks, Jakob. We miss you! =8^)
--
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
--
gento...@lists.gentoo.org mailing list
Steve Long
> Making an actual bug wrangling team (subproject of QA) is something
> I've been toying around with in my head. I'd love to get an actual team
> set up so we can encourage users to help us get the information we need
> in bugs so it is less work for us. Several other distributions have
> such projects, so we have something we can use as a template.
>
ofc, so Gentoo devs are used to working with this model. Irrespective, it
doesn't preclude the need for a good bugmaster[3] but should be seen as
complementary to that person (it's rarely more than one apparently) iow to
support that person in their work.
That requires non-technical things (*cough* follow-up) like a sense of
teamwork, and not looking down on people who don't have cvs commit access.
Of course those also make it more likely that people will want to volunteer
for triage, or indeed anything else (which can be a virtuous circle.) I'd
moot Patrick as a useful bod because he can automate much of this.
[1] http://article.gmane.org/gmane.linux.gentoo.devel/46855
[2] http://article.gmane.org/gmane.linux.gentoo.devel/49546
[3] http://tieguy.org/talks/LCA-2005-paper-html/index.html
--
gento...@lists.gentoo.org mailing list
Rémi Cardona
> Mark Loeser wrote:
>> Making an actual bug wrangling team (subproject of QA) is something
>> I've been toying around with in my head. I'd love to get an actual team
>> set up so we can encourage users to help us get the information we need
>> in bugs so it is less work for us. Several other distributions have
>> such projects, so we have something we can use as a template.
Getting a team is an excellent idea. Jakub is one of those folks that
turn a boring yet essential activity into a craft (with the best
possible meaning of the word "craft").
We all know which devs/herds bugs should be assigned to, we all know
most bugs aren't complete if emerge --info is not provided, that sort of
things. But Real Bug Masters (tm) know all the dupes, know all the
current problems in our various trees and arches, and act as bug-spam
filters for the herds.
So while we can and do *survive* without Jakub, his role is invaluable
and having a proper team can only help us in the long term.
> That requires non-technical things (*cough* follow-up) like a sense of
> teamwork, and not looking down on people who don't have cvs commit access.
FWIW, Jakub never had CVS commit access, and specifically refused it.
He's only ever worked with Bugzilla and IRC (to ping, poke or harass
devs :) )
Cheers
Rémi
--
gento...@lists.gentoo.org mailing list
Donnie Berkholz
> We all know which devs/herds bugs should be assigned to, we all know most
> bugs aren't complete if emerge --info is not provided, that sort of things.
> But Real Bug Masters (tm) know all the dupes, know all the current problems
> in our various trees and arches, and act as bug-spam filters for the herds.
Would it be possible to add the tree categories as products and the
packages as components thereof? That would significantly increase the
odds of correct assignment, because we could save the per-package
assignees in the database.
Thanks,
Donnie
--
gento...@lists.gentoo.org mailing list
Duncan
20080513064...@comet.had1.or.comcast.net, excerpted below, on
Mon, 12 May 2008 23:47:49 -0700:
> Would it be possible to add the tree categories as products and the
> packages as components thereof? That would significantly increase the
> odds of correct assignment, because we could save the per-package
> assignees in the database.
++
I've wondered since I first began working with Gentoo why we couldn't
just do something simple like that. The way it's setup now has got to be
the most obtuse, non-intuitive organization for a simple user to try to
navigate and actually get right, that I've ever seen.
Something simple like cat/pkg would definitely be easier for the newbie
user than having everything (well, pretty much everything a user's going
to file bugs on, anyway) under "Gentoo Linux" /except/ a few things like
portage, and then trying to figure out whether (say) a non-core KDE sound
app goes in KDE, apps, sound, or ebuilds because it's an ebuild bug, or
what.
What would it take to make it tri-level? Then put just two choices at
the top level, like so:
Level 1: package-tree, all-other
Level 2:
2-tree: <cat>
2-other: infra, admin, docs, rel-media
Level 3:
3-<cat>: pkg
3-infra: mirrors, website, bugz, infra-other
3-admin: userrel, devrel, recruitement, admin-other
3-docs: doc-trans, docs-gentoo, docs-not-gentoo
3-rel-media: ...
If we went 4-level we could then add what's currently components under
some of the top-level stuff.
To me, that'd be about the most logical and intuitive layout possible,
but it'd take at least three levels to do right. The two-way tree/non-
tree split at the top, and cat/pkg on the tree side, would /vastly/
simplify bug filing for most users.
I know the first few times I filed a Gentoo bug, I was asking myself if
Gentoo /deliberately/ made it obtuse, because I couldn't figure out how
it could /possibly/ be that unintuitive by mere accident. The product as
a separate page did make things easier, but all one has to do is take a
look at the notes on the page to see it's still anything but intuitive.
Diego 'Flameeyes' Pettenò
> Would it be possible to add the tree categories as products and the
> packages as components thereof?
It makes moving a bug from one package to another quite a complex task
though, as it requires two confirmation screens... and trust me that
happens often enough.
Plus that would work fine if we had a bugzilla for ebuilds only, but
would you really mix categories together with Infra, Portage, Gentoo
Hosted Projects, ... ?
--
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/
Doug Goldstein
--
gento...@lists.gentoo.org mailing list
Steve Long
> Donnie Berkholz <dber...@gentoo.org> writes:
>
>> Would it be possible to add the tree categories as products and the
>> packages as components thereof?
>
> It makes moving a bug from one package to another quite a complex task
> though, as it requires two confirmation screens... and trust me that
> happens often enough.
>
Shouldn't that just be scripted via pybugz? A GUI for that would be nice;
perhaps as a pida[1] module. Frankly it appals me that y'all have so much
time to write bash scriptlets and none to develop tools for your own use.
> Plus that would work fine if we had a bugzilla for ebuilds only, but
> would you really mix categories together with Infra, Portage, Gentoo
> Hosted Projects, ... ?
>
Who cares? It's more organisation than you have now, and as I understand
Duncan's suggestion it's first about adding a category above pkgs within
Ebuilds <foo> (though I think he mixed up interface and tables a bit, sorry
Duncan ;) Tree is the most fundamental work, besides portage. I guess a tag
cloud would be nice tho. No reason you can't build associated metadata
webapps on another host (cf beandog's portage postgres db[2].)
[1] http://pida.co.uk/
[2] http://packages.larrythecow.org/ there's a FF plugin at:
http://mycroft.mozdev.org/download.html?name=larrythecow
--
gento...@lists.gentoo.org mailing list
Diego 'Flameeyes' Pettenò
>> It makes moving a bug from one package to another quite a complex task
>> though, as it requires two confirmation screens... and trust me that
>> happens often enough.
>>
> Shouldn't that just be scripted via pybugz? A GUI for that would be nice;
> perhaps as a pida[1] module. Frankly it appals me that y'all have so much
> time to write bash scriptlets and none to develop tools for your own
> use.
I like Bugzilla for the very reason I can look, comment and in general
manage bugs with decency without needing client software beside a
webbrowser, and I'm rarely without a webbrowser, heck, I had one at hand
even while I was hospitalised (not in the ICU though, that was boring).
Anything that requires me an extra software is something that I'm more
likely _not_ going to use.
>> Plus that would work fine if we had a bugzilla for ebuilds only, but
>> would you really mix categories together with Infra, Portage, Gentoo
>> Hosted Projects, ... ?
>>
> Who cares?
Uh, I do, as I tend to report a lot of bugs and I don't want to have to
use the find command of my browser to see where the heck should I report
it. Don't even get me started on template bugs that I use to mass-report
problems.
And probably most users would find the huge and long product
list to choose from most likely confusing. Users can't get it right
already with the short list we have, reporting bugs on Bugzilla product
which have nothing to do with Bugzilla...
Steve Long
> Steve Long <sl...@rathaus.eclipse.co.uk> writes:
>
>>> It makes moving a bug from one package to another quite a complex task
>>> though, as it requires two confirmation screens... and trust me that
>>> happens often enough.
>>>
>> Shouldn't that just be scripted via pybugz? A GUI for that would be nice;
>> perhaps as a pida[1] module. Frankly it appals me that y'all have so much
>> time to write bash scriptlets and none to develop tools for your own
>> use.
>
> I like Bugzilla for the very reason I can look, comment and in general
> manage bugs with decency without needing client software beside a
> webbrowser, and I'm rarely without a webbrowser, heck, I had one at hand
> even while I was hospitalised (not in the ICU though, that was boring).
> Anything that requires me an extra software is something that I'm more
> likely _not_ going to use.
>
OK so you'd like a webapp version as well.
[@project:
Users regularly offer help in this kind of area, simply because they use the
same interfaces as the devs, only for it to fall at the second or third dev
they interact with, if they're lucky.
]
>>> Plus that would work fine if we had a bugzilla for ebuilds only, but
>>> would you really mix categories together with Infra, Portage, Gentoo
>>> Hosted Projects, ... ?
>>>
>> Who cares?
>
> Uh, I do, as I tend to report a lot of bugs and I don't want to have to
> use the find command of my browser to see where the heck should I report
> it. Don't even get me started on template bugs that I use to mass-report
> problems.
>
> And probably most users would find the huge and long product
> list to choose from most likely confusing. Users can't get it right
> already with the short list we have, reporting bugs on Bugzilla product
> which have nothing to do with Bugzilla...
>
Yeah but the point of hierarchy is so that you do one step at a time (if you
want) via category -> package or just file the way you're used to. We're
still only talking about a small part, in data structural terms, of
bugzilla's schema, however much storage is allocated to the base level
bugs.
Keeping existing workflow would seem to be a requirement.
--
gento...@lists.gentoo.org mailing list