Re: Please move your ABRT bugs upstream

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am Sonntag, den 25.04.2010, 09:23 +0200 schrieb Kevin Kofler:
> Christoph Wickert wrote:
> > We have this nice ABRT tool now, so please let the bug reports our users
> > collect not be useless and forward them upstream cause that's where they
> > belong. We are not collecting these reports to let them rotten in our
> > bugzilla and get them closed by the bugzappers. This is frustrating both
> > for the users as well as for the developers.
> > 
> > Please, dear maintainers, take care of your ABRT reports and forward
> > them if you cannot handle them yourselves!
> 
> How is this our job?
> 
> The ABRT tool should file those bugs upstream in the first place. 

Agreed, but so far it does not and as long as it doesn't, you should
take care of that if you are interested in getting bugs fixed.

As I said before: We are the first line of support. We sort out the
useless reports and the duplicates, if necessary we ask for additional
data and once we have everything in place, we forward it upstream. We
already know the upstream bug trackers and have a login. We already know
the developers and how to reach them. It's easier for us to forward and
track the reports than for our users.

I'm doing this for ~ 130 packages and it works for me. Of course it is a
some work, but it's easier for 20 downstream maintainers to deal with 10
reports each a week than for a single upstream developer to deal with
200 bugs a week because his software is packaged in 20 distributions.

I really wonder what you think a maintainer has to do. You say testing
is not his job and taking care of bugs isn't ether. This leaves
packaging. Sorry, but to me this is a 'fire and forget' attitude.

> The fact 
> that they land in our distro bug tracker makes it a completely worthless and 
> broken tool.

I already told you several times that I consider this useful. One could
see if a crash affects this or that distro for example. If is affects
distro A, B and C but not X and Y, one can start looking at what distros
have in common and what are the differences.

For me it is important to see what bugs affect *our* packages, but if
all our reports are getting closed ether UPSTREAM or INSUFFICIENT_DATA,
there is no way for me to find out.

> It is just plain impossible for me to upstream the dozens of Gnash crashbugs 
> I get from ABRT. The best I can do is to use our Bugzilla's mass change 
> feature to needinfo a bunch at once and to close a bunch at once as 
> INSUFFICIENT_DATA if the reporter is too frigging lazy to upstream his 
> report (which is unfortunately the norm for ABRT-filed reports).

gnash is an extreme example. How many reports do you get per week? And
how many except of gnash?

> Speaking of lazy reporters, ABRT should probably also have a mandatory
> [] I agree that developers, packagers and/or triagers may contact me to 
> request further information and I will provide any such information when 
> possible
> checkbox and only file bugs if the reporter checked that checkbox. 

+1.

Nevertheless the bug handling doesn't work any better at KDE. I have
checked this checkbox (of course) and so far nobody had taken care of my
bugs while I'd be happy to provide more data. One bug was said to be
fixed in KDE 4.4.2 while it was not. Thanks to abrt I could provide a
new backtrace for 4.4.2 and file a new bug for the one that was closed
incorrectly.

> Current versions of KDE's DrKonqi have something like that.

And obviously a checkbox doesn't help ether to separate the 'lazy
idiots' from the active reporters. Q. E. D. ;)

Regards,
Christoph


-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux