What's wrong with ABRT? ALl the backtraces I get are unusable again. If Thunar crashes, not even Thunar-debuginfo gets installed.
abrt 1.0 worked here, then came 1.0.2 which was broken. 1.0.3 was working again, but got superseded be 1.0.4 only a few of days later. This means that most of the time, all the bugs submitted are basically useless.
For me as the maintainer it is a lot of work to reply to all these useless reports and for our users it's just frustrating if all their reports get closed INSUFFICIENT_DATA.
If the situation doesn't change any time soon, we IMHO should consider disabling abrt until the issues are fixed.
Regards, Christoph
On 02/05/2010 09:46 PM, Christoph Wickert wrote:
If the situation doesn't change any time soon, we IMHO should consider disabling abrt until the issues are fixed.
Agreed.
However, I went one step further: I removed ABRT from my systems, not because of issues I would have with it as a Fedora package maintainer, but because of usability issues I am having with it on the user-side and because of other issues I am having with it as sys-admin.
Worse, in this case, I feel the Fedora community is being abused to evaluate a semi-functional piece of SW's "yet uncooked" concepts.
Ralf
Ralf Corsepius wrote:
However, I went one step further: I removed ABRT from my systems, not because of issues I would have with it as a Fedora package maintainer, but because of usability issues I am having with it on the user-side and because of other issues I am having with it as sys-admin.
Worse, in this case, I feel the Fedora community is being abused to evaluate a semi-functional piece of SW's "yet uncooked" concepts.
+1. ABRT is just broken in so many ways it's not even funny and should never have been shipped in its current state.
Kevin Kofler
On Sat, Feb 06, 2010 at 12:23:31PM +0100, Kevin Kofler wrote:
Ralf Corsepius wrote:
However, I went one step further: I removed ABRT from my systems, not because of issues I would have with it as a Fedora package maintainer, but because of usability issues I am having with it on the user-side and because of other issues I am having with it as sys-admin.
Worse, in this case, I feel the Fedora community is being abused to evaluate a semi-functional piece of SW's "yet uncooked" concepts.
+1. ABRT is just broken in so many ways it's not even funny and should never have been shipped in its current state.
For yum related python backtrace bugs, it worked pretty well here and made bug reporting a lot easier. So maybe it should only be activated for cases where additional debuginfo is not needed.
Regards Till
Am Samstag, den 06.02.2010, 16:22 +0100 schrieb Till Maas:
On Sat, Feb 06, 2010 at 12:23:31PM +0100, Kevin Kofler wrote:
+1. ABRT is just broken in so many ways it's not even funny and should never have been shipped in its current state.
For yum related python backtrace bugs, it worked pretty well here and made bug reporting a lot easier. So maybe it should only be activated for cases where additional debuginfo is not needed.
Nice idea. IMO it should only allow to submit reports after some sanity checks. In my case where Thunar crashed and Thunar-debuginfo (and I have lots of these for other package as well) was not installed, it certainly would not have passed these tests.
Regards Till
Regards, Christoph
On Sat, Feb 06, 2010 at 04:22:27PM +0100, Till Maas wrote:
For yum related python backtrace bugs, it worked pretty well here and made bug reporting a lot easier. So maybe it should only be activated for cases where additional debuginfo is not needed.
This time it did not catch the bug: https://bugzilla.redhat.com/show_bug.cgi?id=563368
Regards Till
On 02/10/2010 01:12 AM, Till Maas wrote:
On Sat, Feb 06, 2010 at 04:22:27PM +0100, Till Maas wrote:
For yum related python backtrace bugs, it worked pretty well here and made bug reporting a lot easier. So maybe it should only be activated for cases where additional debuginfo is not needed.
This time it did not catch the bug: https://bugzilla.redhat.com/show_bug.cgi?id=563368
Regards Till
I think I did catch it (if ABRT was running), but ordinary users can't see other user's crashes (the command from this bz has to be run under root) unless root doesn't change this behaviour in abrt's config file.
J.
On Wed, Feb 10, 2010 at 10:23:48AM +0100, Jiri Moskovcak wrote:
I think I did catch it (if ABRT was running), but ordinary users can't see other user's crashes (the command from this bz has to be run under root) unless root doesn't change this behaviour in abrt's config file.
What do I have to change? The manpage (man abrt.conf) or default config (/etc/abrt/abrt.conf) does not give me a hint. Btw. can you maybe use PolicyKit to determine whether abrt-gui and the crashed program are run by the same person in case both happens via the local console?
Regards Till
On 02/10/2010 10:42 AM, Till Maas wrote:
On Wed, Feb 10, 2010 at 10:23:48AM +0100, Jiri Moskovcak wrote:
I think I did catch it (if ABRT was running), but ordinary users can't see other user's crashes (the command from this bz has to be run under root) unless root doesn't change this behaviour in abrt's config file.
What do I have to change? The manpage (man abrt.conf) or default config (/etc/abrt/abrt.conf) does not give me a hint. Btw. can you maybe use
You need to add this to the respective analyzer's configs:
InformAllUsers = yes
CCpp.conf - C/C++ xrashes analyzer Python.conf - python analyzer Kerneloops.conf - kerneloops (already has this enabled)
But this applies only to new crashes, the old ones will still be invisible for ordinary users. Working on updating the man-pages and wiki right now.
PolicyKit to determine whether abrt-gui and the crashed program are run by the same person in case both happens via the local console?
Yes, we're changing the behavior right now.
Regards Till
On Wed, Feb 10, 2010 at 10:58:03AM +0100, Jiri Moskovcak wrote:
You need to add this to the respective analyzer's configs:
InformAllUsers = yes
CCpp.conf - C/C++ xrashes analyzer Python.conf - python analyzer Kerneloops.conf - kerneloops (already has this enabled)
But this applies only to new crashes, the old ones will still be invisible for ordinary users. Working on updating the man-pages and wiki right now.
Thank you, after adding this to the Python.conf file and running service abrtd restart it now catches the python crash.
Regards Till
On Fri, 05 Feb 2010 21:46:54 +0100, Christoph wrote:
What's wrong with ABRT? ALl the backtraces I get are unusable again. If Thunar crashes, not even Thunar-debuginfo gets installed.
abrt 1.0 worked here, then came 1.0.2 which was broken. 1.0.3 was working again, but got superseded be 1.0.4 only a few of days later. This means that most of the time, all the bugs submitted are basically useless.
For me as the maintainer it is a lot of work to reply to all these useless reports and for our users it's just frustrating if all their reports get closed INSUFFICIENT_DATA.
If the situation doesn't change any time soon, we IMHO should consider disabling abrt until the issues are fixed.
Which kernel release? Perhaps related to this sweet little "war" about ABRT: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1237
Am Samstag, den 06.02.2010, 10:51 +0100 schrieb Michael Schwendt:
On Fri, 05 Feb 2010 21:46:54 +0100, Christoph wrote:
What's wrong with ABRT? ALl the backtraces I get are unusable again. If Thunar crashes, not even Thunar-debuginfo gets installed.
Which kernel release? Perhaps related to this sweet little "war" about ABRT: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1237
I am still using 2.6.31.12-174.2.3.fc12 and so do the submitters of the bug reports.
Regards, Christoph
IMO ABRT isn't that useful as a lot of the reports don't include steps to reproduce (I just close the bugs after a month if they don't respond to the "needinfo" request). I believe ABRT shouldn't file a bug report unless it is filled in properly.
On Sat, 06 Feb 2010 10:53:14 +0000, Leigh wrote:
IMO ABRT isn't that useful as a lot of the reports don't include steps to reproduce (I just close the bugs after a month if they don't respond to the "needinfo" request). I believe ABRT shouldn't file a bug report unless it is filled in properly.
Yeah, some of us have pointed out that before.
I'm happy about every detailed backtrace I get, but I would be even more happy if users contributed a tiny bit more and added comments to their tickets and responded to NEEDINFO queries and gave feedback on Test Updates. ABRT has lowered the hurdle so much that people dump generated reports into bugzilla but otherwise they appear like /dev/null and only show rarely that they care about a package.
On Sa, 2010-02-06 at 14:08 +0100, Michael Schwendt wrote: [...]
I'm happy about every detailed backtrace I get, but I would be even more happy if users contributed a tiny bit more and added comments to their tickets and responded to NEEDINFO queries and gave feedback on Test Updates. ABRT has lowered the hurdle so much that people dump generated reports into bugzilla but otherwise they appear like /dev/null and only show rarely that they care about a package.
On the one hand I agree with you on the other hand I see it from an users point of view and feel a bit in a pickle. For example, every second login gnome-panel crashes, removes Gnote from the panel and ABRT shows me a core dump. I cannot reproduce this problem except from a logout and login. So I cannot provide a detailed description what was going on and how to reproduce it (except as I already said: logout and login). But since it crashes that frequently I decided to report it anyway just in the hope that the package maintainer sees from the backtrace what is going wrong. Maybe this is not the best thing to do but after a couple of weeks seeing the red flash light several times a day you go crazy ;-)
However, in the meantime I stopped reporting crashes via ABRT because I think it raises the load for a package maintainer to high while the report should go directly to upstream. Bothering the maintainer first instead of upstream is not the right thing to do.
Just my experience.
cheers, Stefan
Le samedi 06 février 2010 15:53:03, Stefan Schulze Frielinghaus a écrit :
On Sa, 2010-02-06 at 14:08 +0100, Michael Schwendt wrote: [...]
I'm happy about every detailed backtrace I get, but I would be even more happy if users contributed a tiny bit more and added comments to their tickets and responded to NEEDINFO queries and gave feedback on Test Updates. ABRT has lowered the hurdle so much that people dump generated reports into bugzilla but otherwise they appear like /dev/null and only show rarely that they care about a package.
On the one hand I agree with you on the other hand I see it from an users point of view and feel a bit in a pickle. For example, every second login gnome-panel crashes, removes Gnote from the panel and ABRT shows me a core dump. I cannot reproduce this problem except from a logout and login. So I cannot provide a detailed description what was going on and how to reproduce it (except as I already said: logout and login). But since it crashes that frequently I decided to report it anyway just in the hope that the package maintainer sees from the backtrace what is going wrong. Maybe this is not the best thing to do but after a couple of weeks seeing the red flash light several times a day you go crazy ;-)
Same for me. I reported a crash in abrt-gui, without knowing what has caused it, with the hope that the maintainer can understand that from the backtrace.
Stefan Schulze Frielinghaus wrote:
However, in the meantime I stopped reporting crashes via ABRT because I think it raises the load for a package maintainer to high while the report should go directly to upstream. Bothering the maintainer first instead of upstream is not the right thing to do.
+1, in fact that's the biggest design failure in ABRT (in its current state) and basically makes it useless. Gathering backtraces is something that needs to be handled by upstream projects (like KDE does with KCrash/DrKonqi), not distributions.
Kevin Kofler
On Sat, Feb 06, 2010 at 06:53:31PM +0100, Kevin Kofler wrote:
Stefan Schulze Frielinghaus wrote:
However, in the meantime I stopped reporting crashes via ABRT because I think it raises the load for a package maintainer to high while the report should go directly to upstream. Bothering the maintainer first instead of upstream is not the right thing to do.
+1, in fact that's the biggest design failure in ABRT (in its current state) and basically makes it useless. Gathering backtraces is something that needs to be handled by upstream projects (like KDE does with KCrash/DrKonqi), not distributions.
Kevin Kofler
Seems like upstream projects managing app specific captures leads to either framentation of the capture method, or a lack of scalability (1 app per app to collect dumps for that app).
Might be better to have the bugzilla maintainers look at xml proxy methods to forward abrt captured backtraces to specific upstream project logging sites.
Neil
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Kevin Kofler wrote:
Stefan Schulze Frielinghaus wrote:
However, in the meantime I stopped reporting crashes via ABRT because I think it raises the load for a package maintainer to high while the report should go directly to upstream. Bothering the maintainer first instead of upstream is not the right thing to do.
+1, in fact that's the biggest design failure in ABRT (in its current state) and basically makes it useless. Gathering backtraces is something that needs to be handled by upstream projects (like KDE does with KCrash/DrKonqi), not distributions.
Some maintainers fix crashes in their packages and then send the fixes to the upstream, and some don't. Some crashes are caused by distribution-specific environment, and some are not :) It's not clear whether we should report crashes directly to the upstream.
For some packages, reporting upstream could work well (Firefox, OpenOffice.org come to my mind). However, many packages have unresponsive/dead upstream, upstream without issue tracker etc.
See rhbz#532307 for a beautiful example of cross-package bugfixing, which is very hard to do in upstream. At least eight applications will be fixed at the end (e.g. #542277, #547030, #550165, #558329, #561592, #561059)
Karel
On 02/07/2010 03:15 AM, Karel Klic wrote:
Kevin Kofler wrote:
Stefan Schulze Frielinghaus wrote:
However, in the meantime I stopped reporting crashes via ABRT because I think it raises the load for a package maintainer to high while the report should go directly to upstream. Bothering the maintainer first instead of upstream is not the right thing to do.
+1, in fact that's the biggest design failure in ABRT (in its current state) and basically makes it useless. Gathering backtraces is something that needs to be handled by upstream projects (like KDE does with KCrash/DrKonqi), not distributions.
To end-users, it's irrelevant "who is supposed to fix something". Their complaints are against the product call Fedora and thus expect "Fedora to fix their product".
That said: It's irrelevant to Toyota car owners, which supplier manufactured the parts which have caused Toyota to call back 1000 of their cars - To them it's Toyota who is reponisible, and Toyota's duty to fix this issue.
Some maintainers fix crashes in their packages and then send the fixes to the upstream, and some don't. Some crashes are caused by distribution-specific environment, and some are not :) It's not clear whether we should report crashes directly to the upstream.
History tells, low quality automated bug reports to be ignored and to cause a lot of bad blood. Debian for instance has an unfortunate history in doing so - You're better off to learn from their historic mistakes!
For some packages, reporting upstream could work well (Firefox, OpenOffice.org come to my mind).
You mean big, well-known projects with a fully-blown up infrastructure and bureaucracy in place. It's naive to expect such an infrastructure to be in place for all projects.
However, many packages have unresponsive/dead upstream, upstream without issue tracker etc.
Read my previous sentence.
Also take into account that many upstreams will consider automated bug reports, to be "simply SPAM", esp. when the find them to be of low quality. If you're lucky, they will simply ignore them, if you're less lucky, they will confront you with very harsh responses.
Finally: Why are we discussing this here?
This is all should have been part of ABRT's concepts, its upstream should have considered and resolved before unleashing ABRT.
On So, 2010-02-07 at 09:03 +0100, Ralf Corsepius wrote:
On 02/07/2010 03:15 AM, Karel Klic wrote:
Kevin Kofler wrote:
Stefan Schulze Frielinghaus wrote:
However, in the meantime I stopped reporting crashes via ABRT because I think it raises the load for a package maintainer to high while the report should go directly to upstream. Bothering the maintainer first instead of upstream is not the right thing to do.
+1, in fact that's the biggest design failure in ABRT (in its current state) and basically makes it useless. Gathering backtraces is something that needs to be handled by upstream projects (like KDE does with KCrash/DrKonqi), not distributions.
To end-users, it's irrelevant "who is supposed to fix something". Their complaints are against the product call Fedora and thus expect "Fedora to fix their product".
That said: It's irrelevant to Toyota car owners, which supplier manufactured the parts which have caused Toyota to call back 1000 of their cars - To them it's Toyota who is reponisible, and Toyota's duty to fix this issue.
But Toyota's employees do not do that after work in their free time. They get paid for it. If someone is paying me to fix bugs for upstream that's fine and I will try to fix every reported bug. I guess a lot of Fedora package maintainers do their packaging stuff in their spare free time and would say it is not the right thing to offload the work to them.
The analogy between Toyota and Fedora does not convince me ;-)
cheers, Stefan
On Sun, 07 Feb 2010 11:20:04 +0100, Stefan wrote:
On So, 2010-02-07 at 09:03 +0100, Ralf Corsepius wrote:
To end-users, it's irrelevant "who is supposed to fix something". Their complaints are against the product call Fedora and thus expect "Fedora to fix their product".
That said: It's irrelevant to Toyota car owners, which supplier manufactured the parts which have caused Toyota to call back 1000 of their cars - To them it's Toyota who is reponisible, and Toyota's duty to fix this issue.
But Toyota's employees do not do that after work in their free time. They get paid for it. If someone is paying me to fix bugs for upstream that's fine and I will try to fix every reported bug. I guess a lot of Fedora package maintainers do their packaging stuff in their spare free time and would say it is not the right thing to offload the work to them.
The analogy between Toyota and Fedora does not convince me ;-)
That's likely. Because the analogy isn't obvious - and reducing it to a relationship between a paying customer and a paid worker makes it even less obvious.
There is an analogy actually. Regardless of whether the Fedora Project consists of many volunteers, who do unpaid stuff in their spare time, Fedora delivers a product and will have to deal with its consumers and negative feedback. The fact that the product is free (as in "free beer") should not imply that it is worse than a commercial product. How far would you want to go with regard to a fat disclaimer about "no warranties", "free of charge", "no support", "hobbyist developers", to lower a consumer's expectations? A huge sticker on top of the product to advertise against trying it out? What is the added value we [at Fedora] try to add? Surely it isn't that we just lump together software in form of RPM packages _without_ testing and _without_ carefully picking releases and compatible components. Even if we don't guarantee anything, there must be something quality related, which _we_ _try_ to offer.
It's clear that if upstream software quality is poor and if nobody works on improving the software, it is more difficult for the Fedora packager to deliver quality. To shrug one's shoulders in reply to problem reports is the wrong way, however. And the more problem reports, the more important it gets to do something. As a last resort, software could get retired and removed from "The Product".
On So, 2010-02-07 at 12:52 +0100, Michael Schwendt wrote: [...]
There is an analogy actually. Regardless of whether the Fedora Project consists of many volunteers, who do unpaid stuff in their spare time, Fedora delivers a product and will have to deal with its consumers and negative feedback. The fact that the product is free (as in "free beer") should not imply that it is worse than a commercial product.
I completely agree and most open source software proofs that, but this was not the question. The question was if the package maintainer should be triggered first instead of upstream which increases the load for the package maintainer who might not be able to handle all of these requests in the end because it is not his/her full time job.
It's clear that if upstream software quality is poor and if nobody works on improving the software, it is more difficult for the Fedora packager to deliver quality. To shrug one's shoulders in reply to problem reports is the wrong way, however. And the more problem reports, the more important it gets to do something. As a last resort, software could get retired and removed from "The Product".
This is at least a good point to me. ABRT might point out software which needs more attention. If it is not possible to provide the needed power, then the package should be removed to keep the expected stability of Fedora.
cheers, Stefan
On Sun, 07 Feb 2010 14:23:13 +0100, Stefan wrote:
The question was if the package maintainer should be triggered first instead of upstream which increases the load for the package maintainer who might not be able to handle all of these requests in the end because it is not his/her full time job.
Well, that isn't straight-forward to answer IMO.
First of all, upstream may not be paid either for working on the software _and_ on incoming problem reports. What sort of "support" and response time can you expect from upstream in that case?
Secondly, the package maintainer should be informed about what is broken with the chosen/packaged software release. Certainly you don't ask for upstream to filter out *all* reports from all distributions, to return distribution-specific ones into a dist's own bug tracking system, and to work on incomplete backtraces or problems that aren't trivial to reproduce in the absence of the original bug reporter. Depending on the software quality it may be that upstream cannot handle all that either.
Fedora packages are not fire'n'forget releases. Even if you forwarded every bugzilla ticket to upstream, you would still need to monitor the status of the forwarded reports or fix issues yourself, provided that they matter to you. Whether they should matter to you also depends on project strategies and goals and whether Fedora wants to deliver added value. In some cases, the product (or individual packages) may suffer from insufficient contributor resources, and a single package maintainer may not be enough.
ABRT might point out software which needs more attention.
That is not its task. Bugzilla statistical queries could examine packages for a high number of open/unresponded tickets, a growing number of tickets closed by the bugzapper scripts at dist EOL, a low update frequency, and a package owner who isn't responsive for other packages either.
On So, 2010-02-07 at 15:34 +0100, Michael Schwendt wrote:
On Sun, 07 Feb 2010 14:23:13 +0100, Stefan wrote:
The question was if the package maintainer should be triggered first instead of upstream which increases the load for the package maintainer who might not be able to handle all of these requests in the end because it is not his/her full time job.
Well, that isn't straight-forward to answer IMO.
First of all, upstream may not be paid either for working on the software _and_ on incoming problem reports. What sort of "support" and response time can you expect from upstream in that case?
Secondly, the package maintainer should be informed about what is broken with the chosen/packaged software release. Certainly you don't ask for upstream to filter out *all* reports from all distributions, to return distribution-specific ones into a dist's own bug tracking system, and to work on incomplete backtraces or problems that aren't trivial to reproduce in the absence of the original bug reporter. Depending on the software quality it may be that upstream cannot handle all that either.
Fedora packages are not fire'n'forget releases. Even if you forwarded every bugzilla ticket to upstream, you would still need to monitor the status of the forwarded reports or fix issues yourself, provided that they matter to you. Whether they should matter to you also depends on project strategies and goals and whether Fedora wants to deliver added value. In some cases, the product (or individual packages) may suffer from insufficient contributor resources, and a single package maintainer may not be enough.
Hmm yeah. I see the problem. It would even get worse when e.g. some patches are applied to the package, then upstream couldn't even debug properly.
Nasty situation ;-) I will think about it. Hopefully it was not too off topic.
Thanks for letting me know, Stefan
Michael Schwendt wrote:
Secondly, the package maintainer should be informed about what is broken with the chosen/packaged software release. Certainly you don't ask for upstream to filter out *all* reports from all distributions, to return distribution-specific ones into a dist's own bug tracking system,
Most problems are not distribution-specific. For the ones which are, they can close the bugs as DOWNSTREAM, NOTOURBUG or whatever their Bugzilla uses for that case and tell the user to report them to the distribution. It's less work for them do to that for the few bugs which happen to be distribution-specific than for us to do the opposite for the common case.
and to work on incomplete backtraces or problems that aren't trivial to reproduce in the absence of the original bug reporter.
That's why bugs should not be forwarded by us, but filed directly upstream.
Fedora packages are not fire'n'forget releases.
Once upstream fixes the issue (which will result in bugmail to the reporter), it's OK to file a bug to us asking us to backport the fix. But if the package is maintained properly (like e.g. KDE), the next release with the fix will be pushed soon anyway.
Kevin Kofler
On 02/07/2010 07:46 PM, Kevin Kofler wrote:
Michael Schwendt wrote:
Secondly, the package maintainer should be informed about what is broken with the chosen/packaged software release. Certainly you don't ask for upstream to filter out *all* reports from all distributions, to return distribution-specific ones into a dist's own bug tracking system,
Most problems are not distribution-specific.
Yes.
For the ones which are, they can close the bugs as DOWNSTREAM, NOTOURBUG or whatever their Bugzilla uses for that case and tell the user to report them to the distribution.
No.
A Fedora maintainer acting this way, is cheating at his users and at himself.
All he does, is delegating responsibility on bugs around, while * "bug remains unfixed" in Fedora * "user remains exposed to the bug"
Overall, this results into Fedora consisting of packages suffering from known bugs. Depending on the severity of such bugs and the amount of the such bugs, this easily ends up in a low quality distro.
Ralf
Michael Schwendt wrote:
As a last resort, software could get retired and removed from "The Product".
I'm not sure not shipping something at all is better for the user than shipping it with bugs, even if they never get fixed. Often even a buggy software is better than nothing.
Kevin Kofler
On 02/07/2010 12:52 PM, Michael Schwendt wrote:
On Sun, 07 Feb 2010 11:20:04 +0100, Stefan wrote:
On So, 2010-02-07 at 09:03 +0100, Ralf Corsepius wrote:
To end-users, it's irrelevant "who is supposed to fix something". Their complaints are against the product call Fedora and thus expect "Fedora to fix their product".
That said: It's irrelevant to Toyota car owners, which supplier manufactured the parts which have caused Toyota to call back 1000 of their cars - To them it's Toyota who is reponisible, and Toyota's duty to fix this issue.
But Toyota's employees do not do that after work in their free time. They get paid for it. If someone is paying me to fix bugs for upstream that's fine and I will try to fix every reported bug. I guess a lot of Fedora package maintainers do their packaging stuff in their spare free time and would say it is not the right thing to offload the work to them.
The analogy between Toyota and Fedora does not convince me ;-)
That's likely. Because the analogy isn't obvious - and reducing it to a relationship between a paying customer and a paid worker makes it even less obvious. There is an analogy actually. Regardless of whether the Fedora Project consists of many volunteers, who do unpaid stuff in their spare time, Fedora delivers a product and will have to deal with its consumers and negative feedback. The fact that the product is free (as in "free beer") should not imply that it is worse than a commercial product.
Exactly. As a "user" I consider the "Fedora distro" to be a product of the "Fedora Project", regardless of who the people behind this vendor actually are and regardless of its price.
How far would you want to go with regard to a fat disclaimer about "no warranties", "free of charge", "no support", "hobbyist developers", to lower a consumer's expectations?
To me, "free of charge" only implies "user will not sue vendor". It's not a "card blanche" for "low quality" nor for "carelessness/negligence" nor for "unprofessionalism".
A huge sticker on top of the product to advertise against trying it out? What is the added value we [at Fedora] try to add? Surely it isn't that we just lump together software in form of RPM packages _without_ testing and _without_ carefully picking releases and compatible components. Even if we don't guarantee anything, there must be something quality related, which _we_ _try_ to offer.
It's clear that if upstream software quality is poor and if nobody works on improving the software, it is more difficult for the Fedora packager to deliver quality.
Right, in such cases "the Fedora product vendor's representative in charge" of the "low quality component of the Fedora product" has decide upon consequences.
Car manufacturers do the same: It's called QA.
If a supplier doesn't supply the quality they want, they decide upon what to do: "refurbish/fix the component", "return component to supplier", switch "supplier", redesign the "component" or even redesign a larger part of the "product", such that other component vendors' products can replace the "low quality component".
It's the same in Fedora: If a piece of SW in Fedora is broken, then the Fedora maintainers needs to take care about it to prevent to Fedora user-base to be exposed to this bugs. Of course, he can optionally consult upstream, consult others etc. ... nevertheless it's still the Fedora package maintainer who is responsible for is "user-base".
To shrug one's shoulders in reply to problem reports is the wrong way, however. And the more problem reports, the more important it gets to do something. As a last resort, software could get retired and removed from "The Product".
Agreed - ABRT is such a case, IMNSHO. Remove it from the distro and send its devs "back to the drawing board".
Ralf
Michael Schwendt wrote:
I'm happy about every detailed backtrace I get, but I would be even more happy if users contributed a tiny bit more and added comments to their tickets and responded to NEEDINFO queries and gave feedback on Test Updates. ABRT has lowered the hurdle so much that people dump generated reports into bugzilla but otherwise they appear like /dev/null and only show rarely that they care about a package.
Requests to report the crash upstream usually also fall on deaf ears (when all they'd really need to do is copy&paste the generated text and a link to the attached backtrace into the upstream bug tracker).
Without some mechanism to either make ABRT file bugs directly upstream or automatically forward them (in a way which keeps the reporter in the loop, in the hope that they might actually care!), it's basically useless.
There's no way I can fix the dozens of crashes in Gnash myself.
Kevin Kofler
On Sat, Feb 6, 2010 at 6:56 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Michael Schwendt wrote:
I'm happy about every detailed backtrace I get, but I would be even more happy if users contributed a tiny bit more and added comments to their tickets and responded to NEEDINFO queries and gave feedback on Test Updates. ABRT has lowered the hurdle so much that people dump generated reports into bugzilla but otherwise they appear like /dev/null and only show rarely that they care about a package.
Requests to report the crash upstream usually also fall on deaf ears (when all they'd really need to do is copy&paste the generated text and a link to the attached backtrace into the upstream bug tracker).
Without some mechanism to either make ABRT file bugs directly upstream or automatically forward them (in a way which keeps the reporter in the loop, in the hope that they might actually care!), it's basically useless.
There's no way I can fix the dozens of crashes in Gnash myself.
Well reports should go to the maintainer first, he should forward it to upstream as needed.
What needs to be fixed here is bugzilla not ABRT, we need a "report upstream" button.
Am Samstag, den 06.02.2010, 19:27 +0100 schrieb drago01:
Well reports should go to the maintainer first, he should forward it to upstream as needed.
I disagree. Basically there are two situations: 1. The backtrace or the bug report is incomplete. In 95% of these cases submitters don't bother to provide any more info and the bug gets closed INSUFFICIENT_DATA. This should not get filed upstream at all, nether in Fedora, not somewhere upstream. 2. The backtrace is fine and self-explanatory for the developer. In this case it should go directly to upstream.
What needs to be fixed here is bugzilla not ABRT, we need a "report upstream" button.
Ok, and where is the "submit downstream" button in upstream's bug tracker? The Fedora maintainer still will have to forward replies, questions, calls for testing etc. from upstream back to the user and this is a lot of work.
Regards, Christoph
Am Samstag, den 06.02.2010, 20:18 +0100 schrieb Christoph Wickert:
Am Samstag, den 06.02.2010, 19:27 +0100 schrieb drago01:
What needs to be fixed here is bugzilla not ABRT, we need a "report upstream" button.
Ok, and where is the "submit downstream" button in upstream's bug tracker? The Fedora maintainer still will have to forward replies, questions, calls for testing etc. from upstream back to the user and this is a lot of work.
Maybe he wants to have our bugzilla and upstreams bugzilla connected, so that the developer can directly talk to the reporter and propose a fix, that the maintainer can submit to the testing repos. Not a bad idea.
Thomas
On Sat, Feb 6, 2010 at 9:01 PM, Thomas Spura spurath@students.uni-mainz.de wrote:
Am Samstag, den 06.02.2010, 20:18 +0100 schrieb Christoph Wickert:
Am Samstag, den 06.02.2010, 19:27 +0100 schrieb drago01:
What needs to be fixed here is bugzilla not ABRT, we need a "report upstream" button.
Ok, and where is the "submit downstream" button in upstream's bug tracker? The Fedora maintainer still will have to forward replies, questions, calls for testing etc. from upstream back to the user and this is a lot of work.
Maybe he wants to have our bugzilla and upstreams bugzilla connected, so that the developer can directly talk to the reporter and propose a fix, that the maintainer can submit to the testing repos. Not a bad idea.
Yeah exactly, I wasn't suggesting that the maintainer should act as a proxy between user and upstream developer (that would be insane).
Am Samstag, den 06.02.2010, 21:59 +0100 schrieb drago01:
On Sat, Feb 6, 2010 at 9:01 PM, Thomas Spura spurath@students.uni-mainz.de wrote:
Am Samstag, den 06.02.2010, 20:18 +0100 schrieb Christoph Wickert:
Am Samstag, den 06.02.2010, 19:27 +0100 schrieb drago01:
What needs to be fixed here is bugzilla not ABRT, we need a "report upstream" button.
Ok, and where is the "submit downstream" button in upstream's bug tracker? The Fedora maintainer still will have to forward replies, questions, calls for testing etc. from upstream back to the user and this is a lot of work.
Maybe he wants to have our bugzilla and upstreams bugzilla connected, so that the developer can directly talk to the reporter and propose a fix, that the maintainer can submit to the testing repos. Not a bad idea.
Yeah exactly, I wasn't suggesting that the maintainer should act as a proxy between user and upstream developer (that would be insane).
Right, but this is what I am currently spending a lot of my time on. :(
Regards, Christoph
On Sat, 2010-02-06 at 14:08 +0100, Michael Schwendt wrote:
On Sat, 06 Feb 2010 10:53:14 +0000, Leigh wrote:
IMO ABRT isn't that useful as a lot of the reports don't include steps to reproduce (I just close the bugs after a month if they don't respond to the "needinfo" request). I believe ABRT shouldn't file a bug report unless it is filled in properly.
Yeah, some of us have pointed out that before.
And, IIRC, Jiri has already agreed and said this will be implemented, so why bring it up again?
On Sat, 2010-02-06 at 13:32 -0800, Adam Williamson wrote:
And, IIRC, Jiri has already agreed and said this will be implemented, so why bring it up again? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
I have only recently subscribed to the devel-list and haven't had the time to trawl though it all.
On Sat, 2010-02-06 at 21:48 +0000, Leigh Scott wrote:
On Sat, 2010-02-06 at 13:32 -0800, Adam Williamson wrote:
And, IIRC, Jiri has already agreed and said this will be implemented, so why bring it up again? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
I have only recently subscribed to the devel-list and haven't had the time to trawl though it all.
Yeah, I actually only meant to send the more polite version of that email. Damn Evolution :)
On Sat, 2010-02-06 at 14:08 +0100, Michael Schwendt wrote:
On Sat, 06 Feb 2010 10:53:14 +0000, Leigh wrote:
IMO ABRT isn't that useful as a lot of the reports don't include steps to reproduce (I just close the bugs after a month if they don't respond to the "needinfo" request). I believe ABRT shouldn't file a bug report unless it is filled in properly.
Yeah, some of us have pointed out that before.
I believe Jiri has already agreed and said this will be implemented.
Michael Schwendt mschwendt@gmail.com writes:
I believe ABRT shouldn't file a bug report unless it is filled in properly.
Yeah, some of us have pointed out that before. I'm happy about every detailed backtrace I get, but I would be even more happy if users contributed a tiny bit more and added comments to their tickets and responded to NEEDINFO queries and gave feedback on Test Updates. [...]
How much more useful would it be if ABRT had a mode where executables that recently reported crashes are subsequently/temporarily run with syscall tracing in the background, so that if they crash again, then recent process syscall history can also be optionally included in an ABRT report? This would not be hard to do with e.g. systemtap.
- FChE
On 02/08/2010 05:36 PM, Frank Ch. Eigler wrote:
Michael Schwendtmschwendt@gmail.com writes:
I believe ABRT shouldn't file a bug report unless it is filled in properly.
Yeah, some of us have pointed out that before. I'm happy about every detailed backtrace I get, but I would be even more happy if users contributed a tiny bit more and added comments to their tickets and responded to NEEDINFO queries and gave feedback on Test Updates. [...]
How much more useful would it be if ABRT had a mode where executables that recently reported crashes are subsequently/temporarily run with syscall tracing in the background, so that if they crash again, then recent process syscall history can also be optionally included in an ABRT report? This would not be hard to do with e.g. systemtap.
- FChE
Such log would be nice, but it might take some time (even days) before the app crashes again and I can imagine that could generate quite a large log :-/ Maybe if it would store just last few syscalls...
J.
Jiri Moskovcak jmoskovc@redhat.com writes:
Such log would be nice, but it might take some time (even days) before the app crashes again and I can imagine that could generate quite a large log :-/ Maybe if it would store just last few syscalls...
Sure, some circular logging, the last few thousand syscalls, no problem.
- FChE
On Sat, 2010-02-06 at 10:53 +0000, Leigh Scott wrote:
IMO ABRT isn't that useful as a lot of the reports don't include steps to reproduce (I just close the bugs after a month if they don't respond to the "needinfo" request).
You can do it even sooner. If backtrace is unusable and there is no description whatsoever, then *this* user is not likely to bother to do anything to help you.
I believe ABRT shouldn't file a bug report unless it is filled in properly.
Sadly, this is impossible to achieve. Sure, we can
if (description == "") yell("Fill the description dammit!");
but then user might well enter description consisting of "I dont care" (or worse).
On Wed, 2010-02-10 at 15:48 +0100, Denys Vlasenko wrote:
On Sat, 2010-02-06 at 10:53 +0000, Leigh Scott wrote:
IMO ABRT isn't that useful as a lot of the reports don't include steps to reproduce (I just close the bugs after a month if they don't respond to the "needinfo" request).
You can do it even sooner. If backtrace is unusable and there is no description whatsoever, then *this* user is not likely to bother to do anything to help you.
I believe ABRT shouldn't file a bug report unless it is filled in properly.
Sadly, this is impossible to achieve. Sure, we can
if (description == "") yell("Fill the description dammit!");
but then user might well enter description consisting of "I dont care" (or worse).
You're contradicting yourself here. First you say we should close bugs without a description even sooner (like, immediately?), then you don't want abrt to not file a report without a description. I don't see why we should manually do the work abrt fails to do automatically -- while it is automatable.
What strikes me as very puzzling is why abrt has this humongous dialog instead of leading the user step-by-step through this... I know you just changed the UI in a stable release. But doing it twice is twice fun ;-), so why not use a wizard (taking the user by the hand, doing it step by step...) and do it like this:
1. Check if the bug has been reported yet (via that abrt BZ id thingy). If yes, ask user to review the description (in their browser?) and eventually add any additional details (see below in step 3a. for hints abrt could provide for that), then stop here. Otherwise continue.
2. Check that all debuginfos can be installed etc, then continue. If not, tell the user that "important debugging data" can't be assembled right now and a) if they would like to postpone the bug report, if you assume that it's a temporary problem or b) "there's an update for package(s) ... which are used by your application, would you like to install them?", as this seems to be the most common case of debuginfos not being available.
3a. Display wizard window. Ask users (politely!) for a description of what they did before the crash happened:
"Please describe what you did before the application crashed. Provide as much detail as you can, this is important for the person getting the bug report to help you. If this is too much work for you right now, you can make some notes about details that are hard to remember in this field, click on "Postpone report" below
_Hints for filling out this form_
...
[Cancel report] [Postpone report] [Back] [Forward]"
The buttons would be visible on any page in the wizard, [Back] would be insensitive here because it's the first step. "_Hints for filling out this form_" would be a link which would open a help page going into much more detail, e.g.:
"... If you didn't use the app for a long while, state that, but try to remember what you did when you last used it. Please also describe what else you did immediately before the crash. ..."
Also provide examples of good and bad descriptions in this.
3b. While the user fills out the description, abrt loads debuginfo packages in the background. If the user is ready before all are downloaded, display the usual progress bar.
4. Next wizard page. Display backtrace, ask for review and removal of sensitive data like passwords. "You don't need to understand most of this, but if you see data )like passwords) you would not like to be put into the bug report (which may be seen by anybody), please replace it with a placeholder (like '<password>')."
5. Last wizard page. Get confirmation for filing the bug report. "You can review what will be submitted by using the Back and Forward buttons at the bottom of this dialog." Fields for Bugzilla username and password, pre-filled if we have that information already. "[ ] Remember this information" checkbox.
If the user postponed this, they must have a means of continuing this, so the applet may not be hidden in this case. While I'm at it, the applet shouldn't flash forever, this breaks energy-saving measures (if the user ignored it for a minute, they'll ignore it for an hour -- maybe wake up it screensaver gets active, then inactive/unlocked).
In my opinion this would be much less intimidating to users and give us bug reports where we can actually help instead of having to tell most of them "sorry, too few info, can't help" right away.
Those who don't care enough to fill out the description probably won't care enough to create a BZ account in the first place. If there are trolls who would put nonsense into the description or worse, well those could do that via web-based BZ as well. And they can be dealt with.
Nils
On 02/12/2010 03:15 AM, Nils Philippsen wrote:
On Wed, 2010-02-10 at 15:48 +0100, Denys Vlasenko wrote:
On Sat, 2010-02-06 at 10:53 +0000, Leigh Scott wrote:
IMO ABRT isn't that useful as a lot of the reports don't include steps to reproduce (I just close the bugs after a month if they don't respond to the "needinfo" request).
You can do it even sooner. If backtrace is unusable and there is no description whatsoever, then *this* user is not likely to bother to do anything to help you.
I believe ABRT shouldn't file a bug report unless it is filled in properly.
Sadly, this is impossible to achieve. Sure, we can
if (description == "") yell("Fill the description dammit!");
but then user might well enter description consisting of "I dont care" (or worse).
You're contradicting yourself here. First you say we should close bugs without a description even sooner (like, immediately?), then you don't want abrt to not file a report without a description. I don't see why we should manually do the work abrt fails to do automatically -- while it is automatable.
What strikes me as very puzzling is why abrt has this humongous dialog instead of leading the user step-by-step through this... I know you just changed the UI in a stable release. But doing it twice is twice fun ;-), so why not use a wizard (taking the user by the hand, doing it step by step...) and do it like this:
- Check if the bug has been reported yet (via that abrt BZ id thingy).
If yes, ask user to review the description (in their browser?) and eventually add any additional details (see below in step 3a. for hints abrt could provide for that), then stop here. Otherwise continue.
- Check that all debuginfos can be installed etc, then continue. If
not, tell the user that "important debugging data" can't be assembled right now and a) if they would like to postpone the bug report, if you assume that it's a temporary problem or b) "there's an update for package(s) ... which are used by your application, would you like to install them?", as this seems to be the most common case of debuginfos not being available.
3a. Display wizard window. Ask users (politely!) for a description of what they did before the crash happened:
"Please describe what you did before the application crashed. Provide as much detail as you can, this is important for the person getting the bug report to help you. If this is too much work for you right now, you can make some notes about details that are hard to remember in this field, click on "Postpone report" below
_Hints for filling out this form_
...
[Cancel report] [Postpone report] [Back] [Forward]"
The buttons would be visible on any page in the wizard, [Back] would be insensitive here because it's the first step. "_Hints for filling out this form_" would be a link which would open a help page going into much more detail, e.g.:
"... If you didn't use the app for a long while, state that, but try to remember what you did when you last used it. Please also describe what else you did immediately before the crash. ..."
Also provide examples of good and bad descriptions in this.
3b. While the user fills out the description, abrt loads debuginfo packages in the background. If the user is ready before all are downloaded, display the usual progress bar.
- Next wizard page. Display backtrace, ask for review and removal of
sensitive data like passwords. "You don't need to understand most of this, but if you see data )like passwords) you would not like to be put into the bug report (which may be seen by anybody), please replace it with a placeholder (like '<password>')."
- Last wizard page. Get confirmation for filing the bug report. "You
can review what will be submitted by using the Back and Forward buttons at the bottom of this dialog." Fields for Bugzilla username and password, pre-filled if we have that information already. "[ ] Remember this information" checkbox.
If the user postponed this, they must have a means of continuing this, so the applet may not be hidden in this case. While I'm at it, the applet shouldn't flash forever, this breaks energy-saving measures (if the user ignored it for a minute, they'll ignore it for an hour -- maybe wake up it screensaver gets active, then inactive/unlocked).
In my opinion this would be much less intimidating to users and give us bug reports where we can actually help instead of having to tell most of them "sorry, too few info, can't help" right away.
Those who don't care enough to fill out the description probably won't care enough to create a BZ account in the first place. If there are trolls who would put nonsense into the description or worse, well those could do that via web-based BZ as well. And they can be dealt with.
Nils
Hi, Thanks for good hints, I'm already working on a wizard style gui for ABRT, to walk the user thru the reporting proccess, so I'll definitely implement some of you ideas into it.
Thanks, Jirka
On Fri, Feb 12, 2010 at 03:15:39AM +0100, Nils Philippsen wrote:
What strikes me as very puzzling is why abrt has this humongous dialog instead of leading the user step-by-step through this... I know you just changed the UI in a stable release. But doing it twice is twice fun ;-), so why not use a wizard (taking the user by the hand, doing it step by step...) and do it like this:
For me the dialog works pretty well and I suspect a wizard would only slowdown it. So if there is some wizard added, please make it optional.
Regards Till
On Fri, 2010-02-12 at 10:42 +0100, Till Maas wrote:
On Fri, Feb 12, 2010 at 03:15:39AM +0100, Nils Philippsen wrote:
What strikes me as very puzzling is why abrt has this humongous dialog instead of leading the user step-by-step through this... I know you just changed the UI in a stable release. But doing it twice is twice fun ;-), so why not use a wizard (taking the user by the hand, doing it step by step...) and do it like this:
For me the dialog works pretty well and I suspect a wizard would only slowdown it. So if there is some wizard added, please make it optional.
I guess the normal all-in-one dialog is simple enough that it can be kept as an option.
Nils
Christoph Wickert wrote:
What's wrong with ABRT? ALl the backtraces I get are unusable again. If Thunar crashes, not even Thunar-debuginfo gets installed.
There is a flaw in ABRT 1.0.4, which allows to submit incomplete backtraces. It got into the source code during the GUI rewrite.
There is abrt-1.0.6 in Fedora 12 testing repository, which contains a fix for this issue.
abrt 1.0 worked here, then came 1.0.2 which was broken. 1.0.3 was working again, but got superseded be 1.0.4 only a few of days later. This means that most of the time, all the bugs submitted are basically useless.
It became better with later releases, but the bug you described made it bad again (for this release).
As far as I can tell, the last large-scale change (the new GUI) was finished in 1.0.4. It introduced some bugs, but those are fixed now. A lot of people complained about the old GUI, so it seemed to us (the ABRT team) that the GUI overhaul was mandatory. Well, some people complain about the current GUI, but IMHO its better.
The latest version (1.0.6) contains mostly bug fixes, so it should not break things, it should make ABRT reports sane again.
For me as the maintainer it is a lot of work to reply to all these useless reports and for our users it's just frustrating if all their reports get closed INSUFFICIENT_DATA.
IMHO it's not so frustrating for users, as it is frustrating for some maintainers. Users want to help by reporting crashes, but it doesn't make you sad when the crash you just reported was not useful at the end (you invested a few clicks in reporting that crash).
ABRT hurt some maintainers in Fedora 12. I believe the following Fedora releases will benefit from ABRT, as the crashes in the bleeding edge software introduced in every release will be quickly detected and fixed.
I am now going to write a script which detects all the backtraces without debuginfo in Bugzilla, and closes the bugs as INSUFFICIENT_DATA with an apology. I do not know how many of them are in Bugzilla, but those can be detected and closed automatically (more info soon, it should be hacked together quickly).
If the situation doesn't change any time soon, we IMHO should consider disabling abrt until the issues are fixed.
Please consider testing and adding +1 karma to ABRT 1.0.6 in Bodhi.
Also a script [1] which finds all the duplicate backtraces (we can find) in Bugzilla has been written. Those duplicates were made by older ABRT versions without good duplicate detection. ~900 bugs can be closed with this script. Hopefully it removes some burden from package maintainers.
[1] https://fedorahosted.org/abrt/browser/src/Backtrace/abrt-bz-dupchecker
Best Regards, Karel
Le samedi 06 février 2010 18:03:23, Karel Klic a écrit :
Christoph Wickert wrote:
What's wrong with ABRT? ALl the backtraces I get are unusable again. If Thunar crashes, not even Thunar-debuginfo gets installed.
There is a flaw in ABRT 1.0.4, which allows to submit incomplete backtraces. It got into the source code during the GUI rewrite.
Anyway, there should be a tool in ABRT suite, that allows a package maintainer to reconstruct a complete backtrace from an incomplete on, using only the list of involved packages, with there evr(+arch).
On Sat, Feb 6, 2010 at 18:03, Karel Klic kklic@redhat.com wrote:
It became better with later releases, but the bug you described made it bad again (for this release).
As far as I can tell, the last large-scale change (the new GUI) was finished in 1.0.4. It introduced some bugs, but those are fixed now.
Was it really a good idea to push it to a stable release of Fedora if it was such a « large-scale change » ?
---------- Mathieu Bridon
On Sat, 06 Feb 2010 18:03:23 +0100 Karel Klic kklic@redhat.com wrote:
...snip...
Please consider testing and adding +1 karma to ABRT 1.0.6 in Bodhi.
Sadly, I don't think it's going to get much testing currently.
The only folks who can test it are those that just enable updates-testing and update abrt. Anyone who keeps updates-testing enabled fully will have the newer kernel that doesn't work with abrt. ;(
So, I think we need a fixed kernel in updates-testing and wait a bit before pushing this to stable, IMHO.
kevin
Karel Klic wrote:
Christoph Wickert wrote:
For me as the maintainer it is a lot of work to reply to all these useless reports and for our users it's just frustrating if all their reports get closed INSUFFICIENT_DATA.
I am now going to write a script which detects all the backtraces without debuginfo in Bugzilla, and closes the bugs as INSUFFICIENT_DATA with an apology. I do not know how many of them are in Bugzilla, but those can be detected and closed automatically (more info soon, it should be hacked together quickly).
The script to find backtraces without debuginfo has been written[1]. I placed the list of found bugs to the Fedora wiki [2]. IMHO only bugs with 2 comments should be closed, because 2 comments mean that the package maintainer did not touch the bug (ABRT adds 2 comments to every bug it creates). We can close 129 bugs this way.
Also a script [1] which finds all the duplicate backtraces (we can find) in Bugzilla has been written. Those duplicates were made by older ABRT versions without good duplicate detection. ~900 bugs can be closed with this script. Hopefully it removes some burden from package maintainers.
[1] https://fedorahosted.org/abrt/browser/src/Backtrace/abrt-bz-dupchecker
Its 551 bugs that can be closed as duplicates, not 900. I placed the list of affected bugs to the Fedora wiki [3].
So I'd like to close over 600 bugs in Bugzilla using scripts. Is there some Fedora policy regulating this?
[1] https://fedorahosted.org/abrt/browser/scripts/abrt-bz-ratingfixer [2] https://fedoraproject.org/wiki/User:Kklic/ABRT_Incomplete_Backtraces [3] https://fedoraproject.org/wiki/User:Kklic/ABRT_Duplicates
Best Regards, Karel
Am Sonntag, den 07.02.2010, 22:26 +0100 schrieb Karel Klic:
The script to find backtraces without debuginfo has been written[1].
Thanks a lot for your work and for your latest mail as well!
I placed the list of found bugs to the Fedora wiki [2]. IMHO only bugs with 2 comments should be closed, because 2 comments mean that the package maintainer did not touch the bug (ABRT adds 2 comments to every bug it creates). We can close 129 bugs this way.
This means that the active maintainers, who responded to their reports and asked for more info will have no benefit from the script and the ones who ignored the abrt reports did right. Isn't it ironic?
[1] https://fedorahosted.org/abrt/browser/src/Backtrace/abrt-bz-dupchecker
Its 551 bugs that can be closed as duplicates, not 900. I placed the list of affected bugs to the Fedora wiki [3].
IMO all lists should be sorted by package owner. I own ~ 120 packages and it is a quite lot of work to search all these packages in your lists.
Regards, Christoph
On 02/08/2010 02:22 AM, Christoph Wickert wrote:
Am Sonntag, den 07.02.2010, 22:26 +0100 schrieb Karel Klic:
I placed the list of found bugs to the Fedora wiki [2]. IMHO only bugs with 2 comments should be closed, because 2 comments mean that the package maintainer did not touch the bug (ABRT adds 2 comments to every bug it creates). We can close 129 bugs this way.
This means that the active maintainers, who responded to their reports and asked for more info will have no benefit from the script and the ones who ignored the abrt reports did right. Isn't it ironic?
Yes, that is unfortunate. However, it is not polite to close a bug in the middle of some discussion. I can go through the remaining 80 bugs and close some of them manually.
[1] https://fedorahosted.org/abrt/browser/src/Backtrace/abrt-bz-dupchecker
Its 551 bugs that can be closed as duplicates, not 900. I placed the list of affected bugs to the Fedora wiki [3].
IMO all lists should be sorted by package owner. I own ~ 120 packages and it is a quite lot of work to search all these packages in your lists.
I'll try to do it.
Karel
On 02/08/2010 06:11 PM, Karel Klic wrote:
On 02/08/2010 02:22 AM, Christoph Wickert wrote:
Am Sonntag, den 07.02.2010, 22:26 +0100 schrieb Karel Klic: IMO all lists should be sorted by package owner. I own ~ 120 packages and it is a quite lot of work to search all these packages in your lists.
I'll try to do it.
Both lists are now sorted by package owner: https://fedoraproject.org/wiki/User:Kklic/ABRT_Duplicates https://fedoraproject.org/wiki/User:Kklic/ABRT_Incomplete_Backtraces
On Sun, 2010-02-07 at 22:26 +0100, Karel Klic wrote:
So I'd like to close over 600 bugs in Bugzilla using scripts. Is there some Fedora policy regulating this?
It would be best to contact the maintainer of RH Bugzilla, Dave Lawrence; he'll be able to advise you how to proceed.
I don't want to answer all of the messages, so I'll try to sum all of it in this one...
On 02/05/2010 09:46 PM, Christoph Wickert wrote:
What's wrong with ABRT? ALl the backtraces I get are unusable again. If Thunar crashes, not even Thunar-debuginfo gets installed.
abrt 1.0 worked here, then came 1.0.2 which was broken. 1.0.3 was working again, but got superseded be 1.0.4 only a few of days later. This means that most of the time, all the bugs submitted are basically useless.
Unfortunately that's true, it was different problem every time, but the result is the useless backtrace. This shouldn't happen anymore as we now have more extensive testing before releasing a new version.
For me as the maintainer it is a lot of work to reply to all these useless reports and for our users it's just frustrating if all their reports get closed INSUFFICIENT_DATA.
If the current situation is really so bad, we can auto-close all of the bugs reported by the broken versions of ABRT, because I guess they would just sit there until bugzapping period.
If the situation doesn't change any time soon, we IMHO should consider disabling abrt until the issues are fixed.
It's already fixed in 1.0.6, which sits in testing repo. In F12 there is a pending kernel update which (if gets to F12 without change) will prevent ABRT from detecting C/C++ apps crashes, so it will probably make abrt silent for a while.
Now some answers for issues mentioned in this thread:
ABRT doesn't work by design: - it actually does work, but it's bug detection/analyse is too general for some apps, this is something we know about and it's not in our powers to fix (it's not even considered a bug). This is actually the reason why is ABRT extendible by plugins and every devel who maintains some bigger app can write it's own abrt plugin to make the reports to suit his needs. If devel doesn't want to get ABRT reports at all, he can always send me an email and it can be added to ABRT blacklist.
I feel the Fedora community is being abused to evaluate a semi-functional piece of SW's "yet uncooked" concepts: - tha ABRT's concept is used for a while in other distros and ABRT itself is in Fedora since F10, but nobody cared to take a look at it and add some comments/ideas. I don't want to start a fight about non-finished apps in Fedora, but I won't silently ignore it, I remeber quite well the how finished and stable was the last major release of one of the major desktop environment or I remember times when I had to use web mail instead of my favourite client to write an email, because it wasn't stable (and both were in stable Fedora release).
Nice idea. IMO it should only allow to submit reports after some sanity checks: - ABRT uses the code from Dr.Konqui to rate the backtrace and doesn't allow user to send it if the rate is bellow 3 (the scale is 0-4), but the bug in GUI let user to send even the bad BT.
I believe ABRT shouldn't file a bug report unless it is filled in properly:
- we can change to GUI, so it won't let users fill a report without providing a steps to reproduce
History tells, low quality automated bug reports to be ignored and to cause a lot of bad blood. Debian for instance has an unfortunate history in doing so - You're better off to learn from their historic mistake: - times changes, Linux is now used by people who actually use it for work not for the "fun of using Linux" and these people doesn't want to spend time going thru bugzilla and filling some report. Yes, I agree we should learn and in this we should learn from someone more desktop oriented then Debian (maybe even from some non-Linux os??)
What needs to be fixed here is bugzilla not ABRT, we need a "report upstream" button: - the best would be to fix both. what we need to ease the life of maintainers is a middle layer between ABRT (users) and bugzilla(developers) something like mozilla has(http://crash-stats.mozilla.com/).
Surely you're not suggesting holding up a decent kernel from going to stable while waiting for Abrt ? - there is no need to wait for ABRT when talking about the pending kernel update update for F12, there is nothing what ABRT can do to work with that kernel.
Anyway, there should be a tool in ABRT suite, that allows a package maintainer to reconstruct a complete backtrace from an incomplete on, using only the list of involved packages, with there evr(+arch): - you can never get the whole BT without a coredump - you can get recreating should be a matter of a simple script and we can provide it as part of ABRT if devels would use it.
I hope I've cleared few things and will be happy to answer any of you further questions and RFEs.
Jirka
On Sun, Feb 7, 2010 at 6:16 AM, Jiri Moskovcak jmoskovc@redhat.com wrote:
- it actually does work, but it's bug detection/analyse is too general for
some apps, this is something we know about and it's not in our powers to fix (it's not even considered a bug). This is actually the reason why is ABRT extendible by plugins and every devel who maintains some bigger app can write it's own abrt plugin to make the reports to suit his needs. If devel doesn't want to get ABRT reports at all, he can always send me an email and it can be added to ABRT blacklist.
Where can information about the plugin API be found? The abrt-plugins man page has very little information. It basically just says to read PLUGINS-HOWTO "in the documentation directory". Which documentation directory is that? I don't see such a file in any of the abrt-* packages. (I expected to find it in abrt-devel, BTW. That package contains only 2 symlinks. Where are the header files? Are they not needed by plugin authors?)
Thanks,
On 02/08/2010 05:05 PM, Jerry James wrote:
On Sun, Feb 7, 2010 at 6:16 AM, Jiri Moskovcakjmoskovc@redhat.com wrote:
- it actually does work, but it's bug detection/analyse is too general for
some apps, this is something we know about and it's not in our powers to fix (it's not even considered a bug). This is actually the reason why is ABRT extendible by plugins and every devel who maintains some bigger app can write it's own abrt plugin to make the reports to suit his needs. If devel doesn't want to get ABRT reports at all, he can always send me an email and it can be added to ABRT blacklist.
Where can information about the plugin API be found? The abrt-plugins man page has very little information. It basically just says to read PLUGINS-HOWTO "in the documentation directory". Which documentation directory is that? I don't see such a file in any of the abrt-* packages. (I expected to find it in abrt-devel,
Yes, it should be in devel package, will fix this.
http://git.fedorahosted.org/git/abrt.git?p=abrt.git;a=blob_plain;f=doc/PLUGI...
BTW. That package contains only 2 symlinks. Where are the header files? Are they not needed by plugin authors?)
Good point, so far nobody wrote a plugin outside of abrt git, so the devel package wasn't actually never used :-/ I will add the required .h files into the package and it will be fixed in 1.0.7. Until it's fixed in rpm, you can download and hack the code using our git from here:
https://fedorahosted.org/abrt/wiki/AbrtInstallation
Jirka
On Sun, 2010-02-07 at 14:16 +0100, Jiri Moskovcak wrote:
because I guess they would just sit there until bugzapping period.
There's no 'bugzapping period', exactly. BugZappers work all the time, but only on a small subset of all Fedora packages, we simply do not have the manpower to cover all of them. So for the many packages which are not covered by Bugzappers, reports just sit there until the maintainer chooses to deal with them, or they get killed due to the release for which they were filed going EOL.
On 02/09/2010 04:17 AM, Adam Williamson wrote:
On Sun, 2010-02-07 at 14:16 +0100, Jiri Moskovcak wrote:
because I guess they would just sit there until bugzapping period.
or they get killed due to the release for which they were filed going EOL.
That's what I meant :)
J.
On Tue, 2010-02-09 at 09:42 +0100, Jiri Moskovcak wrote:
On 02/09/2010 04:17 AM, Adam Williamson wrote:
On Sun, 2010-02-07 at 14:16 +0100, Jiri Moskovcak wrote:
because I guess they would just sit there until bugzapping period.
or they get killed due to the release for which they were filed going EOL.
That's what I meant :)
ahh. doh. /me feels silly :)
Am Sonntag, den 07.02.2010, 14:16 +0100 schrieb Jiri Moskovcak:
- ABRT uses the code from Dr.Konqui to rate the backtrace and doesn't
allow user to send it if the rate is bellow 3 (the scale is 0-4), but the bug in GUI let user to send even the bad BT.
I think this bug should be fixed now in 1.0.6, but the rating doesn't work. A backtrace with no debuginfo was rated 3 (while it should be 0 I guess).
https://bugzilla.redhat.com/show_bug.cgi?id=565387
Regards, Christoph