hi!
This is something I got in my mail box today. As I don't have a valid answer for this, maybe someone else can answer for me?
cheers, Bert
the url of the blog of the guy: http://www.krisbuytaert.be/blog/
== the mail ==
Dear Fedoracommunity,
Over the course of the day I recieved 22^3 mails from your friendly Bug Zapper. Most of those bugs where bugs I had reported upon crashes using bug-buddy. Bugs on different desktop tools such as .. synergy, evolution, gwibber , gnome-settings and probably some others
I do understand that I development goes on and on .. and your fancy devs don't care anymore about bugs I reported on Fedora 12 as they are all hacking on Fedora 15.
But what I don't get is that non of these bugs was ever touched, they've been automatically created , and automatically closed
<a href="http://tieguy.org/blog/2004/09/">Luis</a> already told us ages ago .. that every project needs a bugmaster apparently Fedora replaced that bugmaster with a Bug Zapper.
So can someone please explain my why I should continue to try to improve Fedora by reporting bugs ?
On Wed, Nov 3, 2010 at 4:41 PM, Bert Desmet wrote:
hi!
This is something I got in my mail box today. As I don't have a valid answer for this, maybe someone else can answer for me?
cheers, Bert
the url of the blog of the guy: http://www.krisbuytaert.be/blog/
== the mail ==
Dear Fedoracommunity,
Over the course of the day I recieved 22^3 mails from your friendly Bug Zapper. Most of those bugs where bugs I had reported upon crashes using bug-buddy. Bugs on different desktop tools such as .. synergy, evolution, gwibber , gnome-settings and probably some others
I do understand that I development goes on and on .. and your fancy devs don't care anymore about bugs I reported on Fedora 12 as they are all hacking on Fedora 15.
But what I don't get is that non of these bugs was ever touched, they've been automatically created , and automatically closed
<a href="http://tieguy.org/blog/2004/09/">Luis</a> already told us ages ago .. that every project needs a bugmaster apparently Fedora replaced that bugmaster with a Bug Zapper.
So can someone please explain my why I should continue to try to improve Fedora by reporting bugs ?
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is.
From what I have seen, the maintainers are more responsive to manually
filed bugs than to ABRT filed bugs (Am I wrong?). Apparently the current setup is driving users (such as the person in the above email) away who are otherwise willing to report bugs. This is not good.
What can we do to make it better? Some ideas:
1. - ABRT stops reporting new bugs to Fedora. - The user does a self evaluation: Is the bugcoding related, or packaging related? - If he thinks the bug is packaging related, or if he's not sure, he manually files a bug to Fedora bugzilla. Otherwise he notifies the developers. - The package maintainer asks for a backtrace - User reproduces the crash, and puts the bug number in ABRT gui. ABRT posts the backtrace to the bug report as an attachment. - If the bug is coding related, the package maintainer can direct the user to the developers.
2. There can be a checkbox in pkgdb for maintainers to turn off ABRT bug reporting for their packages.
3. ?
Orcan
On Wed, 2010-11-03 at 21:02 -0400, Orcan Ogetbil wrote:
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is.
I disagree. I have seen many bugs fixed with the aid of abrt feedback. It beats the hell out of a bug report which says 'it crashed'.
From what I have seen, the maintainers are more responsive to manually filed bugs than to ABRT filed bugs (Am I wrong?). Apparently the current setup is driving users (such as the person in the above email) away who are otherwise willing to report bugs. This is not good.
What can we do to make it better? Some ideas:
- ABRT stops reporting new bugs to Fedora.
- The user does a self evaluation: Is the bugcoding related, or
packaging related?
- If he thinks the bug is packaging related, or if he's not sure, he
manually files a bug to Fedora bugzilla. Otherwise he notifies the developers.
- The package maintainer asks for a backtrace
- User reproduces the crash, and puts the bug number in ABRT gui. ABRT
posts the backtrace to the bug report as an attachment.
- If the bug is coding related, the package maintainer can direct the
user to the developers.
This is not practical. Users are not in a position to know whether the crash is in downstream or upstream code.
There can be a checkbox in pkgdb for maintainers to turn off ABRT bug reporting for their packages.
This seems reasonable, for packagers who are not in a position to act on such reports, but then, that's not a great position for a packager to be in; for instance, I'm a packager who can't code so these reports are of fairly limited value to me directly, but they would at least give me good data to pass to the upstream coders of any package I own.
On Wed, Nov 3, 2010 at 9:55 PM, Adam Williamson wrote:
On Wed, 2010-11-03 at 21:02 -0400, Orcan Ogetbil wrote:
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is.
I disagree. I have seen many bugs fixed with the aid of abrt feedback. It beats the hell out of a bug report which says 'it crashed'.
Does it compare to this number? (it takes a while to open)
From what I have seen, the maintainers are more responsive to manually filed bugs than to ABRT filed bugs (Am I wrong?). Apparently the current setup is driving users (such as the person in the above email) away who are otherwise willing to report bugs. This is not good.
What can we do to make it better? Some ideas:
- ABRT stops reporting new bugs to Fedora.
- The user does a self evaluation: Is the bugcoding related, or
packaging related?
- If he thinks the bug is packaging related, or if he's not sure, he
manually files a bug to Fedora bugzilla. Otherwise he notifies the developers.
- The package maintainer asks for a backtrace
- User reproduces the crash, and puts the bug number in ABRT gui. ABRT
posts the backtrace to the bug report as an attachment.
- If the bug is coding related, the package maintainer can direct the
user to the developers.
Hence I added "if he's not sure". Please read again.
This is not practical. Users are not in a position to know whether the crash is in downstream or upstream code.
There can be a checkbox in pkgdb for maintainers to turn off ABRT bug reporting for their packages.
This seems reasonable, for packagers who are not in a position to act on such reports, but then, that's not a great position for a packager to be in; for instance, I'm a packager who can't code so these reports are of fairly limited value to me directly, but they would at least give me good data to pass to the upstream coders of any package I own.
I played the middle man in some of the bug reports. The user did not seem to want to contact the developer directly. The upstream asked for something, and I forwarded it to the user. This went back and forth a couple times until I realized that this was highly inefficient, and mostly a waste of time (since one of the parties gave up eventually). There's got to be a better way.
Orcan
On Wed, 2010-11-03 at 22:12 -0400, Orcan Ogetbil wrote:
On Wed, Nov 3, 2010 at 9:55 PM, Adam Williamson wrote:
On Wed, 2010-11-03 at 21:02 -0400, Orcan Ogetbil wrote:
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is.
I disagree. I have seen many bugs fixed with the aid of abrt feedback. It beats the hell out of a bug report which says 'it crashed'.
Does it compare to this number? (it takes a while to open)
Not hard to run the numbers. There've been 31,603 bugs reported to Bugzilla by abrt. There are 2,216 bugs reported by abrt that have been closed as CURRENTRELEASE, RAWHIDE, ERRATA or NEXTRELEASE (which are the resolutions that usually imply 'it got fixed'). I think a tool that's resulted in 2,216 fixes for crasher bugs is pretty cool. :)
(I just searched for bugs with [abrt] in the subject reported against Fedora, which gives the 31,603 total, then ran the same search but with the above resolution restrictions).
From what I have seen, the maintainers are more responsive to manually filed bugs than to ABRT filed bugs (Am I wrong?). Apparently the current setup is driving users (such as the person in the above email) away who are otherwise willing to report bugs. This is not good.
What can we do to make it better? Some ideas:
- ABRT stops reporting new bugs to Fedora.
- The user does a self evaluation: Is the bugcoding related, or
packaging related?
- If he thinks the bug is packaging related, or if he's not sure, he
manually files a bug to Fedora bugzilla. Otherwise he notifies the developers.
- The package maintainer asks for a backtrace
- User reproduces the crash, and puts the bug number in ABRT gui. ABRT
posts the backtrace to the bug report as an attachment.
- If the bug is coding related, the package maintainer can direct the
user to the developers.
Hence I added "if he's not sure". Please read again.
My point is that you may as well not bother with the cases where the user is sure, because they'll be very rare, and such users will know what to do anyway.
This is not practical. Users are not in a position to know whether the crash is in downstream or upstream code.
There can be a checkbox in pkgdb for maintainers to turn off ABRT bug reporting for their packages.
This seems reasonable, for packagers who are not in a position to act on such reports, but then, that's not a great position for a packager to be in; for instance, I'm a packager who can't code so these reports are of fairly limited value to me directly, but they would at least give me good data to pass to the upstream coders of any package I own.
I played the middle man in some of the bug reports. The user did not seem to want to contact the developer directly. The upstream asked for something, and I forwarded it to the user. This went back and forth a couple times until I realized that this was highly inefficient, and mostly a waste of time (since one of the parties gave up eventually). There's got to be a better way.
I'm not sure there is. Implementing a whole separate system for abrt to report to is essentially just institutionalizing the middle-man. But hey, if we go that way, fine. It's worth noting, though, that we're not short of proposals for implementing an intermediary system for abrt, we've already had one for a while. We're short on people *writing* the intermediary system.
On Wed, Nov 3, 2010 at 10:59 PM, Adam Williamson wrote:
On Wed, 2010-11-03 at 22:12 -0400, Orcan Ogetbil wrote:
On Wed, Nov 3, 2010 at 9:55 PM, Adam Williamson wrote:
On Wed, 2010-11-03 at 21:02 -0400, Orcan Ogetbil wrote:
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is.
I disagree. I have seen many bugs fixed with the aid of abrt feedback. It beats the hell out of a bug report which says 'it crashed'.
Does it compare to this number? (it takes a while to open)
Not hard to run the numbers. There've been 31,603 bugs reported to Bugzilla by abrt. There are 2,216 bugs reported by abrt that have been closed as CURRENTRELEASE, RAWHIDE, ERRATA or NEXTRELEASE (which are the resolutions that usually imply 'it got fixed'). I think a tool that's resulted in 2,216 fixes for crasher bugs is pretty cool. :)
I am pretty sure a subset of these closed bugs are "mass-closing" of bugs when a maintainer updates the software. Sometimes, when you forward the report upstream, they don't understand the output either, and say "it may be fixed, just update and try". You update the software, put it to testing, and ask the user if it is fixed for him. The user doesn't respond as usual. Then you mark it as fixed without really knowing what's going on. Then you have such statistics. YAY!
Orcan
On Wed, Nov 3, 2010 at 11:10 PM, Orcan Ogetbil wrote:
On Wed, Nov 3, 2010 at 10:59 PM, Adam Williamson wrote:
On Wed, 2010-11-03 at 22:12 -0400, Orcan Ogetbil wrote:
On Wed, Nov 3, 2010 at 9:55 PM, Adam Williamson wrote:
On Wed, 2010-11-03 at 21:02 -0400, Orcan Ogetbil wrote:
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is.
I disagree. I have seen many bugs fixed with the aid of abrt feedback. It beats the hell out of a bug report which says 'it crashed'.
Does it compare to this number? (it takes a while to open)
Not hard to run the numbers. There've been 31,603 bugs reported to Bugzilla by abrt. There are 2,216 bugs reported by abrt that have been closed as CURRENTRELEASE, RAWHIDE, ERRATA or NEXTRELEASE (which are the resolutions that usually imply 'it got fixed'). I think a tool that's resulted in 2,216 fixes for crasher bugs is pretty cool. :)
I am pretty sure a subset of these closed bugs are "mass-closing" of bugs when a maintainer updates the software. Sometimes, when you forward the report upstream, they don't understand the output either, and say "it may be fixed, just update and try". You update the software, put it to testing, and ask the user if it is fixed for him. The user doesn't respond as usual. Then you mark it as fixed without really knowing what's going on. Then you have such statistics. YAY!
I randomly picked 20 bug reports out of those 2,216 that were closed CURRENTRELEASE, RAWHIDE, ERRATA or NEXTRELEASE.
1 had the software patched, and updated (Good fix) 2 had some sort of discussion (1-2 messages) before the maintainer updates the software and marks it fixed 17 had no conversation at all. The maintainer just updates the software to the next version.
Of course some of these might be real fixes. I didn't look deeply into it.
However, believing that these bugs are "fixed" thanks to the ABRT reports sounds to me like wishful thinking.
Orcan
On 11/04/2010 03:59 AM, Adam Williamson wrote:
On Wed, 2010-11-03 at 22:12 -0400, Orcan Ogetbil wrote:
On Wed, Nov 3, 2010 at 9:55 PM, Adam Williamson wrote:
On Wed, 2010-11-03 at 21:02 -0400, Orcan Ogetbil wrote:
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is.
I disagree. I have seen many bugs fixed with the aid of abrt feedback. It beats the hell out of a bug report which says 'it crashed'.
Does it compare to this number? (it takes a while to open)
Not hard to run the numbers. There've been 31,603 bugs reported to Bugzilla by abrt. There are 2,216 bugs reported by abrt that have been closed as CURRENTRELEASE, RAWHIDE, ERRATA or NEXTRELEASE (which are the resolutions that usually imply 'it got fixed'). I think a tool that's resulted in 2,216 fixes for crasher bugs is pretty cool. :)
2216/31603 = 7%
With all due respect, to me, this qualifies as ineffective, esp when considering the communicational overhead/noise attached to them.
IMO, the more interesting figure would be
* How many of these fixed bugs would not have been fixed if abrt wasn't around. My (wild) guess is, not much more, because serious and reproduceable bugs would have been manually reported in any case.
* How many of the "unfixed bugs" remained unfixed because abrt's reports are not reporting sufficient information to allow maintainers to investigate. As far as the packages I am maintaining are concerned, I haven't been able to fix any bug in my packages due to abrt reports. As far as I as a user am concerned, none of the bugs I had reported via abrt was fixed. In both cases, however I am experiencing the noise abrt causes.
Ralf
On 11/3/2010 7:02 PM, Orcan Ogetbil wrote:
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is. Orcan
Of the 28 abrt bugs filed against my packages, I think 1 resulted in a real fix that I needed to apply as a packager. Another was fixed by an update. The rest are piling up. I don't have the time to fix them myself. I rarely get any response to my requests for more info (5 are in needinfo). I haven't been able to get upstream to involved. I'm seriously considering orphaning pdfedit (14 bugs) over this.
0rion
On Wed, 2010-11-03 at 21:58 -0600, Orion Poplawski wrote:
On 11/3/2010 7:02 PM, Orcan Ogetbil wrote:
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is. Orcan
Of the 28 abrt bugs filed against my packages, I think 1 resulted in a real fix that I needed to apply as a packager. Another was fixed by an update. The rest are piling up. I don't have the time to fix them myself. I rarely get any response to my requests for more info (5 are in needinfo). I haven't been able to get upstream to involved. I'm seriously considering orphaning pdfedit (14 bugs) over this.
My question would be 'why'? There seems to be an assumption that an open bug report you can't fix is a serious problem; of course in a sense it is, but then, it's not as if, if we remove or otherwise change abrt, software is going to magically stop crashing. It's going to crash just as much. There just won't be bug reports associated with the crashes. I guess what I'm asking is what actual harm/damage are these reports causing, beyond the time it takes to look at the report and figure out whether you can fix it? Why is the fact that people have experienced crashes you haven't yet figured out how to fix a reason to stop maintaining the software?
On 11/03/2010 11:05 PM, Adam Williamson wrote:
On Wed, 2010-11-03 at 21:58 -0600, Orion Poplawski wrote:
On 11/3/2010 7:02 PM, Orcan Ogetbil wrote:
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is. Orcan
Of the 28 abrt bugs filed against my packages, I think 1 resulted in a real fix that I needed to apply as a packager. Another was fixed by an update. The rest are piling up. I don't have the time to fix them myself. I rarely get any response to my requests for more info (5 are in needinfo). I haven't been able to get upstream to involved. I'm seriously considering orphaning pdfedit (14 bugs) over this.
My question would be 'why'? There seems to be an assumption that an open bug report you can't fix is a serious problem; of course in a sense it is, but then, it's not as if, if we remove or otherwise change abrt, software is going to magically stop crashing. It's going to crash just as much. There just won't be bug reports associated with the crashes. I guess what I'm asking is what actual harm/damage are these reports causing, beyond the time it takes to look at the report and figure out whether you can fix it? Why is the fact that people have experienced crashes you haven't yet figured out how to fix a reason to stop maintaining the software?
If I can weigh in. First off, I have no preference in this and can see validity in both sides, but I'll share my impressions.
Prior to the introduction of abrt I started wanting to get more involved. At the time I wasn't sure, and was talking with a friend who felt the same. After awhile we figured that one way is to report bugs/ or annoyances and help get them fixed in whatever way we could. Soon after that abrt arrived. I started using abrt and filing bugs very much willing to help in their triage, analysis and testing. I should add that I also file bugs when it isn't a crash, but something I consider a bug...
Its been somewhat a disappointing experience. Not because of the % of the bugs fixed, but because of the % response. I'm not sure if any of my bugs have been responded to. There are probably one or two. I've been annoyed that some of the bugs are getting many many CC's added to them (or the ones I've been added to), but no response. I completely realize this is a matter of man power so am in no way complaining. However from my perspective, the question is, do I even bother? In some cases now I'm not reporting the abrt detected crashes if its in something I figure won't get much attention, or I have no idea how it happened. For example I had a handful of Firefox crashing mysteriously. I wasn't even *using* it when it crashed. If it wasn't for abrt I may not have even noticed. Now, if FF crashes I rarely report it. I imagine its because I know they must be getting inundated with these types of reports, and how can they know I'm willing to help any more than the other thousand of reports. They can't... However from my perspective as one who files bugs, its less valuable as I don't see things I report being fixed so why report. It also lets me know how many things are crashing on my systems. I used to feel linux was more stable, and in some senses it is, however now I am starting to see more and more crashes that may have been happening all along but I didn't know. So I'm not as naive anymore I guess.
I have to say, I have since become a packager and involved in other ways... and would like to become more involved but won't have more time for another 14 months.
Just some thoughts...
Just a followup thought... I wonder if abrt could be made smarter / changed to allow for a preference setting to report on updates-testing or all updates... I know awhile back I made suggestions on what it would take in my mind to increase user testing [1]. I see abrt as another way to help increase the quality of Fedora. In its current state it is likely flooding developers and as such less effective than it could be. Just some thoughts...
[1] http://lists.fedoraproject.org/pipermail/devel/2010-June/138077.html
2010/11/4 Orcan Ogetbil oget.fedora@gmail.com:
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is.
No need to discuss - it's really useful. I recently closed several issues with the aid of stacktaces sent by ABRT.
On Thu, Nov 4, 2010 at 1:05 AM, Adam Williamson wrote:
I guess what I'm asking is what actual harm/damage are these reports causing, beyond the time it takes to look at the report and figure out whether you can fix it? Why is the fact that people have experienced crashes you haven't yet figured out how to fix a reason to stop maintaining the software?
Well, since you start with "beyond the time it takes to look", I guess that the time it takes to look won't be enough of an argument to put on the table. Then I won't have anything else to say. For me that is all that matters. Actually that is all that I give to Fedora: time.
The question is Am I using the time efficiently? OR Are the these tools actually preventing me to be efficient during my available time?
Orcan
On Thu, 2010-11-04 at 02:15 -0400, Orcan Ogetbil wrote:
On Thu, Nov 4, 2010 at 1:05 AM, Adam Williamson wrote:
I guess what I'm asking is what actual harm/damage are these reports causing, beyond the time it takes to look at the report and figure out whether you can fix it? Why is the fact that people have experienced crashes you haven't yet figured out how to fix a reason to stop maintaining the software?
Well, since you start with "beyond the time it takes to look", I guess that the time it takes to look won't be enough of an argument to put on the table. Then I won't have anything else to say. For me that is all that matters. Actually that is all that I give to Fedora: time.
The question is Am I using the time efficiently? OR Are the these tools actually preventing me to be efficient during my available time?
Well, it seems to me that your proposal basically involves sticking several artificial barriers in the process of filing crash reports to Bugzilla in the hopes that we'll get fewer of them, and also trying to get reports upstream by the initial reporters...which doesn't really remove the time requirement, just dumps it on someone else (upstream).
I don't know, it just seems like the case where, when something crashes, we catch the fact of the crash and the most useful data about it (backtrace) and put it somewhere is better than the case where, when something crashes, we don't do that. Even if we go with a system where there's some kind of intermediary place for abrt reports to go, *someone* is going to have to invest in the time to look at them. And I'm not sure that introducing barriers to reporting just to try and get fewer people to report crashes makes a whole lot of sense either.
On 11/04/2010 07:15 AM, Orcan Ogetbil wrote:
On Thu, Nov 4, 2010 at 1:05 AM, Adam Williamson wrote:
I guess what I'm asking is what actual harm/damage are these reports causing, beyond the time it takes to look at the report and figure out whether you can fix it? Why is the fact that people have experienced crashes you haven't yet figured out how to fix a reason to stop maintaining the software?
Well, since you start with "beyond the time it takes to look", I guess that the time it takes to look won't be enough of an argument to put on the table. Then I won't have anything else to say. For me that is all that matters. Actually that is all that I give to Fedora: time.
The question is Am I using the time efficiently? OR Are the these tools actually preventing me to be efficient during my available time?
As a user wanting to report a bug, abrt is both.
On one hand it's a systematic way to report bugs, on the other hand it forces me download debug packages and to struggle with its GUI. Considering the facts that downloading 100MBs of debug-packages may not always be applicable (E.g. when not having broadband access), that abrt not always manages to correctly handle debug-infos, this costs.
That said, I repeatedly ended up with "deleting" abrt notifications and to ignore it.
As a maintainer, abrt to me primarily means "wading through wakes of hardly readable emails", mostly to scan them for useful information. I many cases I ended up with closing BZ, because these emails did not contain sufficient info.
That said, as a maintainer, abrt to me only has introduced a higher noise/signal ratio in bugreports as before.
Ralf
On Thu, 2010-11-04 at 07:41 +0100, Ralf Corsepius wrote:
The question is Am I using the time efficiently? OR Are the these tools actually preventing me to be efficient during my available time?
As a user wanting to report a bug, abrt is both.
On one hand it's a systematic way to report bugs, on the other hand it forces me download debug packages and to struggle with its GUI. Considering the facts that downloading 100MBs of debug-packages may not always be applicable (E.g. when not having broadband access), that abrt not always manages to correctly handle debug-infos, this costs.
That said, I repeatedly ended up with "deleting" abrt notifications and to ignore it.
This is another thing where we don't have any trouble identifying the problem and the solution. Will Woods has had the debuginfofs system sketched out for years to deal with this. What he doesn't have is the time to write it (since he's busy with AutoQA). Anyone else could do it instead, though.
As a maintainer, abrt to me primarily means "wading through wakes of hardly readable emails", mostly to scan them for useful information. I many cases I ended up with closing BZ, because these emails did not contain sufficient info.
That said, as a maintainer, abrt to me only has introduced a higher noise/signal ratio in bugreports as before.
I'm not sure SNR is the be-all and end-all, really. Fixing crasher bugs is surely an inherently desirable thing, even if it *does* add work examining the reports.
On Thu, Nov 4, 2010 at 2:28 AM, Adam Williamson wrote:
On Thu, 2010-11-04 at 02:15 -0400, Orcan Ogetbil wrote:
On Thu, Nov 4, 2010 at 1:05 AM, Adam Williamson wrote:
I guess what I'm asking is what actual harm/damage are these reports causing, beyond the time it takes to look at the report and figure out whether you can fix it? Why is the fact that people have experienced crashes you haven't yet figured out how to fix a reason to stop maintaining the software?
Well, since you start with "beyond the time it takes to look", I guess that the time it takes to look won't be enough of an argument to put on the table. Then I won't have anything else to say. For me that is all that matters. Actually that is all that I give to Fedora: time.
The question is Am I using the time efficiently? OR Are the these tools actually preventing me to be efficient during my available time?
Well, it seems to me that your proposal basically involves sticking several artificial barriers in the process of filing crash reports to Bugzilla in the hopes that we'll get fewer of them, and also trying to get reports upstream by the initial reporters...which doesn't really remove the time requirement, just dumps it on someone else (upstream).
Correct. We shouldn't miss the fact that it takes less time to process the backtraces if we wrote the code ourselves.
For a bug that I can reproduce, the time it takes for me to fix it might be comparable to the time it takes me to report it upstream and get it fixed there.
The extreme inefficiency comes from the bugs that I can't reproduce, the upstream can't reproduce, and the user isn't responding. And this happens *a lot*. Most of the time, they don't even put down the steps to reproduce. Can we at least mandate including the steps to reproduce in the ABRT reports?
Orcan
On 11/04/2010 07:55 AM, Adam Williamson wrote:
On Thu, 2010-11-04 at 07:41 +0100, Ralf Corsepius wrote:
I'm not sure SNR is the be-all and end-all, really.
When it comes to efficiency, it is.
In other words, as far as I am concerned, abrt has reduced efficiency of bug-hunting by flooding maintainers with low quality, often unusable reports and risen the communication churn related to BZs.
Conversely, a similar consideration applies to the user side: abrt has lowered the threshold to report bugs and risen the expectations on report bugs responses.
Fixing crasher bugs is surely an inherently desirable thing, even if it *does* add work examining the reports.
As I tried to express before, "serious crashers" likely would also have been reported without abrt. I seriously question, abrt has much helpful impact on reports related to "crashers".
It's the "nagging"/"non-crasher" class of bugs, which is really reducing the "user-experience" of Fedora, exactly the class of bugs "abrt" is not designed to to not cover.
Ralf
As far as I understand the process you might just recheck your bug report against last official release and bump version in the corresponding field if the bug is still reproducible.
Otherwise, no-one is interested to improve 2-3years old _desktop_ system.
On Wed, Nov 3, 2010 at 10:41 PM, Bert Desmet bert@devnox.be wrote:
hi!
This is something I got in my mail box today. As I don't have a valid answer for this, maybe someone else can answer for me?
cheers, Bert
the url of the blog of the guy: http://www.krisbuytaert.be/blog/
== the mail ==
Dear Fedoracommunity,
Over the course of the day I recieved 22^3 mails from your friendly Bug Zapper. Most of those bugs where bugs I had reported upon crashes using bug-buddy. Bugs on different desktop tools such as .. synergy, evolution, gwibber , gnome-settings and probably some others
I do understand that I development goes on and on .. and your fancy devs don't care anymore about bugs I reported on Fedora 12 as they are all hacking on Fedora 15.
But what I don't get is that non of these bugs was ever touched, they've been automatically created , and automatically closed
<a href="http://tieguy.org/blog/2004/09/">Luis</a> already told us ages ago .. that every project needs a bugmaster apparently Fedora replaced that bugmaster with a Bug Zapper.
So can someone please explain my why I should continue to try to improve Fedora by reporting bugs ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 04/11/10 04:23, Orcan Ogetbil wrote:
On Wed, Nov 3, 2010 at 11:10 PM, Orcan Ogetbil wrote:
On Wed, Nov 3, 2010 at 10:59 PM, Adam Williamson wrote:
On Wed, 2010-11-03 at 22:12 -0400, Orcan Ogetbil wrote:
On Wed, Nov 3, 2010 at 9:55 PM, Adam Williamson wrote:
On Wed, 2010-11-03 at 21:02 -0400, Orcan Ogetbil wrote:
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is.
I disagree. I have seen many bugs fixed with the aid of abrt feedback. It beats the hell out of a bug report which says 'it crashed'.
Does it compare to this number? (it takes a while to open)
Not hard to run the numbers. There've been 31,603 bugs reported to Bugzilla by abrt. There are 2,216 bugs reported by abrt that have been closed as CURRENTRELEASE, RAWHIDE, ERRATA or NEXTRELEASE (which are the resolutions that usually imply 'it got fixed'). I think a tool that's resulted in 2,216 fixes for crasher bugs is pretty cool. :)
I am pretty sure a subset of these closed bugs are "mass-closing" of bugs when a maintainer updates the software. Sometimes, when you forward the report upstream, they don't understand the output either, and say "it may be fixed, just update and try". You update the software, put it to testing, and ask the user if it is fixed for him. The user doesn't respond as usual. Then you mark it as fixed without really knowing what's going on. Then you have such statistics. YAY!
I randomly picked 20 bug reports out of those 2,216 that were closed CURRENTRELEASE, RAWHIDE, ERRATA or NEXTRELEASE.
1 had the software patched, and updated (Good fix) 2 had some sort of discussion (1-2 messages) before the maintainer updates the software and marks it fixed 17 had no conversation at all. The maintainer just updates the software to the next version.
Of course some of these might be real fixes. I didn't look deeply into it.
However, believing that these bugs are "fixed" thanks to the ABRT reports sounds to me like wishful thinking.
Orcan
I am aware of at least two bugs filed from me via abrt, which were fixed because of the report. I'm pretty sure, I did not file hundreds or thousands of abrt-reports. Maybe your perspective is a bit too negative.
Matthias
* Orcan Ogetbil [04/11/2010 09:35] :
The extreme inefficiency comes from the bugs that I can't reproduce, the upstream can't reproduce, and the user isn't responding. And this happens *a lot*. Most of the time, they don't even put down the steps to reproduce. Can we at least mandate including the steps to reproduce in the ABRT reports?
Is there any reason you can't close these bugs with a INSUFFICIENT_DATA resolution? This seems to be the most appropriate thing to do in this case.
Emmanuel
On 04/11/10 06:56, Orcan Ogetbil wrote:
For a bug that I can reproduce, the time it takes for me to fix it might be comparable to the time it takes me to report it upstream and get it fixed there.
Maybe not something all users can do, write code? Should not be a barrier to using Linux, Fedora in particular.
The extreme inefficiency comes from the bugs that I can't reproduce, the upstream can't reproduce, and the user isn't responding. And this happens *a lot*.
Tell them so, ask them to go on the test list, user list: "Has X happended to you, bug ref soem url.
Most of the time, they don't even put down the steps
to reproduce. Can we at least mandate including the steps to reproduce in the ABRT reports?
In many cases it may not be known by the user, booted up, there was a bug waiting for me in the abrt icon.
Removing abrt, does not preclude the bug from happening, only the users knowledge that it happened.
Sent by a general user (learning some code).
On Thu, Nov 04, 2010 at 02:15:30AM -0400, Orcan Ogetbil wrote:
The question is Am I using the time efficiently? OR Are the these tools actually preventing me to be efficient during my available time?
Wasn't there some way for a maintainer to opt out of abrt?
I remember seeing this being discussed but cannot find how to do it on the abrt trac or in the man-pages.
Was it just a plan? Is it not wanted?
On Wed, 3 Nov 2010 23:10:54 -0400 Orcan Ogetbil oget.fedora@gmail.com wrote:
I am pretty sure a subset of these closed bugs are "mass-closing" of bugs when a maintainer updates the software. Sometimes, when you forward the report upstream, they don't understand the output either, and say "it may be fixed, just update and try". You update the software, put it to testing, and ask the user if it is fixed for him. The user doesn't respond as usual. Then you mark it as fixed without really knowing what's going on. Then you have such statistics. YAY!
If you as a maintainer close it as fixed instead of 'insufficient data' then you are at fault. I never close as fixed unless I have confirmation (or I know because i tested/fixed myself).
Simo.
On Wed, 3 Nov 2010 21:41:22 +0100, Bert wrote:
hi!
This is something I got in my mail box today. As I don't have a valid answer for this, maybe someone else can answer for me?
cheers, Bert
the url of the blog of the guy: http://www.krisbuytaert.be/blog/
== the mail ==
Dear Fedoracommunity,
Over the course of the day I recieved 22^3 mails from your friendly Bug Zapper. Most of those bugs where bugs I had reported upon crashes using bug-buddy. Bugs on different desktop tools such as .. synergy, evolution, gwibber , gnome-settings and probably some others
I do understand that I development goes on and on .. and your fancy devs don't care anymore about bugs I reported on Fedora 12 as they are all hacking on Fedora 15.
But what I don't get is that non of these bugs was ever touched, they've been automatically created , and automatically closed
Some packagers just don't respond. Not even for packaging mistakes. :(
<a href="http://tieguy.org/blog/2004/09/">Luis</a> already told us ages ago .. that every project needs a bugmaster apparently Fedora replaced that bugmaster with a Bug Zapper.
So can someone please explain my why I should continue to try to improve Fedora by reporting bugs ?
Glad you ask this. The bugzapping script is stupid. It asks the reporter for NEEDINFO when in fact it ought to ask WTF has the packager not responded since Fedora 12?
Am Donnerstag, den 04.11.2010, 02:15 -0400 schrieb Orcan Ogetbil:
The question is Am I using the time efficiently? OR Are the these tools actually preventing me to be efficient during my available time?
How would they? You can ignore all bug reports, you can even set up a mail filter to not see them. Costs no time, so it is very efficient.
IMHO ABRT is just an offer. It depends on you what you make of it. I can only encourage maintainers to care about ABRT bugs and push everything upstream, even if it might be frustrating due to the lack of feedback from both the developers and the reporters.
Regards, Christoph
Am Donnerstag, den 04.11.2010, 12:18 +0100 schrieb Sven Lankes:
On Thu, Nov 04, 2010 at 02:15:30AM -0400, Orcan Ogetbil wrote:
The question is Am I using the time efficiently? OR Are the these tools actually preventing me to be efficient during my available time?
Wasn't there some way for a maintainer to opt out of abrt?
I remember seeing this being discussed but cannot find how to do it on the abrt trac or in the man-pages.
Was it just a plan? Is it not wanted?
How would you do that? A popup in ABRT that reads
"Sorry, but the maintainer of this package has decided to not accept any bug reports."
I think this would be a *really* bad user experience.
Regards, Christoph
Am Donnerstag, den 04.11.2010, 13:28 +0100 schrieb Michael Schwendt:
On Wed, 3 Nov 2010 21:41:22 +0100, Bert wrote:
So can someone please explain my why I should continue to try to improve Fedora by reporting bugs ?
Glad you ask this. The bugzapping script is stupid. It asks the reporter for NEEDINFO when in fact it ought to ask WTF has the packager not responded since Fedora 12?
+ 100!
Regards, Christoph
Hi, some possitive news from me first: We have a new backtrace parser which should be able to find the duplicates much better (tested on every known dupes reported by ABRT so far) so at least the number of dupes should lower once this out (we're having some troubles with SELinux so it didn't make it to the repos before F14 :( )
...and for the rest I'll try to answer as much as I can, so here we go:
Q: How many of these fixed bugs would not have been fixed if abrt wasn't around. My (wild) guess is, not much more, because serious and reproduceable bugs would have been manually reported in any case.
A: Hm, maybe even more interesting figures would be how long would it take until it's reported for the first time, so how soon the devel would be notified about the crash...
Q: How many of the "unfixed bugs" remained unfixed because abrt's reports are not reporting sufficient information to allow maintainers to investigate.
A: I don't understand this, if the bug is reproducible then a lot of users will sooner or later hit it, so someone will provide more info.. If it's just one occurence and the reporter is not responsive, then the bug probably doesn't bother him or anyone else anymore, so it's safe to let the bugzapper to close it (or do it manually as INSUFF_DATA)
Q: As far as the packages I am maintaining are concerned, I haven't been able to fix any bug in my packages due to abrt reports.
A: That's unfortunate, as ABRT's main idea is to provide such information, please send me an email which data you're missing and we will add it to the ABRT report (if it can be gathered automatically) or I can just add it to blacklist if ABRT is not able to provide such informations.
Q: As far as I as a user am concerned, none of the bugs I had reported via abrt was fixed.
A: If you filled a good report (which I have no doubt you did!) then it's the packager to blame not ABRT.
Q: Of the 28 abrt bugs filed against my packages, I think 1 resulted in a real fix that I needed to apply as a packager. Another was fixed by an update. The rest are piling up. I don't have the time to fix them myself. I rarely get any response to my requests for more info (5 are in needinfo). I haven't been able to get upstream to involved. I'm seriously considering orphaning pdfedit (14 bugs) over this.
A: It's not possible for ABRT to determine if the bug was caused by Fedora specific patch or by an upstream code, so just forwarding it to upstream is really not good idea. If those bugs are serious - affecting a lot of people then upstream should care, if they don't it's unfortunate, but nothing what ABRT should be blame for...
Q: Its been somewhat a disappointing experience. Not because of the % of the bugs fixed, but because of the % response. I'm not sure if any of my bugs have been responded to. There are probably one or two. I've been annoyed that some of the bugs are getting many many CC's added to them (or the ones I've been added to), but no response.
A: If you filled the "how to reproduce" and provided a good description and there was a lot of people CCed on the bug, then not-responding to the report just shows the nature of the packager... (please don't start a flame about this, I know there might be bugs with a lot of CC and no usable comment, but c'mon how many of such bugs is there?)
Q: The extreme inefficiency comes from the bugs that I can't reproduce, the upstream can't reproduce, and the user isn't responding. And this happens *a lot*. Most of the time, they don't even put down the steps to reproduce.
A: Agree, the way I handle these bugs is to ask user for steps to reproduce or at least some hints, if he doesn't respond in some time, I just close it as INSUFFICIENT_DATA, there is really nothing more you can do.
Q: Can we at least mandate including the steps to reproduce in the ABRT reports?
A: We can, but I'm really not sure how to write a logic that will check the if the steps make sense or if it's just "lorem ipsum" ...
Q: > > On one hand it's a systematic way to report bugs, on the other hand it
forces me download debug packages and to struggle with its GUI. Considering the facts that downloading 100MBs of debug-packages may
not
always be applicable (E.g. when not having broadband access), that
abrt
not always manages to correctly handle debug-infos, this costs.
That said, I repeatedly ended up with "deleting" abrt notifications
and
to ignore it.
This is another thing where we don't have any trouble identifying the problem and the solution. Will Woods has had the debuginfofs system sketched out for years to deal with this. What he doesn't have is the time to write it (since he's busy with AutoQA). Anyone else could do it instead, though.
A: There is a few projects trying to deal with this, some of them should be ready for F15 we will be more than happy for some feedback on this, so together we make sure it's going the right direction...
http://fedoraproject.org/wiki/Features/RetraceServer http://fedoraproject.org/wiki/Features/DebuginfoFS
Q: It's the "nagging"/"non-crasher" class of bugs, which is really reducing the "user-experience" of Fedora, exactly the class of bugs "abrt" is not designed to to not cover.
A: Such bugs can be easily reported using the BZ's web page as it's more an essay then a bug report, so no additional data or user skills required for such bugreport...
Q: Wasn't there some way for a maintainer to opt out of abrt? I remember seeing this being discussed but cannot find how to do it on the abrt trac or in the man-pages.
A: The maintainer who can't handle the number of ABRT reports or thinks that ABRT can't provide any usefull information about crash in his package (or has some other good reason) can always ping me and I will add this package to ABRT's blacklist in it's default configuration. I'm not sure if we should allow packager to blacklist their packages without asking us first, but if there will be a lot of you asking for it, I'm not against it...
Hope this clears some things out, Jirka
On Thu, Nov 04, 2010 at 02:21:19PM +0100, Christoph Wickert wrote:
[Opt-out for ABRT-Reports]
How would you do that? A popup in ABRT that reads "Sorry, but the maintainer of this package has decided to not accept any bug reports."
Nope.
App X crashes and then _nothing_ happens. Just as if abrtd wasn't running.
Maybe a hint in the crash-list of the abrt app that the maintainer has decided to not accept abrt generated bug-reports.
I like abrt but I'd say that it should be up to the maintainer if he wants to use the tool or not. In particular when ignoring the reports sheds a bad light on the projects bug-response-quality perception.
"RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> In other words, as far as I am concerned, abrt has reduced RC> efficiency of bug-hunting by flooding maintainers with low quality, RC> often unusable reports and risen the communication churn related to RC> BZs.
It's been discussed many times and I still believe that it would be extremely beneficial for ABRT to remain, but to store its data somewhere other than bugzilla. Perhaps this speaks more to deficiencies in bugzilla, but it really doesn't seem to be the proper repository for the information that ABRT is producing. Not only do you need an account in order to report things, but the ABRT client is responsible for trying to eliminate duplicates (which it's getting better at, I admit). And bugzilla really makes it difficult to manage large numbers of bugs, which is a problem in itself but certainly not helped by ABRT piling on.
But I guess without someone stepping up and implementing non-bugzilla storage for ABRT and the tools required to query that data, this is all just idle talk.
- J<
On 11/04/2010 03:38 PM, Sven Lankes wrote:
On Thu, Nov 04, 2010 at 02:21:19PM +0100, Christoph Wickert wrote:
[Opt-out for ABRT-Reports]
How would you do that? A popup in ABRT that reads "Sorry, but the maintainer of this package has decided to not accept any bug reports."
Nope.
App X crashes and then _nothing_ happens. Just as if abrtd wasn't running.
Maybe a hint in the crash-list of the abrt app that the maintainer has decided to not accept abrt generated bug-reports.
I like abrt but I'd say that it should be up to the maintainer if he wants to use the tool or not. In particular when ignoring the reports sheds a bad light on the projects bug-response-quality perception.
That's how the blacklist in ABRT works right now. But since I started thinking about this I feel like it's not the right way, because hiding crashes != fixing crashes and since we have ABRT in Fedora, users expect to be (at least) notified about crashes, so I propose changing the blacklist behaviour so user is notified about the crash, but when user wants to report (or generate a backtrace) it will tell him something like:
ABRT can't report a bug in this application, because it's not able to gather all required information. You can analyze the bug using ABRT, but you have to create the report manually.
or something in that sense I bet someone get make a better and more polite message...
Any other ideas?
J.
On Thu, 4 Nov 2010, Christoph Wickert wrote:
How would you do that? A popup in ABRT that reads
"Sorry, but the maintainer of this package has decided to not accept any bug reports."
I think this would be a *really* bad user experience.
If telling the truth about Open Source development decisions provide a '*really* bad user experience', the packager and the hosting project has to decide
if a fork is in order, and if they can credibly do it; or
to remove the package and explain why; or
if it is such an immensely popular package that one 'CANNOT' omit it [firefox and the Mozilla Foundation's approach on trademarks comes to mind], still document a URL to the problem in the popup on a pre package basis
Concealing and hiding from the truth (lying to one-self and others about reality) can scarcely be called 'being excellent to one another' or to the community toard which advocacy and service are being targetted, no?
-- Russ herrold
On 04/11/10 14:46, Jiri Moskovcak wrote: <snip>
but when user
wants to report (or generate a backtrace) it will tell him something like:
ABRT can't report a bug in this application, because it's not able
to gather all required information. You can analyze the bug using ABRT, but you have to create the report manually.
Thats where the user may say "Forget this"
or something in that sense I bet someone get make a better and more polite message...
Be honest, not polite. If a maintainer doesn't want auto generated bugz, then tell the user. "The maintainer would prefer a manully generated report, please contact the package maintainer: foo-owner@ \ bugzilla component foo for further details"
On Wed, 2010-11-03 at 21:02 -0400, Orcan Ogetbil wrote:
On Wed, Nov 3, 2010 at 4:41 PM, Bert Desmet wrote:
hi!
This is something I got in my mail box today. As I don't have a valid answer for this, maybe someone else can answer for me?
cheers, Bert
the url of the blog of the guy: http://www.krisbuytaert.be/blog/
== the mail ==
Dear Fedoracommunity,
Over the course of the day I recieved 22^3 mails from your friendly Bug Zapper. Most of those bugs where bugs I had reported upon crashes using bug-buddy. Bugs on different desktop tools such as .. synergy, evolution, gwibber , gnome-settings and probably some others
I do understand that I development goes on and on .. and your fancy devs don't care anymore about bugs I reported on Fedora 12 as they are all hacking on Fedora 15.
But what I don't get is that non of these bugs was ever touched, they've been automatically created , and automatically closed
<a href="http://tieguy.org/blog/2004/09/">Luis</a> already told us ages ago .. that every project needs a bugmaster apparently Fedora replaced that bugmaster with a Bug Zapper.
So can someone please explain my why I should continue to try to improve Fedora by reporting bugs ?
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is.
From what I have seen, the maintainers are more responsive to manually filed bugs than to ABRT filed bugs (Am I wrong?). Apparently the current setup is driving users (such as the person in the above email) away who are otherwise willing to report bugs. This is not good.
What can we do to make it better? Some ideas:
- ABRT stops reporting new bugs to Fedora.
- The user does a self evaluation: Is the bugcoding related, or
packaging related?
- If he thinks the bug is packaging related, or if he's not sure, he
manually files a bug to Fedora bugzilla. Otherwise he notifies the developers.
- The package maintainer asks for a backtrace
- User reproduces the crash, and puts the bug number in ABRT gui. ABRT
posts the backtrace to the bug report as an attachment.
- If the bug is coding related, the package maintainer can direct the
user to the developers.
There can be a checkbox in pkgdb for maintainers to turn off ABRT bug reporting for their packages.
?
FWIW, I'll take this opportunity to send along a link to the triage scripts I wrote for Python ABRT bugs: http://people.fedoraproject.org/gitweb?p=dmalcolm/public_git/triage.git;a=tr...
This is a mixture of generalized logic for parsing an incoming bug and doing things with it, plus a bunch of python-specific heuristics based on the reports that I'm seeing. I'm sure it could be adapted/extended by other package maintainers to cover the patterns of bug reports that they receive.
I try to use this on all incoming bugs I receive, so that they've at least had _some_ attention. Though on busy days I'm afraid I do let some things drop on the floor :(
Caveat: the GUI doesn't work yet.
Hope this is helpful Dave
On 11/04/2010 01:21 PM, Christoph Wickert wrote:
Am Donnerstag, den 04.11.2010, 13:28 +0100 schrieb Michael Schwendt:
On Wed, 3 Nov 2010 21:41:22 +0100, Bert wrote:
So can someone please explain my why I should continue to try to improve Fedora by reporting bugs ?
Glad you ask this. The bugzapping script is stupid. It asks the reporter for NEEDINFO when in fact it ought to ask WTF has the packager not responded since Fedora 12?
- 100!
Agreed
If the maintainer is not responding to reports or not acting as the link to upstream ( that if he's not upstream himself ) for the component he's responsable for in Fedora I ask you this why are those components in bugzilla in the first place?
If we want to fix things we need to fix things at the root level and we dont do that by blaming tools like abrt and the root level here are those non responsive maintainers.
We can try to find the root cause why they are unresponsive and try to address that or we can seperate non responsive maintainers from the responsive ones and remove those components from bugzilla and at the same time we can work with those responsive maintainers and the community with improving things on both maintainers/reporters sides.
In the end not responding to bugs does nothing more than to waste community resource ( reporters QA in general ) and hurts the project reputation since often bugs do not get fixed resulting in the novise end user(s) experience the same bug being horrible if we are lucky we have other application with similar function packed and ready for the novice end user if we are unlucky we loose him cursing Fedora being to broken to use with all the glory that comes with that.
JBG
On Thu, Nov 04, 2010 at 04:10:31PM +0000, "Jóhann B. Guðmundsson" wrote:
If the maintainer is not responding to reports or not acting as the link to upstream ( that if he's not upstream himself ) for the component he's responsable for in Fedora I ask you this why are those components in bugzilla in the first place?
The reason is that bugzilla can still be used for Fedora-specific packaging bugs for these components.
I agree however that the Fedora packager should at least respond to bugs, even if only to say "sorry, that's way out of my league, I'm only handling packaging, have a look at this upstream bugtracker".
Rich.
On Thu, 2010-11-04 at 12:18 +0100, Sven Lankes wrote:
On Thu, Nov 04, 2010 at 02:15:30AM -0400, Orcan Ogetbil wrote:
The question is Am I using the time efficiently? OR Are the these tools actually preventing me to be efficient during my available time?
Wasn't there some way for a maintainer to opt out of abrt?
I remember seeing this being discussed but cannot find how to do it on the abrt trac or in the man-pages.
Was it just a plan? Is it not wanted?
You can contact the abrt developers and they can put an exception in abrt's configuration.
On Thu, 2010-11-04 at 13:28 +0100, Michael Schwendt wrote:
So can someone please explain my why I should continue to try to improve Fedora by reporting bugs ?
Glad you ask this. The bugzapping script is stupid. It asks the reporter for NEEDINFO when in fact it ought to ask WTF has the packager not responded since Fedora 12?
you're looking at it through a 'moral' framework when the important thing is the 'practical' framework. :) The practical point is that F12 is about to go EOL which means the bug must be closed...UNLESS it's still present in later releases. It's the reporter who is most likely to be able to say whether it is, therefore, we ask the user to check and update the bug, not the maintainer. It may be 'fairer' to set needinfo maintainer, but the result sure wouldn't be as good in practical terms, because the maintainer is less likely than the user to actually be able/inclined to provide the required data.
On Thu, 2010-11-04 at 14:20 +0100, Christoph Wickert wrote:
Am Donnerstag, den 04.11.2010, 02:15 -0400 schrieb Orcan Ogetbil:
The question is Am I using the time efficiently? OR Are the these tools actually preventing me to be efficient during my available time?
How would they? You can ignore all bug reports, you can even set up a mail filter to not see them. Costs no time, so it is very efficient.
IMHO ABRT is just an offer. It depends on you what you make of it. I can only encourage maintainers to care about ABRT bugs and push everything upstream, even if it might be frustrating due to the lack of feedback from both the developers and the reporters.
This is a way to look at it, but I'd suggest that if you're going to set up a filter to simply ignore abrt bugs, you should at least set it so that it auto-replies to them with a message to that effect, so users aren't left looking at a dead bug report and wondering why.
On Thu, 2010-11-04 at 14:21 +0100, Christoph Wickert wrote:
Am Donnerstag, den 04.11.2010, 12:18 +0100 schrieb Sven Lankes:
On Thu, Nov 04, 2010 at 02:15:30AM -0400, Orcan Ogetbil wrote:
The question is Am I using the time efficiently? OR Are the these tools actually preventing me to be efficient during my available time?
Wasn't there some way for a maintainer to opt out of abrt?
I remember seeing this being discussed but cannot find how to do it on the abrt trac or in the man-pages.
Was it just a plan? Is it not wanted?
How would you do that? A popup in ABRT that reads
"Sorry, but the maintainer of this package has decided to not accept any bug reports."
I think this would be a *really* bad user experience.
When abrt is configured not to report bugs for a given package it simply doesn't track those crashes at all. If the app crashes, you don't get an abrt pop up. (AIUI, anyway.)
On 11/04/2010 04:24 PM, Richard W.M. Jones wrote:
On Thu, Nov 04, 2010 at 04:10:31PM +0000, "Jóhann B. Guðmundsson" wrote:
If the maintainer is not responding to reports or not acting as the link to upstream ( that if he's not upstream himself ) for the component he's responsable for in Fedora I ask you this why are those components in bugzilla in the first place?
The reason is that bugzilla can still be used for Fedora-specific packaging bugs for these components.
Fail to see the reasoning here.
If the maintainer is not responding in the first place....
I agree however that the Fedora packager should at least respond to bugs, even if only to say "sorry, that's way out of my league, I'm only handling packaging, have a look at this upstream bugtracker".
Our view on this differes from my perspective I considere it one of packager responsability/duty to be the liasion between Fedora users/reporters and upstream ( from user perspective Fedora is upstream ) after all he's the one that introduced that component and signed up to maintain it in Fedora in the first place.
So using you example from above, from my perspective it is this
"Sorry, that's way out of my league, I'm only handling packaging. I have contacted and filed this bug upstream for you <insert link to upstream bug here >.
please keep track on it encase upstream needs some further details from you.
When this bug has been fixed and that fix has found it's way to Fedora I will make notify of that on this report so you can test if that bug fix has fixed the problem you experienced.
Thank you for your report".
I agree with you that atleast some communication is better then none.
JBG
On 07:41 Thu 04 Nov , Ralf Corsepius wrote:
snip...
As a maintainer, abrt to me primarily means "wading through wakes of hardly readable emails", mostly to scan them for useful information. I many cases I ended up with closing BZ, because these emails did not contain sufficient info.
That said, as a maintainer, abrt to me only has introduced a higher noise/signal ratio in bugreports as before.
This is the problem we have with java-1.6.0-openjdk, except it's magnified by the fact that the user could be running *ANYTHING* on the JVM. So if some native code in a Java application crashes the JVM, we get an abrt bug report for it.
The information provided is pretty much always useless for diagnosing the issue. The attached crash report is pretty incomprehensible for the JVM. Including the hs_err_<pid>.log generated by the JVM would at least be a start in making it easier to see what the failure was. But the main problem is that there is pretty much no way of reproducing most of these crashes and the user often has no clue what happened.
We're getting lots of these, on a daily basis, which means that proper bug reports (i.e. ones filed by users who actually took the time to file a bug report with some useful information) are getting swamped by these abrt reports and our valuable time is being wasted.
Please turn these off for this package until such a time as the default abrt report is actually useful for some form of diagnosis, which means it at least has an hs_err file and mandatory reproducer information.
Ralf
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 04/11/10 17:51, Dr Andrew John Hughes wrote:
This is the problem we have with java-1.6.0-openjdk, except it's magnified by the fact that the user could be running *ANYTHING* on the JVM. So if some native code in a Java application crashes the JVM, we get an abrt bug report for it.
<snip>
Please turn these off for this package until such a time as the default abrt report is actually useful for some form of diagnosis, which means it at least has an hs_err file and mandatory reproducer information.
Then step up and work with the abrt devs, tell them what you need. "Don't shoot the messenger, help improve the message"
On 17:54 Thu 04 Nov , Frank Murphy wrote:
On 04/11/10 17:51, Dr Andrew John Hughes wrote:
This is the problem we have with java-1.6.0-openjdk, except it's magnified by the fact that the user could be running *ANYTHING* on the JVM. So if some native code in a Java application crashes the JVM, we get an abrt bug report for it.
<snip> > > Please turn these off for this package until such a time as the default > abrt report is actually useful for some form of diagnosis, which means > it at least has an hs_err file and mandatory reproducer information.
Then step up and work with the abrt devs, tell them what you need. "Don't shoot the messenger, help improve the message"
I just have.
And not for the first time.
-- Regards,
Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, 2010-11-04 at 17:51 +0000, Dr Andrew John Hughes wrote:
Please turn these off for this package until such a time as the default abrt report is actually useful for some form of diagnosis, which means it at least has an hs_err file and mandatory reproducer information.
It'd be best to send this request directly to the abrt team (though I think Jiri is reading this thread now so he should pick it up).
On 11/04/2010 06:56 PM, Dr Andrew John Hughes wrote:
On 17:54 Thu 04 Nov , Frank Murphy wrote:
On 04/11/10 17:51, Dr Andrew John Hughes wrote:
This is the problem we have with java-1.6.0-openjdk, except it's magnified by the fact that the user could be running *ANYTHING* on the JVM. So if some native code in a Java application crashes the JVM, we get an abrt bug report for it.
<snip> > > Please turn these off for this package until such a time as the default > abrt report is actually useful for some form of diagnosis, which means > it at least has an hs_err file and mandatory reproducer information.
Then step up and work with the abrt devs, tell them what you need. "Don't shoot the messenger, help improve the message"
I just have.
And not for the first time.
Speaking of JVM - I already tried to contact the JVM maintainers (http://lists.fedoraproject.org/pipermail/java-devel/2010-October/003957.html).... I can blacklist jvm before we figure this out, but I'm afraid, that by silencing ABRT the whole JVM+ABRT problem will just go off the radar...
Jirka
-- Regards,
Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 19:06 Thu 04 Nov , Jiri Moskovcak wrote:
On 11/04/2010 06:56 PM, Dr Andrew John Hughes wrote:
On 17:54 Thu 04 Nov , Frank Murphy wrote:
On 04/11/10 17:51, Dr Andrew John Hughes wrote:
This is the problem we have with java-1.6.0-openjdk, except it's magnified by the fact that the user could be running *ANYTHING* on the JVM. So if some native code in a Java application crashes the JVM, we get an abrt bug report for it.
<snip> > > Please turn these off for this package until such a time as the default > abrt report is actually useful for some form of diagnosis, which means > it at least has an hs_err file and mandatory reproducer information.
Then step up and work with the abrt devs, tell them what you need. "Don't shoot the messenger, help improve the message"
I just have.
And not for the first time.
Speaking of JVM - I already tried to contact the JVM maintainers (http://lists.fedoraproject.org/pipermail/java-devel/2010-October/003957.html).... I can blacklist jvm before we figure this out, but I'm afraid, that by silencing ABRT the whole JVM+ABRT problem will just go off the radar...
Yes, this thread is what I was referring to.
If you're happy with /var/log/openjdk as a location for error logs, I can look at adding this option upstream. But this would take time to appear in the java-1.6.0-openjdk packages and presumably for the abrt side to be worked out too.
In the meantime, we should consider turning off ABRT for OpenJDK until fixes on both the abrt and OpenJDK side have trickled through to end users.
Jirka
-- Regards,
Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 11/04/2010 07:26 PM, Dr Andrew John Hughes wrote:
On 19:06 Thu 04 Nov , Jiri Moskovcak wrote:
On 11/04/2010 06:56 PM, Dr Andrew John Hughes wrote:
On 17:54 Thu 04 Nov , Frank Murphy wrote:
On 04/11/10 17:51, Dr Andrew John Hughes wrote:
This is the problem we have with java-1.6.0-openjdk, except it's magnified by the fact that the user could be running *ANYTHING* on the JVM. So if some native code in a Java application crashes the JVM, we get an abrt bug report for it.
<snip> > > Please turn these off for this package until such a time as the default > abrt report is actually useful for some form of diagnosis, which means > it at least has an hs_err file and mandatory reproducer information.
Then step up and work with the abrt devs, tell them what you need. "Don't shoot the messenger, help improve the message"
I just have.
And not for the first time.
Speaking of JVM - I already tried to contact the JVM maintainers (http://lists.fedoraproject.org/pipermail/java-devel/2010-October/003957.html).... I can blacklist jvm before we figure this out, but I'm afraid, that by silencing ABRT the whole JVM+ABRT problem will just go off the radar...
Yes, this thread is what I was referring to.
If you're happy with /var/log/openjdk as a location for error logs, I can look at adding this option upstream.
- ok, great!
But this would take time to appear in the java-1.6.0-openjdk packages and presumably for the abrt side to be worked out too.
In the meantime, we should consider turning off ABRT for OpenJDK until fixes on both the abrt and OpenJDK side have trickled through to end users.
- deal :)
I wait a few days for other maintainers who wants to blacklist their packages (please write directly to me) and then will update ABRT in Fedora with this new configuration.
Jirka
-- Regards,
Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Le jeudi 04 novembre 2010 à 09:38 -0700, Adam Williamson a écrit :
On Thu, 2010-11-04 at 13:28 +0100, Michael Schwendt wrote:
So can someone please explain my why I should continue to try to improve Fedora by reporting bugs ?
Glad you ask this. The bugzapping script is stupid. It asks the reporter for NEEDINFO when in fact it ought to ask WTF has the packager not responded since Fedora 12?
you're looking at it through a 'moral' framework when the important thing is the 'practical' framework. :) The practical point is that F12 is about to go EOL which means the bug must be closed...UNLESS it's still present in later releases. It's the reporter who is most likely to be able to say whether it is, therefore, we ask the user to check and update the bug, not the maintainer.
From a practical point of view, as a bug reporter, when I get mass
notifications to update scores of bugs that were opened years ago, and that the people owning the component never bothered to respond on (even to confirm they were alive), I just /dev/null the result and never look at it again.
Sometimes people ask me why I let bugs get autoclosed when they hit the same problems months later, but really, I don't see the point of spending hours to re-test reports, when no one could spend minutes to ask for (human) confirmation.
And that includes abrt reports. Any abrt report on testing of rawhide is a major PITA to assemble (minimum half an hour for a typical gui app to hunt down all the missing debuginfos manually in koji, since the debuginfo mirrors never seem to be in sync with the package depos themselves, not counting when abrt wants me to download the gigs of kernel debuginfo of the day), so if when people say here abrt is "too easy" and abrt reporters "do not make efforts" I cant only be ROTFL (or crying, more accurately)
Le jeudi 04 novembre 2010 à 19:40 +0100, Jiri Moskovcak a écrit :
On 11/04/2010 07:26 PM, Dr Andrew John Hughes wrote:
Yes, this thread is what I was referring to.
If you're happy with /var/log/openjdk as a location for error logs, I can look at adding this option upstream.
- ok, great!
Please either use the same directory name as the one the jvm is installed under /usr/lib/jvm/, or choose a directory name all jvms can share.
On 11/04/2010 01:05 AM, Adam Williamson wrote:
My question would be 'why'? There seems to be an assumption that an open bug report you can't fix is a serious problem; of course in a sense it is, but then, it's not as if, if we remove or otherwise change abrt, software is going to magically stop crashing. It's going to crash just as much. There just won't be bug reports associated with the crashes. I guess what I'm asking is what actual harm/damage are these reports causing, beyond the time it takes to look at the report and figure out whether you can fix it? Why is the fact that people have experienced crashes you haven't yet figured out how to fix a reason to stop maintaining the software?
Amen to that. My own experience is that I am not a packager, but I care about the packages I use---so if there are bugs, I want to be able to file reports, and in some cases I was able to fix bugs, e..g. in drgeo and BLT.
In my case, it ended up being an efficient method of communicating with the package manager. I found a bug, I sent a patch, it went in through testing, and became part of Fedora. I had a good experience with the system.
I filed maybe a dozen bug reports. The emails are slightly annoying (why do I need to know about new CC:s on the bug list), but I am surprised that it would lead someone to quit using the system.
I think some improvements could be made in the user interaction; perhaps the initial ABRT screen should have an opt-out to all automated email for those who don't think they'll get involved in the bugzilla process. The fixers can still pull the email from the report and ask questions in personal emails.
On Thu, 2010-11-04 at 17:51 +0000, Dr Andrew John Hughes wrote:
On 07:41 Thu 04 Nov , Ralf Corsepius wrote:
snip...
As a maintainer, abrt to me primarily means "wading through wakes of hardly readable emails", mostly to scan them for useful information. I many cases I ended up with closing BZ, because these emails did not contain sufficient info.
That said, as a maintainer, abrt to me only has introduced a higher noise/signal ratio in bugreports as before.
This is the problem we have with java-1.6.0-openjdk, except it's magnified by the fact that the user could be running *ANYTHING* on the JVM. So if some native code in a Java application crashes the JVM, we get an abrt bug report for it.
The information provided is pretty much always useless for diagnosing the issue. The attached crash report is pretty incomprehensible for the JVM. Including the hs_err_<pid>.log generated by the JVM would at least be a start in making it easier to see what the failure was. But the main problem is that there is pretty much no way of reproducing most of these crashes and the user often has no clue what happened.
Could some of this by alleviated by teaching gdb a bit more about the insides of the JVM? (e.g. how to prettyprint JVM objects and stack frames?)
Doing the equivalent for CPython has been a huge improvement for the analogous situation: https://fedoraproject.org/wiki/Features/EasierPythonDebugging
Hope this is helpful Dave
On Thu, 2010-11-04 at 19:44 +0100, Nicolas Mailhot wrote:
From a practical point of view, as a bug reporter, when I get mass notifications to update scores of bugs that were opened years ago, and that the people owning the component never bothered to respond on (even to confirm they were alive), I just /dev/null the result and never look at it again.
Sometimes people ask me why I let bugs get autoclosed when they hit the same problems months later, but really, I don't see the point of spending hours to re-test reports, when no one could spend minutes to ask for (human) confirmation.
I think that is fine. It's not your responsibility to retest a bug you no longer care about. If someone else cares and retests, they ideally would be able to reopen it, but Bugzilla currently doesn't allow that ( https://bugzilla.redhat.com/show_bug.cgi?id=573535 ). If no one cares, the bug may not be worth fixing.
On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote:
The practical point is that F12 is about to go EOL which means the bug must be closed...
Why? Obviously it needs to be clear that nothing further should be expected from the maintainer unless/until the version is bumped. But the project can choose to indicate that by closing the bugs as WONTFIX or some other way, e.g., another resolution or by customizing Bugzilla to show a notice on bugs that are open against an EOL version of Fedora. Personally, I dislike the use of WONTFIX because philosophically I think it doesn't fit, and practically it makes zapped bugs impossible to distinguish from real WONTFIX bugs in searches (https://bugzilla.redhat.com/show_bug.cgi?id=528319).
* Przemek Klosowski [04/11/2010 21:51] :
(why do I need to know about new CC:s on the bug list)
FWIW, this can be configured: https://bugzilla.redhat.com/userprefs.cgi?tab=email
Emmanuel
On 11/04/2010 03:22 PM, Emmanuel Seyman wrote:
- Przemek Klosowski [04/11/2010 21:51] :
(why do I need to know about new CC:s on the bug list)
FWIW, this can be configured: https://bugzilla.redhat.com/userprefs.cgi?tab=email
Emmanuel
But probably should be configured not to send CC changes by default. It's the first thing I do with every bugzilla account...
On Thu, Nov 4, 2010 at 1:51 AM, Peter Lemenkov wrote:
2010/11/4 Orcan Ogetbil :
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is.
No need to discuss - it's really useful. I recently closed several issues with the aid of stacktaces sent by ABRT.
I am very happy that the current scheme works well for you. You think that we should ignore the outstanding 93% of the ABRT bug reports, and the 6000 untouched bugs that will be closed in a month. If we don't do anything that 6000 will multiply at the end of the F-13 cycle.
The current scheme did not fit the majority of maintainers.This is obvious. The numbers just prove it. Moreover, it drives users away from reporting bugs and drives at least 1 maintainer away from maintaining certain packages.
Instead of saying "no need to discuss, it works for me", let us try to improve this process. Going in circular arguments will not help us.
Orcan
On 11/04/2010 10:49 PM, Orcan Ogetbil wrote:
On Thu, Nov 4, 2010 at 1:51 AM, Peter Lemenkov wrote:
2010/11/4 Orcan Ogetbil :
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is.
No need to discuss - it's really useful. I recently closed several issues with the aid of stacktaces sent by ABRT.
I am very happy that the current scheme works well for you. You think that we should ignore the outstanding 93% of the ABRT bug reports, and the 6000 untouched bugs that will be closed in a month. If we don't do anything that 6000 will multiply at the end of the F-13 cycle.
The current scheme did not fit the majority of maintainers.This is obvious. The numbers just prove it. Moreover, it drives users away from reporting bugs and drives at least 1 maintainer away from maintaining certain packages.
Instead of saying "no need to discuss, it works for me", let us try to improve this process. Going in circular arguments will not help us.
Orcan
Obviously we *need* to discuss, but just complaining won't help anything - if you think ABRT is not providing a good info for you packages, then please write me an email how to improve it (which data you'd like to see for specific packages) and we can sure do something about that and disable it in a meanwhile to relieve you from those useless bug reports.
Jirka
On Thu, Nov 4, 2010 at 6:05 PM, Jiri Moskovcak wrote:
On 11/04/2010 10:49 PM, Orcan Ogetbil wrote:
On Thu, Nov 4, 2010 at 1:51 AM, Peter Lemenkov wrote:
2010/11/4 Orcan Ogetbil :
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is.
No need to discuss - it's really useful. I recently closed several issues with the aid of stacktaces sent by ABRT.
I am very happy that the current scheme works well for you. You think that we should ignore the outstanding 93% of the ABRT bug reports, and the 6000 untouched bugs that will be closed in a month. If we don't do anything that 6000 will multiply at the end of the F-13 cycle.
The current scheme did not fit the majority of maintainers.This is obvious. The numbers just prove it. Moreover, it drives users away from reporting bugs and drives at least 1 maintainer away from maintaining certain packages.
Instead of saying "no need to discuss, it works for me", let us try to improve this process. Going in circular arguments will not help us.
Orcan
Obviously we *need* to discuss, but just complaining won't help anything
- if you think ABRT is not providing a good info for you packages, then
please write me an email how to improve it (which data you'd like to see for specific packages) and we can sure do something about that and disable it in a meanwhile to relieve you from those useless bug reports.
Sure, here are the things that I need.
1- For my packages, I don't want any ABRT bug reports without the "Steps to reproduce" information. ABRT should tell the user the field is missing and it won't send a bug report until the user fills it. Some maintainers say they don't need the "Steps to reproduce", but I need it.
2- ABRT should keep track of unresponsive users. If a user has an outstanding "needinfo?" flag for the bugs sent through ABRT, he shouldn't be able to send a new bug report through ABRT for my packages.
3- Ability to turn off ABRT for certain packages. Whenever I provide an application package with no nonstandard patches and there is a crash, it is most definitely not my fault. The user should be instructed to take the backtrace upstream to the URL of the package and report it in their bug tracker/mailing list. Even better, ABRT can file the bug directly upstream. I am willing to provide the information of upstream bug trackers/mailing lists for all of my packages.
Thanks for your understanding, Orcan
On Thu, 04 Nov 2010 16:10:17 -0400, Matt McCutchen wrote:
On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote:
The practical point is that F12 is about to go EOL which means the bug must be closed...
Why? Obviously it needs to be clear that nothing further should be expected from the maintainer unless/until the version is bumped. But the project can choose to indicate that by closing the bugs as WONTFIX or some other way, e.g., another resolution or by customizing Bugzilla to show a notice on bugs that are open against an EOL version of Fedora. Personally, I dislike the use of WONTFIX because philosophically I think it doesn't fit, and practically it makes zapped bugs impossible to distinguish from real WONTFIX bugs in searches (https://bugzilla.redhat.com/show_bug.cgi?id=528319).
This is my problem with the auto closing also. Leaving a bug open allows a more dedicated maintainer to come along (even years later) and actually fix or even apply patches that are still relevant without wasting time with bugs that we're actually looked at and legitimately closed.
On 11/04/2010 07:47 PM, Matt McCutchen wrote:
If someone else cares and retests, they ideally would be able to reopen it, but Bugzilla currently doesn't allow that
Somebody can correct me if I'm wrong but as I recall we changed that deliberately. ( should be a discussion about this in this list archives or on the test list archives or QA meetings log even )
If I can recall correctly the problem was that the ( new/inexperienced ) reporters were constantly opening bugs maintainer(s) closed due to misunderstanding of the underlying problem or simply disagreement between them and they were constantly changing severity and priority of bugs which maintainers use to prioritise their own work flow . ( new/inexperienced reporters had a tendency to think the bug they experienced was the most severe one )
Conscious was reached to strip those rights from the reporters and triagers by default and if/when they joined certain fas group(s) they would gain that access.
This move generally improved interaction between reporters/triagers and maintainers/packagers and so far you are the only one I've noticed that mentions the lack of the ability to do this in our bugzilla.
I think the general practice between reporters is to file a new report and mentioning regression and refer to the old bug in that report since commenting on a closed bug may not have the ( current ) maintainer(s) still subscribed to it.
Maintainers themselves can then decide if they want to reopen the old one and mark the new one as duplicate or keep it a separated bug.
JBG
Ps. Dont hesitate to correct me if memory has been playing tricks on me and this discussion and relevant action never took place this is all very vague to me.. .
On 11/04/2010 11:22 PM, Orcan Ogetbil wrote:
On Thu, Nov 4, 2010 at 6:05 PM, Jiri Moskovcak wrote:
On 11/04/2010 10:49 PM, Orcan Ogetbil wrote:
On Thu, Nov 4, 2010 at 1:51 AM, Peter Lemenkov wrote:
2010/11/4 Orcan Ogetbil :
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is.
No need to discuss - it's really useful. I recently closed several issues with the aid of stacktaces sent by ABRT.
I am very happy that the current scheme works well for you. You think that we should ignore the outstanding 93% of the ABRT bug reports, and the 6000 untouched bugs that will be closed in a month. If we don't do anything that 6000 will multiply at the end of the F-13 cycle.
The current scheme did not fit the majority of maintainers.This is obvious. The numbers just prove it. Moreover, it drives users away from reporting bugs and drives at least 1 maintainer away from maintaining certain packages.
Instead of saying "no need to discuss, it works for me", let us try to improve this process. Going in circular arguments will not help us.
Orcan
Obviously we *need* to discuss, but just complaining won't help anything
- if you think ABRT is not providing a good info for you packages, then
please write me an email how to improve it (which data you'd like to see for specific packages) and we can sure do something about that and disable it in a meanwhile to relieve you from those useless bug reports.
Sure, here are the things that I need.
1- For my packages, I don't want any ABRT bug reports without the "Steps to reproduce" information. ABRT should tell the user the field is missing and it won't send a bug report until the user fills it. Some maintainers say they don't need the "Steps to reproduce", but I need it.
- ok, but there is a problem as ABRT doesn't have the logic to ask for steps to reproduce just for some packages, so the easiest would be to ask for it for every package - but even then I think you will end up with a lot of bugs with "Don't know" as steps to reproduce.. btw, one of our RFEs is to let user attach a screencast of how to reproduce a bug...
2- ABRT should keep track of unresponsive users. If a user has an outstanding "needinfo?" flag for the bugs sent through ABRT, he shouldn't be able to send a new bug report through ABRT for my packages.
- interesting idea, but this is hardly doable just on the client side and would require a server side support
3- Ability to turn off ABRT for certain packages. Whenever I provide an application package with no nonstandard patches and there is a crash, it is most definitely not my fault. The user should be instructed to take the backtrace upstream to the URL of the package and report it in their bug tracker/mailing list. Even better, ABRT can file the bug directly upstream. I am willing to provide the information of upstream bug trackers/mailing lists for all of my packages.
- this is tricky one - even without patches, the application may be crashing because of some library we use in Fedora and it's really hard to say if the library is causing that or the program itself so that's where we the maintainers step in and decide before reporting to upstream... other problem is that every bug tracker would require a specific reporter plugin which usually takes a few weeks to write and test ...
So to sum it up, the fastest solution I can provide for you is to blacklist your packages and/or ask for at least some text in steps to reproduce.
Jirka
Thanks for your understanding, Orcan
On Thu, 04 Nov 2010 11:57:58 +0100, Emmanuel Seyman wrote:
- Orcan Ogetbil [04/11/2010 09:35] :
The extreme inefficiency comes from the bugs that I can't reproduce, the upstream can't reproduce, and the user isn't responding. And this happens *a lot*. Most of the time, they don't even put down the steps to reproduce. Can we at least mandate including the steps to reproduce in the ABRT reports?
Is there any reason you can't close these bugs with a INSUFFICIENT_DATA resolution? This seems to be the most appropriate thing to do in this case.
Even better: can abrt-reported bugs that have been NEEDINFO for more than, say, 7 days be automatically closed INSUFFICIENT_DATA?
That'd be quite a huge timesaver. Better duplicate detection would be nice too.
On 11/04/2010 10:22 PM, Orcan Ogetbil wrote:
2- ABRT should keep track of unresponsive users. If a user has an outstanding "needinfo?" flag for the bugs sent through ABRT, he shouldn't be able to send a new bug report through ABRT for my packages.
Since this has turned into general pony request to the ABRT I shall throw in one for the reporters
On behalf of all reporters that have never received a response from a maintainer on a component they have reported against I not only ask the ABRT maintainers to block any reports against those component that a maintainer has not responded but I also request that those components get removed from bugzilla.redhat.com.
3- Ability to turn off ABRT for certain packages. Whenever I provide an application package with no nonstandard patches and there is a crash, it is most definitely not my fault. The user should be instructed to take the backtrace upstream to the URL of the package and report it in their bug tracker/mailing list. Even better, ABRT can file the bug directly upstream. I am willing to provide the information of upstream bug trackers/mailing lists for all of my packages.
This confusion has been going on for enough of release cycles already and I think it's time for FPC to step in and clarify what are the maintainers/packagers responsibility towards the Fedora community and it's user base to avoid any further rifts between QA members and maintainers.
Either reporters report directly upstream always or to our own bug tracking system which one is it?
JBG
On Thu, Nov 04, 2010 at 11:58:21PM +0000, "Jóhann B. Guðmundsson" wrote:
On 11/04/2010 10:22 PM, Orcan Ogetbil wrote:
2- ABRT should keep track of unresponsive users. If a user has an outstanding "needinfo?" flag for the bugs sent through ABRT, he shouldn't be able to send a new bug report through ABRT for my packages.
Since this has turned into general pony request to the ABRT I shall throw in one for the reporters
On behalf of all reporters that have never received a response from a maintainer on a component they have reported against I not only ask the ABRT maintainers to block any reports against those component that a maintainer has not responded but I also request that those components get removed from bugzilla.redhat.com.
3- Ability to turn off ABRT for certain packages. Whenever I provide an application package with no nonstandard patches and there is a crash, it is most definitely not my fault. The user should be instructed to take the backtrace upstream to the URL of the package and report it in their bug tracker/mailing list. Even better, ABRT can file the bug directly upstream. I am willing to provide the information of upstream bug trackers/mailing lists for all of my packages.
This confusion has been going on for enough of release cycles already and I think it's time for FPC to step in and clarify what are the maintainers/packagers responsibility towards the Fedora community and it's user base to avoid any further rifts between QA members and maintainers.
This one's fesco, not fpc. (Policy about maintaining packages rather than how to create quality packages).
Perhaps a slightly easier to implement method of achieving something similar would be to orphan packages that have ignored bug reports rather than to remove their bugzilla components.
-Toshio
On Thu, Nov 4, 2010 at 7:04 PM, Jiri Moskovcak wrote:
So to sum it up, the fastest solution I can provide for you is to blacklist your packages and/or ask for at least some text in steps to reproduce.
That would be an excellent start. Thank you for spending your time on this.
Orcan
On Thu, 04 Nov 2010 16:10:17 -0400, Matt McCutchen wrote:
On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote:
The practical point is that F12 is about to go EOL which means the bug must be closed...
Why? Obviously it needs to be clear that nothing further should be expected from the maintainer unless/until the version is bumped. But the project can choose to indicate that by closing the bugs as WONTFIX or some other way, e.g., another resolution or by customizing Bugzilla to show a notice on bugs that are open against an EOL version of Fedora. Personally, I dislike the use of WONTFIX because philosophically I think it doesn't fit, and practically it makes zapped bugs impossible to distinguish from real WONTFIX bugs in searches (https://bugzilla.redhat.com/show_bug.cgi?id=528319).
This is my problem with the auto closing also. Leaving a bug open allows a more dedicated maintainer to come along (even years later) and actually fix or even apply patches that are still relevant without wasting time with bugs that we're actually looked at and legitimately closed.
Years later pretty much every bug will be irrelevant thanks to the underlying changes that happen with every release and asking submitters to verify that the bug is still there is the right way to go. After all 8 out of 10 abrt submitted bugs against Eclipse stays months with questions and needinfo flags and no response from submitters. Note that I'm not saying these bugs shouldn't be submitted sometimes even just because for the 2 submitters that answer questions but I definitely don't want to waste my time closing the rest of them. "Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. " This is the best we can do no matter what we want to do!
P.S. Believe me having open bugs that both the packager and the submitter care for are useless and these are the kind of bugs that get auto closed. If one of them cares he will change the version flag. Oh and looking at a list of hundreds bugs makes things close to impossible to put priorities, fix and improve the situation.
Alexander Kurtakov
On Thu, 04 Nov 2010 16:10:17 -0400, Matt McCutchen wrote:
On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote:
The practical point is that F12 is about to go EOL which means the bug must be closed...
Why? Obviously it needs to be clear that nothing further should be expected from the maintainer unless/until the version is bumped. But the project can choose to indicate that by closing the bugs as WONTFIX or some other way, e.g., another resolution or by customizing Bugzilla to show a notice on bugs that are open against an EOL version of Fedora. Personally, I dislike the use of WONTFIX because philosophically I think it doesn't fit, and practically it makes zapped bugs impossible to distinguish from real WONTFIX bugs in searches (https://bugzilla.redhat.com/show_bug.cgi?id=528319).
This is my problem with the auto closing also. Leaving a bug open allows a more dedicated maintainer to come along (even years later) and actually fix or even apply patches that are still relevant without wasting time with bugs that we're actually looked at and legitimately closed.
Years later pretty much every bug will be irrelevant thanks to the underlying changes that happen with every release and asking submitters to verify that the bug is still there is the right way to go. After all 8 out of 10 abrt submitted bugs against Eclipse stays months with questions and needinfo flags and no response from submitters. Note that I'm not saying these bugs shouldn't be submitted sometimes even just because for the 2 submitters that answer questions but I definitely don't want to waste my time closing the rest of them. "Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. " This is the best we can do no matter what we want to do!
P.S. Believe me having open bugs that both the packager and the submitter
DON'T care for (sorry for the typo)
care for are useless and these are the kind of bugs that get auto closed. If one of them cares he will change the version flag. Oh and looking at a list of hundreds bugs makes things close to impossible to put priorities, fix and improve the situation.
Alexander Kurtakov
On Thu, Nov 04, 2010 at 11:58:21PM +0000, "Jóhann B. Guðmundsson" wrote:
On 11/04/2010 10:22 PM, Orcan Ogetbil wrote:
2- ABRT should keep track of unresponsive users. If a user has an outstanding "needinfo?" flag for the bugs sent through ABRT, he shouldn't be able to send a new bug report through ABRT for my packages.
Since this has turned into general pony request to the ABRT I shall throw in one for the reporters
On behalf of all reporters that have never received a response from a maintainer on a component they have reported against I not only ask the ABRT maintainers to block any reports against those component that a maintainer has not responded but I also request that those components get removed from bugzilla.redhat.com.
3- Ability to turn off ABRT for certain packages. Whenever I provide an application package with no nonstandard patches and there is a crash, it is most definitely not my fault. The user should be instructed to take the backtrace upstream to the URL of the package and report it in their bug tracker/mailing list. Even better, ABRT can file the bug directly upstream. I am willing to provide the information of upstream bug trackers/mailing lists for all of my packages.
This confusion has been going on for enough of release cycles already and I think it's time for FPC to step in and clarify what are the maintainers/packagers responsibility towards the Fedora community and it's user base to avoid any further rifts between QA members and maintainers.
This one's fesco, not fpc. (Policy about maintaining packages rather than how to create quality packages).
Perhaps a slightly easier to implement method of achieving something similar would be to orphan packages that have ignored bug reports rather than to remove their bugzilla components.
So what if I got 100 bug reports and didn't answered 10 bugs you will want to orphan my package? Welcome to the world without gtk, openjdk, eclipse-platform, kdelibs ....
I can't see why can't we just admit - This is our best feel free to join us and help ?? (someone should find better wording)
Alex
-Toshio
On 05/11/10 07:27, Alexander Kurtakov wrote:
So what if I got 100 bug reports and didn't answered 10 bugs you will want to orphan my package? Welcome to the world without gtk, openjdk, eclipse-platform, kdelibs ....
I think maybe it is meant more as "You have 100 bugs, 80 are not acknowledged.
I can't see why can't we just admit - This is our best feel free to join us and help ?? (someone should find better wording)
Is this not where added manpower can help? At least a group who can be put together (existing?), to look at reproducing\unable to bugs, to help the maintainers.
Just a thought.
On 11/05/2010 07:47 AM, Frank Murphy wrote:
On 05/11/10 07:27, Alexander Kurtakov wrote:
So what if I got 100 bug reports and didn't answered 10 bugs you will want to orphan my package? Welcome to the world without gtk, openjdk, eclipse-platform, kdelibs ....
I think maybe it is meant more as "You have 100 bugs, 80 are not acknowledged.
I can't see why can't we just admit - This is our best feel free to join us and help ?? (someone should find better wording)
Is this not where added manpower can help? At least a group who can be put together (existing?), to look at reproducing\unable to bugs, to help the maintainers.
We already have QA dedicated group to aid maintainers and it's called triagers and a whole range off testers which can be pinged on irc or on the test-list even for a period of time we had a automatic responce reply to all bugs which was to "lower" the expectation of new/inexperienced reporters but it did not fix the underlying problem..
Reports came in --><-- Auto responce reply back to the reporter --> QA verified try to duplicate bug --> Bug set to maintainer --> Bug stayed like that until EOL....
We have had watercooler discussion on irc amongs ourself in QA on and off through several release cycles now to assign or ask a tester/triager to spesific components which have an actual maintainer behind them ( not speaking about packagers here ) to take the load of develepers and in some cases testers have done so on their own initiative because they just love the application they are running as a potentiall solution but we have not written anything down or come up with some concrete plan to aim at and work on.
One of the problem to solve with that is how we can equally cover all componets since we fear that users would cherry pick and jump on the component they love and leave more underthehood critical components out.
Basically popular component nr1 has 30 testers/triager while more vital critical component nr1 has 0..
Perhaps assign/rotate method would work in this case users a and b assign to component a this day/week while c and d take care of component b but as I mentioned all of this is just more or less ideas in our heads and have been so for a while.
Ofcourse this would only apply to responsive ( upstream ) maintainers but not packagers and unresponsive maintainers since nonresponsive maintainer is still a nonresponsive maintainer and spending anykind of community resources on them is just a waste of everbodys time..
QA service like this might actually attract more upstream developer to participate and join the project.
JBG
Frank Murphy said the following on 11/05/2010 12:47 AM Pacific Time:
On 05/11/10 07:27, Alexander Kurtakov wrote:
So what if I got 100 bug reports and didn't answered 10 bugs you will want to orphan my package? Welcome to the world without gtk, openjdk, eclipse-platform, kdelibs ....
I think maybe it is meant more as "You have 100 bugs, 80 are not acknowledged.
I can't see why can't we just admit - This is our best feel free to join us and help ?? (someone should find better wording)
Is this not where added manpower can help? At least a group who can be put together (existing?), to look at reproducing\unable to bugs, to help the maintainers.
We've been trying to do that and get it off the ground for several years. It hasn't exactly flourished.
DISCLAIMER: I'm not a package maintainer, but I have been involved with bug triage and was around the original effort to get Fedora bugzilla under control.
I've always believed our core need is more maintainers if the goal is *fixing* and *resolving* bugs. Triage and debugging help only goes so far.
It took several posts to devel-announce, personal emails, and weekly meetings during the roll up to Alpha, Beta, and Final, just to get information and help with ~20 blocker bugs. Addressing ~12,000 other open bugs will require something different.
John
Orcan Ogetbil, Wed, 03 Nov 2010 21:02:02 -0400:
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is.
From what I have seen, the maintainers are more responsive to manually filed bugs than to ABRT filed bugs (Am I wrong?). Apparently the current setup is driving users (such as the person in the above email) away who are otherwise willing to report bugs. This is not good.
Have you ever tried to explain to reporter that he need to reproduce the crash (which he has no idea how to do in the first place), then generate the backtrace using gdb? I did, many times, and I think ABRT is a great idea. Except for those duplicates ....
I believe that abrt's ability to find duplicates got much better lately, so it might be possible we will get another avalanche of closing ABRT bugs when F13 will go out EOS, but I believe it got much better in F14.
Best,
Matěj
On 11/05/2010 05:41 PM, Matej Cepl wrote:
Orcan Ogetbil, Wed, 03 Nov 2010 21:02:02 -0400:
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is.
From what I have seen, the maintainers are more responsive to manually filed bugs than to ABRT filed bugs (Am I wrong?). Apparently the current setup is driving users (such as the person in the above email) away who are otherwise willing to report bugs. This is not good.
Have you ever tried to explain to reporter that he need to reproduce the crash (which he has no idea how to do in the first place), then generate the backtrace using gdb? I did,
ABRT doesn't.
It doesn't tell the user that core dumps without reproducer are worthless in most cases but blindly sends out reports
Also, this produces incomplete traceback in many (IMO all) cases.
many times, and I think ABRT is a great idea.
I beg to differ ... It's an interesting idea, but still has to prove its viability and sustainability. I for one am having strong doubts.
Except for those duplicates ....
... and its arcane GUI
... and it being useless without GBs of spare diskspace and bandwidth [I just had a nautilus crash ... ABRT wanted to install ca. 100 debug infos. Please understand why I dod not report this crash]
... and it confronting/molesting un-educated/ordinary users who are not able or interested to cope with ABRT/bugzilla etc. [Do you expect a secretary for who Firefox just crashed to be wanting a redhat bugzilla account?]
... and many many other details.
Ralf
On Thu, 04 Nov 2010 09:38:35 -0700, Adam wrote:
On Thu, 2010-11-04 at 13:28 +0100, Michael Schwendt wrote:
So can someone please explain my why I should continue to try to improve Fedora by reporting bugs ?
Glad you ask this. The bugzapping script is stupid. It asks the reporter for NEEDINFO when in fact it ought to ask WTF has the packager not responded since Fedora 12?
you're looking at it through a 'moral' framework when the important thing is the 'practical' framework. :) The practical point is that F12 is about to go EOL which means the bug must be closed...
It is inefficient, if some time later another user needs to report the same issue only to get ignored, too. It is not encouraging our users to spend time on reporting bugs and on replying to NEEDINFO or other questions in the tickets. The warning that the ticket may be closed could have been given _much_ earlier, e.g. after two months of silence with no reply from the maintainer(s). Or at release time of F(N+1) Beta. Much worse if it's the second time a ticket is closed because of EOL. It's just poor form to ignore a user's bug report completely. I've received bugzapping mails for various issues, including packaging mistakes that have not been examined since F12. For example: http://bugzilla.redhat.com/516352
UNLESS it's still present in later releases. It's the reporter who is most likely to be able to say whether it is, therefore, we ask the user to check and update the bug, not the maintainer.
This is ridiculous because of very poor timing and because bugs may not always be reproducible. What makes you think the reporter can find the free time to handle a flood of EOL tickets?
It may be 'fairer' to set needinfo maintainer, but the result sure wouldn't be as good in practical terms, because the maintainer is less likely than the user to actually be able/inclined to provide the required data.
I'd like to see the list of Fedora packages, which are under-maintained and actually suffer from issues, which are not fixed by the Fedora Project and are not fixed in the upstream code base either (because a packager doesn't even forward problem reports to upstream trackers or because upstream development doesn't get rid of defects "magically" with lots of code rewrites).
On 11/04/2010 06:22 PM, Orcan Ogetbil wrote:
2- ABRT should keep track of unresponsive users. If a user has an outstanding "needinfo?" flag for the bugs sent through ABRT, he shouldn't be able to send a new bug report through ABRT for my packages.
That's a little harsh---I have been in situation when I couldn't reply to a 'needinfo' because e.g. I upgraded in the meantime, or I'd have to reboot to a different kernel or something like that.
I think it's OK to close the bug if 'needinfo' is several weeks old. Would that satisfy your needs?
On Thu, 2010-11-04 at 16:10 -0400, Matt McCutchen wrote:
On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote:
The practical point is that F12 is about to go EOL which means the bug must be closed...
Why? Obviously it needs to be clear that nothing further should be expected from the maintainer unless/until the version is bumped. But the project can choose to indicate that by closing the bugs as WONTFIX or some other way,
That's, um, exactly the process we're discussing here. We close all bugs for a given release when that release goes EOL. (I forget what resolution is used, it may well be WONTFIX). We send a warning note to all bugs that will be closed under this process, a short while before they're closed, so the reporters can check if they exist in a newer version and bump the report to that version to keep it open, if they like.
On Thu, 2010-11-04 at 17:49 -0400, Orcan Ogetbil wrote:
On Thu, Nov 4, 2010 at 1:51 AM, Peter Lemenkov wrote:
2010/11/4 Orcan Ogetbil :
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is.
No need to discuss - it's really useful. I recently closed several issues with the aid of stacktaces sent by ABRT.
I am very happy that the current scheme works well for you. You think that we should ignore the outstanding 93% of the ABRT bug reports, and the 6000 untouched bugs that will be closed in a month. If we don't do anything that 6000 will multiply at the end of the F-13 cycle.
Well, so what? So a bunch of bug reports got filed, didn't lead to any changes, and then got closed. I mean, I guess looked at from a certain angle it's 'inefficient', but I don't think we're hitting any particular resource constraints in terms of Bugzilla use at this point.
On Fri, 2010-11-05 at 07:27 -0700, John Poelstra wrote:
Frank Murphy said the following on 11/05/2010 12:47 AM Pacific Time:
On 05/11/10 07:27, Alexander Kurtakov wrote:
So what if I got 100 bug reports and didn't answered 10 bugs you will want to orphan my package? Welcome to the world without gtk, openjdk, eclipse-platform, kdelibs ....
I think maybe it is meant more as "You have 100 bugs, 80 are not acknowledged.
I can't see why can't we just admit - This is our best feel free to join us and help ?? (someone should find better wording)
Is this not where added manpower can help? At least a group who can be put together (existing?), to look at reproducing\unable to bugs, to help the maintainers.
We've been trying to do that and get it off the ground for several years. It hasn't exactly flourished.
Right. This is:
https://fedoraproject.org/wiki/BugZappers
as John says, it's been around for a while. Both John and I have tried to drive it to some extent. But it just doesn't get a lot of people who are really committed to doing the work. The fact that the work is often boring and generally not much use to the person doing the work him/herself, directly, contributes to this.
On Fri, 2010-11-05 at 18:29 +0100, Michael Schwendt wrote:
It is inefficient, if some time later another user needs to report the same issue only to get ignored, too. It is not encouraging our users to spend time on reporting bugs and on replying to NEEDINFO or other questions in the tickets. The warning that the ticket may be closed could have been given _much_ earlier, e.g. after two months of silence with no reply from the maintainer(s). Or at release time of F(N+1) Beta. Much worse if it's the second time a ticket is closed because of EOL. It's just poor form to ignore a user's bug report completely. I've received bugzapping mails for various issues, including packaging mistakes that have not been examined since F12. For example: http://bugzilla.redhat.com/516352
Closing the bug *isn't* ignoring it. Leaving it open and doing exactly nothing about it, which is what would happen if we didn't auto-close bugs, is ignoring it. If the bug hasn't had any attention for the last year and a half it's not particularly likely to magically get it now, is it?
If we don't auto-close bugs we wind up with a huge pile of ancient bugs which just gets in the way of people who want to come along and actually clean up the bug list for a package. It's harder to do that if you're looking at reports from the Stone Age.
UNLESS it's still present in later releases. It's the reporter who is most likely to be able to say whether it is, therefore, we ask the user to check and update the bug, not the maintainer.
This is ridiculous because of very poor timing
John always posts the schedule for housekeeping tasks to test list (I think possibly devel list too, I forget) and asks for feedback. He never seems to get any.
and because bugs may not always be reproducible. What makes you think the reporter can find the free time to handle a flood of EOL tickets?
I don't think they always will, but the alternative is worse. If the bug's not reproducible, how is anyone going to fix it? Or know that it's been fixed?
It may be 'fairer' to set needinfo maintainer, but the result sure wouldn't be as good in practical terms, because the maintainer is less likely than the user to actually be able/inclined to provide the required data.
I'd like to see the list of Fedora packages, which are under-maintained and actually suffer from issues, which are not fixed by the Fedora Project and are not fixed in the upstream code base either (because a packager doesn't even forward problem reports to upstream trackers or because upstream development doesn't get rid of defects "magically" with lots of code rewrites).
And I'd like a gold-plated pony. If you'd like to see the list, why not create it? I don't think anyone else has it lying around just ready to produce on demand.
(Unless there was meant to be a second part to this sentence and you got lost somewhere in the middle :>)
On Fri, 2010-11-05 at 13:48 -0400, Przemek Klosowski wrote:
On 11/04/2010 06:22 PM, Orcan Ogetbil wrote:
2- ABRT should keep track of unresponsive users. If a user has an outstanding "needinfo?" flag for the bugs sent through ABRT, he shouldn't be able to send a new bug report through ABRT for my packages.
That's a little harsh---I have been in situation when I couldn't reply to a 'needinfo' because e.g. I upgraded in the meantime, or I'd have to reboot to a different kernel or something like that.
But you can reply to needinfo in these cases. You can reply by saying 'sorry, I'm no longer able to test this, we'd better close it'.
On Fri, 05 Nov 2010 12:30:41 -0700, Adam wrote:
If the bug hasn't had any attention for the last year and a half it's not particularly likely to magically get it now, is it?
Then why should the reporter take action in reply to the NEEDINFO bugzapping request?
Something is terribly wrong here, if reporter adjusts F12 -> F13 -> F14 over a period of N months in reply to the automated NEEDINFO requests and still doesn't get any response other than another automated one after six more months.
John always posts the schedule for housekeeping tasks to test list (I think possibly devel list too, I forget) and asks for feedback. He never seems to get any.
Look in the archives. It's not the first time I've criticized what this bugzapping script does. It has stopped me from filing lots of issues, both with regard to packaging bugs as well as other problems, because I simply cannot handle the flood of NEEDINFO requests. If I remember correctly, this predates your involvement in Fedora. (And John comes up with so much stuff, hardly anyone will handle it anyway.)
If the bug's not reproducible, how is anyone going to fix it? Or know that it's been fixed?
Praise ABRT! In many cases, complete backtraces in conjunction with the source code reveal programming errors - sometimes embarassing ones. Not always, but if nobody skims over the problem reports, nobody can tell whether a reported bug is interesting or not.
I'd like to see the list of Fedora packages, which are under-maintained and actually suffer from issues, which are not fixed by the Fedora Project and are not fixed in the upstream code base either (because a packager doesn't even forward problem reports to upstream trackers or because upstream development doesn't get rid of defects "magically" with lots of code rewrites).
And I'd like a gold-plated pony. If you'd like to see the list, why not create it? I don't think anyone else has it lying around just ready to produce on demand.
(Unless there was meant to be a second part to this sentence and you got lost somewhere in the middle :>)
The sentence is complete. Probably writing it was wasted time, because apparently *you* are not interested in feedback or in ideas, which might be more helpful than hiding bugs under the carpet.
On Fri, 2010-11-05 at 21:37 +0100, Michael Schwendt wrote:
On Fri, 05 Nov 2010 12:30:41 -0700, Adam wrote:
If the bug hasn't had any attention for the last year and a half it's not particularly likely to magically get it now, is it?
Then why should the reporter take action in reply to the NEEDINFO bugzapping request?
Something is terribly wrong here, if reporter adjusts F12 -> F13 -> F14 over a period of N months in reply to the automated NEEDINFO requests and still doesn't get any response other than another automated one after six more months.
So, what's your alternative?
John always posts the schedule for housekeeping tasks to test list (I think possibly devel list too, I forget) and asks for feedback. He never seems to get any.
Look in the archives. It's not the first time I've criticized what this bugzapping script does. It has stopped me from filing lots of issues, both with regard to packaging bugs as well as other problems, because I simply cannot handle the flood of NEEDINFO requests. If I remember correctly, this predates your involvement in Fedora. (And John comes up with so much stuff, hardly anyone will handle it anyway.)
Yes, we've been doing it for a while. I keep saying it's not perfect. But what's your alternative? The underlying problem here is the one everyone knows about: we don't have enough manpower to fix all bugs. Given that, why is it better to leave them rotting away for years than to close them?
If the bug's not reproducible, how is anyone going to fix it? Or know that it's been fixed?
Praise ABRT! In many cases, complete backtraces in conjunction with the source code reveal programming errors - sometimes embarassing ones. Not always, but if nobody skims over the problem reports, nobody can tell whether a reported bug is interesting or not.
Well, in the abrt thread we have someone arguing that abrt reports are almost always useless without steps to reproduce (their words, not mine)...clearly, everyone doesn't agree here.
I'd like to see the list of Fedora packages, which are under-maintained and actually suffer from issues, which are not fixed by the Fedora Project and are not fixed in the upstream code base either (because a packager doesn't even forward problem reports to upstream trackers or because upstream development doesn't get rid of defects "magically" with lots of code rewrites).
And I'd like a gold-plated pony. If you'd like to see the list, why not create it? I don't think anyone else has it lying around just ready to produce on demand.
(Unless there was meant to be a second part to this sentence and you got lost somewhere in the middle :>)
The sentence is complete. Probably writing it was wasted time, because apparently *you* are not interested in feedback or in ideas, which might be more helpful than hiding bugs under the carpet.
Saying 'I want someone to make this list so I can look at it' isn't really useful feedback or ideas, it's demanding someone else do work on your behalf. Which historically speaking is not the best way to make sure it gets done.
I have trouble parsing that sentence, my eyes glaze out somewhere in the middle of the fourth line, but if I'm reading it right, you want a list of packages for which our track record of fixing bugs is not great, right? Okay, supposing we make such a list, what is it you want to do with it?
On Fri, 05 Nov 2010 17:56:51 +0100, Ralf wrote:
ABRT
It doesn't tell the user that core dumps without reproducer are worthless in most cases but blindly sends out reports
Parts of the Fedora user base "abuse" ABRT in that they refuse to fill in the empty fields. Blame the reporters not the tool. It's too easy for such people to open tickets via ABRT and then ignore a maintainer's NEEDINFO request. It's disheartening in some cases, but it's a people-problem not a tool-problem.
Also, this produces incomplete traceback in many (IMO all) cases.
Cannot confirm that. There seem to be some issues with not finding the needed debuginfo packages, which may be related to frequent updates of repos and older packages getting pruned. It may also be related to users updating their boxes at strange times, e.g. seldomly but immediately after a crash.
On Thu, 04 Nov 2010 23:05:01 +0100, Jiri wrote:
- if you think ABRT is not providing a good info for you packages, then
please write me an email how to improve it
Could you please add another hurdle that tries to stop users from not filling in the empty fields about how to reproduce a problem? Backtraces [plus the source code] can tell a tale, but they are not always sufficient. And a bit of background about what caused an app to malfunction can be very helpful. Fedora users need to understand that.
On Fri, Nov 5, 2010 at 4:53 PM, Michael Schwendt wrote:
On Thu, 04 Nov 2010 23:05:01 +0100, Jiri wrote:
- if you think ABRT is not providing a good info for you packages, then
please write me an email how to improve it
Could you please add another hurdle that tries to stop users from not filling in the empty fields about how to reproduce a problem? Backtraces [plus the source code] can tell a tale, but they are not always sufficient. And a bit of background about what caused an app to malfunction can be very helpful. Fedora users need to understand that.
+1
To the above I should add, in many cases, I need the full list of packages (with version-release) that are installed in the user's system. Please add this too.
Thanks, Orcan
On Thu, 04 Nov 2010 23:58:21 +0000, Jóhann wrote:
On behalf of all reporters that have never received a response from a maintainer on a component they have reported against I not only ask the ABRT maintainers to block any reports against those component that a maintainer has not responded but I also request that those components get removed from bugzilla.redhat.com.
Weird idea. Not sure it's worth commenting on it. The problem with maintainers not responding to some tickets can have multiple reasons. Some components literally are flooded with new tickets. Hundreds. Thousands. It's obvious that they all cannot be processed other than by scripts. For other components, the maintainer may be occupied with many packages but one. And still the one package may be updated regularly with upstream releases that include fixes for various issues. It's just the bugzilla grunt work that's not done for that package. Interesting would be to determine the packages that are [somewhat] neglected with regard to incoming tickets because of no spare time to take care of them.
Much more interesting would be to determine those maintainers, who seem to neglect all of most of their bugzilla tickets for all or most of their packages.
On Fri, 5 Nov 2010 09:27:46 +0200, Alexander wrote:
I can't see why can't we just admit - This is our best feel free to join us and help ?? (someone should find better wording)
Yeah. It isn't that obvious to our users (and potential contributors among them) where help is needed, where help would be accepted (possibly up to the point of becoming an official Fedora Contributor with commit access), or whether a lack of response is just temporary due to priorities.
On Fri, 05 Nov 2010 13:45:37 -0700, Adam wrote:
Something is terribly wrong here, if reporter adjusts F12 -> F13 -> F14 over a period of N months in reply to the automated NEEDINFO requests and still doesn't get any response other than another automated one after six more months.
So, what's your alternative?
To keep them open, so as they get older and they continue to affect users, they could be moved up from the bottom of somebody's TODO list.
If they get closed, much is lost including test-case attachments, comments, links. Eventually somebody will open a new ticket for F15 and point out that the package is broken since F8.
The underlying problem here is the one everyone knows about: we don't have enough manpower to fix all bugs. Given that, why is it better to leave them rotting away for years than to close them?
Better would be to fix the bug in the software/package and remove the cause of new tickets or dupes created by ABRT. Who can tell whether lack of response is really due to lack of manpower? And not due to other factors?
For example, there's a crash in librsvg2, which affects multiple apps that use this library, including Nautilus. There have been multiple reports about it. Including an upstream ticket created by me. Including a comment on what is wrong in the source and what would be a work-around. No response so far. http://bugzilla.redhat.com/553069 Other tickets for the same issue are in EOL NEEDINFO state meanwhile. For me, even with provenpackager access, it's not clear how to proceed even if the issue affects one of my packages, too. And whereas I would fix such an issue in my own packages, there are lengthy documents like https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages that make me insecure.
[...], you want a list of packages for which our track record of fixing bugs is not great, right? Okay, supposing we make such a list, what is it you want to do with it?
Not right. I (and to the best of my knowledge also other packagers I've talked to) could use such a list and look for packages that need help. Based on actual statistics instead of randomly poking in bugzilla or in bugz.fedoraproject.org pages.
On Fri, 2010-11-05 at 23:09 +0100, Michael Schwendt wrote:
On Fri, 05 Nov 2010 13:45:37 -0700, Adam wrote:
Something is terribly wrong here, if reporter adjusts F12 -> F13 -> F14 over a period of N months in reply to the automated NEEDINFO requests and still doesn't get any response other than another automated one after six more months.
So, what's your alternative?
To keep them open, so as they get older and they continue to affect users, they could be moved up from the bottom of somebody's TODO list.
How are we to know they continue to affect users?
If they get closed, much is lost including test-case attachments, comments, links. Eventually somebody will open a new ticket for F15 and point out that the package is broken since F8.
It's not lost, it's all there; the bug is just marked CLOSED. It can be re-opened if it turns out to be necessary. People file new bugs without looking for duplicates all the time anyway. We usually only catch dupes through triage efforts or through the developer noticing that a bug looks like an older one.
The underlying problem here is the one everyone knows about: we don't have enough manpower to fix all bugs. Given that, why is it better to leave them rotting away for years than to close them?
Better would be to fix the bug in the software/package and remove the cause of new tickets or dupes created by ABRT. Who can tell whether lack of response is really due to lack of manpower? And not due to other factors?
we've only had abrt for a short time; we've had the EOL process much longer. We wouldn't suddenly stop needing the EOL process if abrt wasn't around.
lack of manpower is the ultimate explanation for lack of attention to bugs whenever I've gone to the trouble of tracking down an explanation. What other explanation would you posit?
For example, there's a crash in librsvg2, which affects multiple apps that use this library, including Nautilus. There have been multiple reports about it. Including an upstream ticket created by me. Including a comment on what is wrong in the source and what would be a work-around. No response so far. http://bugzilla.redhat.com/553069 Other tickets for the same issue are in EOL NEEDINFO state meanwhile. For me, even with provenpackager access, it's not clear how to proceed even if the issue affects one of my packages, too. And whereas I would fix such an issue in my own packages, there are lengthy documents like https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages that make me insecure.
None of this feels like it has much to do with the EOL process. How exactly would changing the EOL process help this?
[...], you want a list of packages for which our track record of fixing bugs is not great, right? Okay, supposing we make such a list, what is it you want to do with it?
Not right. I (and to the best of my knowledge also other packagers I've talked to) could use such a list and look for packages that need help. Based on actual statistics instead of randomly poking in bugzilla or in bugz.fedoraproject.org pages.
okay, so that's a sensible idea. It wasn't at all obvious, to me anyway, from your initial post :)
On Fri, 05 Nov 2010 09:14:08 +0200, Alexander Kurtakov wrote:
On Thu, 04 Nov 2010 16:10:17 -0400, Matt McCutchen wrote:
On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote:
The practical point is that F12 is about to go EOL which means the bug must be closed...
Why? Obviously it needs to be clear that nothing further should be expected from the maintainer unless/until the version is bumped. But the project can choose to indicate that by closing the bugs as WONTFIX or some other way, e.g., another resolution or by customizing Bugzilla to show a notice on bugs that are open against an EOL version of Fedora. Personally, I dislike the use of WONTFIX because philosophically I think it doesn't fit, and practically it makes zapped bugs impossible to distinguish from real WONTFIX bugs in searches (https://bugzilla.redhat.com/show_bug.cgi?id=528319).
This is my problem with the auto closing also. Leaving a bug open allows a more dedicated maintainer to come along (even years later) and actually fix or even apply patches that are still relevant without wasting time with bugs that we're actually looked at and legitimately closed.
Years later pretty much every bug will be irrelevant thanks to the underlying changes that happen with every release and asking submitters to verify that the bug is still there is the right way to go. After all 8 out of 10 abrt submitted bugs against Eclipse stays months with questions and needinfo flags and no response from submitters. Note that I'm not saying these bugs shouldn't be submitted sometimes even just because for the 2 submitters that answer questions but I definitely don't want to waste my time closing the rest of them. "Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. " This is the best we can do no matter what we want to do!
P.S. Believe me having open bugs that both the packager and the submitter care for are useless and these are the kind of bugs that get auto closed. If one of them cares he will change the version flag. Oh and looking at a list of hundreds bugs makes things close to impossible to put priorities, fix and improve the situation.
I understand what your saying. After some consideration, my issues are:
1. I don't respond to autobots. 2. If the maintainer doesn't care, I don't care. Thus I'm not gonna tick of some version flag or something.
I think what would help moving forward, (without having to do away with the autobots, which I welcome) is what Matt said... that the autobots did not "CLOSE", but had some different status, such as: "AUTO-CLOSED".
On 11/05/2010 09:46 PM, Michael Schwendt wrote:
On Fri, 05 Nov 2010 17:56:51 +0100, Ralf wrote:
ABRT
It doesn't tell the user that core dumps without reproducer are worthless in most cases but blindly sends out reports
Parts of the Fedora user base "abuse" ABRT in that they refuse to fill in the empty fields. Blame the reporters not the tool.
A matter of point of view: To me this is an ABRT GUI issue. It currently doesn't suck as much as it did before, nevertheless its usability still leaves much to be desired.
As yourself: What would you do if you were a "simple computer user" and are facing this "flash bulb icon" asking you to become "root" and to get a bugzilla account?
You'd call your sys-admin, who'll deinstall or deactivate ABRT pretty soon, when you call him for the "Nth time". As a user you'd also think "what kind of crap is this Fedora/Linux - the WinXP I have at home is better".
It's too easy for such people to open tickets via ABRT and then ignore a maintainer's NEEDINFO request.
Correct - But the same applies to maintainers.
My experience is, most of them ignore ABRT reports, probably because the ABRT reports are not helpful to them and/or don't contain sufficient infos.
It's disheartening in some cases, but it's a people-problem not a tool-problem.
I disagree - IMO; ABRT is not end-user ready. It presumes end-users to be familiar with redhat's infrastructure, which is a developer infrastructure and them to be interested to get involved into Fedora development. This simply does not apply.
Also, this produces incomplete traceback in many (IMO all) cases.
Cannot confirm that.
In almost all cases, I am observing missting debuginfos even after executing debuginfo-installs.
There seem to be some issues with not finding the needed debuginfo packages, which may be related to frequent updates of repos and older packages getting pruned. It may also be related to users updating their boxes at strange times, e.g. seldomly but immediately after a crash.
Possible. This certainly this applies in some cases.
However, I am experiencing missing debuginfos after debuginfo-install even with what is supposed to be "uptodate" Fedora installations.
Ralf
On 11/05/2010 08:20 PM, Adam Williamson wrote:
On Thu, 2010-11-04 at 17:49 -0400, Orcan Ogetbil wrote:
On Thu, Nov 4, 2010 at 1:51 AM, Peter Lemenkov wrote:
2010/11/4 Orcan Ogetbil :
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is.
No need to discuss - it's really useful. I recently closed several issues with the aid of stacktaces sent by ABRT.
I am very happy that the current scheme works well for you. You think that we should ignore the outstanding 93% of the ABRT bug reports, and the 6000 untouched bugs that will be closed in a month. If we don't do anything that 6000 will multiply at the end of the F-13 cycle.
Well, so what? So a bunch of bug reports got filed, didn't lead to any changes, and then got closed.
According to the figures you sent earlier this week, ca. 93% of all ABRT reports can be expected to suffer this fate.
I mean, I guess looked at from a certain angle it's 'inefficient',
OK, I understand you are wanting to play down the issues ABRT has.
but I don't think we're hitting any particular resource constraints in terms of Bugzilla use at this point.
Why do you think are we discussing/arguing?
IMO, the primary underlaying problem we are disscussing here is "ARBT draining away too many resources".
Ralf
On 11/05/2010 10:06 PM, Michael Schwendt wrote:
On Thu, 04 Nov 2010 23:58:21 +0000, Jóhann wrote:
On behalf of all reporters that have never received a response from a maintainer on a component they have reported against I not only ask the ABRT maintainers to block any reports against those component that a maintainer has not responded but I also request that those components get removed from bugzilla.redhat.com.
Weird idea. Not sure it's worth commenting on it. The problem with maintainers not responding to some tickets can have multiple reasons. Some components literally are flooded with new tickets. Hundreds. Thousands.
These packages should be examined and analysed individually and consequences be drawn upon, if neccessary even if they might be unpleasant.
Ralf
On 11/06/2010 01:53 AM, Ralf Corsepius wrote:
On 11/05/2010 09:46 PM, Michael Schwendt wrote:
On Fri, 05 Nov 2010 17:56:51 +0100, Ralf wrote:
ABRT It doesn't tell the user that core dumps without reproducer are worthless in most cases but blindly sends out reports
Parts of the Fedora user base "abuse" ABRT in that they refuse to fill in the empty fields. Blame the reporters not the tool.
A matter of point of view: To me this is an ABRT GUI issue. It currently doesn't suck as much as it did before, nevertheless its usability still leaves much to be desired.
Agreed
It has been improving but is far from novice usage perfection but whether that is good or bad all boils down to the so called "Target user base"<sigh>.
As yourself: What would you do if you were a "simple computer user" and are facing this "flash bulb icon" asking you to become "root" and to get a bugzilla account?
You'd call your sys-admin, who'll deinstall or deactivate ABRT pretty soon, when you call him for the "Nth time". As a user you'd also think "what kind of crap is this Fedora/Linux - the WinXP I have at home is better".
The same problem here applies to all regardless of OS or Application.
If the entry level is to high or OS or Application give novice end user to much "in you face time" they replace it or find a way to silence the nuance one way or another.
It's too easy for such people to open tickets via ABRT and then ignore a maintainer's NEEDINFO request.
Correct - But the same applies to maintainers.
My experience is, most of them ignore ABRT reports, probably because the ABRT reports are not helpful to them and/or don't contain sufficient infos.
Same applies to human directly submitted report....
It's disheartening in some cases, but it's a people-problem not a tool-problem.
I disagree - IMO; ABRT is not end-user ready. It presumes end-users to be familiar with redhat's infrastructure, which is a developer infrastructure and them to be interested to get involved into Fedora development. This simply does not apply.
Again it all boils down to the so called "Target user base"....
JBG
On 11/06/2010 02:11 AM, Ralf Corsepius wrote:
On 11/05/2010 10:06 PM, Michael Schwendt wrote:
On Thu, 04 Nov 2010 23:58:21 +0000, Jóhann wrote:
On behalf of all reporters that have never received a response from a maintainer on a component they have reported against I not only ask the ABRT maintainers to block any reports against those component that a maintainer has not responded but I also request that those components get removed from bugzilla.redhat.com.
Weird idea. Not sure it's worth commenting on it. The problem with maintainers not responding to some tickets can have multiple reasons. Some components literally are flooded with new tickets. Hundreds. Thousands.
These packages should be examined and analysed individually and consequences be drawn upon, if neccessary even if they might be unpleasant
Agreed...
JBG
On Sat, 06 Nov 2010 04:17:59 +0000, Jóhann wrote:
On 11/06/2010 02:11 AM, Ralf Corsepius wrote:
On 11/05/2010 10:06 PM, Michael Schwendt wrote:
On Thu, 04 Nov 2010 23:58:21 +0000, Jóhann wrote:
On behalf of all reporters that have never received a response from a maintainer on a component they have reported against I not only ask the ABRT maintainers to block any reports against those component that a maintainer has not responded but I also request that those components get removed from bugzilla.redhat.com.
Weird idea. Not sure it's worth commenting on it. The problem with maintainers not responding to some tickets can have multiple reasons. Some components literally are flooded with new tickets. Hundreds. Thousands.
These packages should be examined and analysed individually and consequences be drawn upon, if neccessary even if they might be unpleasant
Agreed...
JBG
Agreeing doesn't fix the resource problems. For special packages, it's obvious.
http://bugz.fedoraproject.org/kernel 1374 bugs found
For others, it isn't.
http://bugz.fedoraproject.org/gftp 49 bugs found
But the bugzapping EOL script treats all packages equally, afaik. It would also kill off _the single one_ major crasher ticket for a maintainer's single package just because nobody replies in bugzilla.
On 11/06/2010 01:53 AM, Ralf Corsepius wrote:
On 11/05/2010 09:46 PM, Michael Schwendt wrote:
On Fri, 05 Nov 2010 17:56:51 +0100, Ralf wrote:
ABRT It doesn't tell the user that core dumps without reproducer are worthless in most cases but blindly sends out reports
Parts of the Fedora user base "abuse" ABRT in that they refuse to fill in the empty fields. Blame the reporters not the tool.
A matter of point of view: To me this is an ABRT GUI issue. It currently doesn't suck as much as it did before, nevertheless its usability still leaves much to be desired.
Agreed
It has been improving but is far from novice usage perfection but whether that is good or bad all boils down to the so called "Target user base"<sigh>.
As yourself: What would you do if you were a "simple computer user" and are facing this "flash bulb icon" asking you to become "root" and to get a bugzilla account?
You'd call your sys-admin, who'll deinstall or deactivate ABRT pretty
soon, when you call him for the "Nth time".
As a user you'd also think "what kind of crap is this Fedora/Linux -
the WinXP I have at home is better".
The same problem here applies to all regardless of OS or Application.
If the entry level is to high or OS or Application give novice end user to much "in you face time" they replace it or find a way to silence the nuance one way or another.
It's too easy for such people to open tickets via ABRT and then ignore a maintainer's NEEDINFO request.
Correct - But the same applies to maintainers.
My experience is, most of them ignore ABRT reports, probably because the ABRT reports are not helpful to them and/or don't contain sufficient infos.
Same applies to human directly submitted report....
It's disheartening in some cases, but it's a people-problem not a tool-problem.
I disagree - IMO; ABRT is not end-user ready. It presumes end-users to be familiar with redhat's infrastructure, which is a developer infrastructure and them to be interested to get involved into Fedora development. This simply does not apply.
Again it all boils down to the so called "Target user base"....
I wonder is there a single OS that targets a single user base??? And if we define a target user base - we will ditch everything else ? And are contributors that care for different target user base gonna be hound to stop contributing because Fedora Project doesn't care for their contributions?
Such ideas are way more terrible than a few bugreports didn't get responded.
P.S I'm really missing how defining a target user base won't hurt the project as a whole.
Alex
JBG
On Fri, 05 Nov 2010 15:15:36 -0700, Adam wrote:
On Fri, 2010-11-05 at 23:09 +0100, Michael Schwendt wrote:
On Fri, 05 Nov 2010 13:45:37 -0700, Adam wrote:
Something is terribly wrong here, if reporter adjusts F12 -> F13 -> F14 over a period of N months in reply to the automated NEEDINFO requests and still doesn't get any response other than another automated one after six more months.
So, what's your alternative?
To keep them open, so as they get older and they continue to affect users, they could be moved up from the bottom of somebody's TODO list.
How are we to know they continue to affect users?
As a first step, make sure the EOL script never closes a ticket more than once. If it closed it for F12 EOL, a user reassigns it to F13, and then the script closes it once more for F13 EOL, that should be seen as an early-warning system. Worse if a user reassigns it from F12 EOL to F14 or even Rawhide, and still it isn't dealt with for unknown reasons.
Further, it's common for users to create duplicates, or to add comments to existing bugzilla tickets, or to add themselves to the Cc field, or to bookmark bz links and visit them every once in a while. Somebody needs to take notice of such activity. The Fedora Wiki suggests that the package maintainers do.
Tools like ABRT search for duplicates or (if failing to find a dupe), open a NEW ticket for the same issue. A maintainer or triager, who skims over the stacktrace and categorizes a bz ticket (possibly changing the Subject line to something meaningful), could easily find the old ticket. The old ticket with users in Cc, perhaps useful comments or test-cases. Sometimes it takes weeks or months for someone to consider opening a new ticket, though. Why expect the maintainer to treat new tickets differently than old tickets for the same issue that lives on for months?
If they get closed, much is lost including test-case attachments, comments, links. Eventually somebody will open a new ticket for F15 and point out that the package is broken since F8.
It's not lost, it's all there; the bug is just marked CLOSED. It can be re-opened if it turns out to be necessary.
Who will be the expert to know how to find it? And who will have the necessary time to review closed tickets?
People file new bugs without looking for duplicates all the time anyway. We usually only catch dupes through triage efforts or through the developer noticing that a bug looks like an older one.
Exactly. And if incoming bug reports aren't triaged by anyone, closing tickets too early only falsifies the program's condition. A bug opened in 2010 will make it look like it may be a new bug, when in fact EOL scripts have killed old tickets for the same bug multiple times before.
lack of manpower is the ultimate explanation for lack of attention to bugs whenever I've gone to the trouble of tracking down an explanation. What other explanation would you posit?
- lack of interest - packager too lazy to forward issue upstream - packager not capable of fixing the bug or analyzing the problem - a crap code base (spaghetti-code, poor design, basic coding mistakes e.g.) - package only needed as a dependency - common mindshare among some people that bugzilla is a plague - a high personal package count as the ultimate goal, even if there's the risk that they aren't really maintained
It isn't obvious to users and other packagers.
For example, there's a crash in librsvg2, which affects multiple apps that use this library, including Nautilus. There have been multiple reports about it. Including an upstream ticket created by me. Including a comment on what is wrong in the source and what would be a work-around. No response so far. http://bugzilla.redhat.com/553069 Other tickets for the same issue are in EOL NEEDINFO state meanwhile. For me, even with provenpackager access, it's not clear how to proceed even if the issue affects one of my packages, too. And whereas I would fix such an issue in my own packages, there are lengthy documents like https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages that make me insecure.
None of this feels like it has much to do with the EOL process. How exactly would changing the EOL process help this?
How does closing the ticket help at all? There are test-case attachments as the problem is 100% reproducible. There is one work-around. And yet there is a lack of response and nothing about this in the Wiki. The Wiki page linked above just talks about "controversial fixes" or "matter of style" to raise doubts. This EOL process is too independent and ought to be linked with other procedures (orphans, retiring pkgs, non-responsive maintainers, call for volunteers, todo lists, cry for help).
On Sat, 06 Nov 2010 04:17:59 +0000, Jóhann wrote:
On 11/06/2010 02:11 AM, Ralf Corsepius wrote:
On 11/05/2010 10:06 PM, Michael Schwendt wrote:
On Thu, 04 Nov 2010 23:58:21 +0000, Jóhann wrote:
On behalf of all reporters that have never received a response from a maintainer on a component they have reported against I not only ask the ABRT maintainers to block any reports against those component that a maintainer has not responded but I also request that those components get removed from bugzilla.redhat.com.
Weird idea. Not sure it's worth commenting on it. The problem with maintainers not responding to some tickets can have multiple reasons. Some components literally are flooded with new tickets. Hundreds. Thousands.
These packages should be examined and analysed individually and consequences be drawn upon, if neccessary even if they might be unpleasant
Agreed...
JBG
Agreeing doesn't fix the resource problems. For special packages, it's obvious.
http://bugz.fedoraproject.org/kernel 1374 bugs found
For others, it isn't.
http://bugz.fedoraproject.org/gftp 49 bugs found
But the bugzapping EOL script treats all packages equally, afaik. It would also kill off _the single one_ major crasher ticket for a maintainer's single package just because nobody replies in bugzilla.
It's not going to "kill" the bug - it will ask the submitter to check whether the bug still applies to newer Fedora version. Why does everyone want to put more and more burden on maintainers and arguing about small things that users should do? How can you expect a maintainer to fix/respond to hundreds of bugs and not expect the user to verify his/her bug still applies?
Alex
On Sat, 6 Nov 2010 12:23:00 +0200, Alexander wrote:
How can you expect a maintainer to fix/respond to hundreds of bugs and not expect the user to verify his/her bug still applies?
Have you noticed how many ticket EOL warnings some users receive all of a sudden? They may be able to pay attention to one or a few, but not all. And if they reassign a few, how likely is it that there will be a response prior to next EOL?
On Sat, 6 Nov 2010 12:23:00 +0200, Alexander wrote:
How can you expect a maintainer to fix/respond to hundreds of bugs and not expect the user to verify his/her bug still applies?
Have you noticed how many ticket EOL warnings some users receive all of a sudden? They may be able to pay attention to one or a few, but not all. And if they reassign a few, how likely is it that there will be a response prior to next EOL?
Hmm, let's switch user with maintainer?
Have you noticed how many new tickets some maintainers receive all of a sudden? They may be able to pay attention to one or a few, but not all. And if the fix a few and ask for additional info on the others, how likely is it that there will be a response before they get their package updated and/or underlying library changes to make the bug needs retesting?
Do you see my point now?
Alex
On Sat, 6 Nov 2010 12:23:00 +0200, Alexander wrote:
How can you expect a maintainer to fix/respond to hundreds of bugs and not expect the user to verify his/her bug still applies?
Have you noticed how many ticket EOL warnings some users receive all of a sudden? They may be able to pay attention to one or a few, but not all. And if they reassign a few, how likely is it that there will be a response prior to next EOL?
Hmm, let's switch user with maintainer?
Have you noticed how many new tickets some maintainers receive all of a sudden? They may be able to pay attention to one or a few, but not all. And if the fix a few and ask for additional info on the others, how likely is it that there will be a response before they get their package updated and/or underlying library changes to make the bug needs retesting?
Do you see my point now?
Oh and I forgot to add this: If you think it is discouraging for the user do get his bug autoclosed, why do you think it is not discouraging for the maintainer to ask questions and noone answers them?
Alex
Alex
On Sat, Nov 06, 2010 at 01:36:24PM +0200, Alexander Kurtakov wrote:
On Sat, 6 Nov 2010 12:23:00 +0200, Alexander wrote:
How can you expect a maintainer to fix/respond to hundreds of bugs and not expect the user to verify his/her bug still applies?
Have you noticed how many ticket EOL warnings some users receive all of a sudden? They may be able to pay attention to one or a few, but not all. And if they reassign a few, how likely is it that there will be a response prior to next EOL?
Hmm, let's switch user with maintainer?
Have you noticed how many new tickets some maintainers receive all of a sudden? They may be able to pay attention to one or a few, but not all. And if
Maintainer do not usually receive lots of bugs within one or two days that they have to handle within one month.
Regards Till
On Sat, Nov 06, 2010 at 12:23:00PM +0200, Alexander Kurtakov wrote:
Why does everyone want to put more and more burden on maintainers and arguing about small things that users should do? How can you expect a maintainer to fix/respond to hundreds of bugs and not expect the user to verify his/her bug still applies?
I have no problem to verify a bug when the maintainer is ready to fix it. But it is pretty annoying to verify it within a small time window regularly just to have it ignored till the next EOL date. This has no benefit and is only a big waste of manpower which we do not have too much of. So for bug reporters that are also package maintainers, the productive time of these maintainers is reduced by this procedure.
Regards Till
On Sat, Nov 06, 2010 at 01:36:24PM +0200, Alexander Kurtakov wrote:
On Sat, 6 Nov 2010 12:23:00 +0200, Alexander wrote:
How can you expect a maintainer to fix/respond to hundreds of bugs and not expect the user to verify his/her bug still applies?
Have you noticed how many ticket EOL warnings some users receive all of a sudden? They may be able to pay attention to one or a few, but not all. And if they reassign a few, how likely is it that there will be a response prior to next EOL?
Hmm, let's switch user with maintainer?
Have you noticed how many new tickets some maintainers receive all of a sudden? They may be able to pay attention to one or a few, but not all. And if
Maintainer do not usually receive lots of bugs within one or two days that they have to handle within one month.
We can argue about this a lot (e.e. submitter can reopen bug whenever he finds the time to verify the bug). So the real problem is the notice period? Will it help if there is 6 weeks notice instead of 4? Any other idea?
Alex
Regards Till
On Sat, 6 Nov 2010 13:36:24 +0200, Alexander wrote:
Hmm, let's switch user with maintainer?
Have you noticed how many new tickets some maintainers receive all of a sudden?
In general or because of the EOL script creating a flood? ;)
Who classifies whether an incoming bug report is important or not? Right, the maintainer. If a maintainer seems to ignore a bug report due to time constraints or other factors, why should the reporter spend additional efforts on performing retests at all?
They may be able to pay attention to one or a few, but not all. And if the fix a few and ask for additional info on the others, how likely is it that there will be a response before they get their package updated and/or underlying library changes to make the bug needs retesting?
Do you see my point now?
No. Waiting six months before asking a bug reporter to retest N bugs with a different distribution release just doesn't fly. And if the bug reporter retests and confirms that a bug is still reproducible, does that make it more likely that there will be a fix? So far, it doesn't.
On Sat, 6 Nov 2010 13:38:36 +0200, Alexander wrote:
Oh and I forgot to add this: If you think it is discouraging for the user do get his bug autoclosed, why do you think it is not discouraging for the maintainer to ask questions and noone answers them?
Perhaps read my other replies where I commented on that. To sum up: I do think it is discouraging to see some bug reporters not react to NEEDINFO queries.
2010/11/6 Till Maas
On Sat, Nov 06, 2010 at 12:23:00PM +0200, Alexander Kurtakov wrote:
Why does everyone want to put more and more burden on maintainers and
arguing
about small things that users should do? How can you expect a maintainer to fix/respond to hundreds of bugs and
not
expect the user to verify his/her bug still applies?
I am an example of a user who sometimes send a report through ABRT but rarely replies in it, because I have no idea how to reproduce it. For example, if "randomly" (from my user point of view) Firefox or Empathy crashes, I suppose that the debug trace is enough for the author to see the problem. Unfortunately, if the maintainer asks me for more info, I will hardly be able to give it, because for me the crashes are random.
Sometimes I can guess a possible way of reproducing the bug, and then I add it as a comment in ABRT, but this is very strange.
So please, don't blame users for not replying bugs, because most of them will think that pushing the button (and waiting for all the debug packages to download) are enough work for them. Besides, most of them perhaps even don't speak English.
Sometimes I try to help finding duplicates, and I find bugs not detected automatically by ABRT because, although the trace is almost identical, the bug title is not, because the version of the package has changed a little. Perhaps this could be improved.
Sorry for the noise.
On 11/06/2010 02:53 AM, Ralf Corsepius wrote:
On 11/05/2010 09:46 PM, Michael Schwendt wrote:
On Fri, 05 Nov 2010 17:56:51 +0100, Ralf wrote:
ABRT
It doesn't tell the user that core dumps without reproducer are worthless in most cases but blindly sends out reports
Parts of the Fedora user base "abuse" ABRT in that they refuse to fill in the empty fields. Blame the reporters not the tool.
A matter of point of view: To me this is an ABRT GUI issue. It currently doesn't suck as much as it did before, nevertheless its usability still leaves much to be desired.
- please, send me some ideas or mockups and I will be more than happy to change the GUI... but just complaining "it sucks" doesn't give me much information what to fix ...
As yourself: What would you do if you were a "simple computer user" and are facing this "flash bulb icon" asking you to become "root"
- this is not true, you don't need a root for user crashes, so please don't lie ...
and to get a bugzilla account?
- yes, that's unfortunate, but what would be the solution here? allowing some anonymous account will lead to even worse situation...
You'd call your sys-admin, who'll deinstall or deactivate ABRT pretty soon, when you call him for the "Nth time".
- don't understand, why would you call admin? maybe this comes from the wrong presumption that ABRT needs root...
As a user you'd also think "what kind of crap is this Fedora/Linux - the WinXP I have at home is better".
- hm, wxp bug reporting is nice, because end-users can't even see where the bug went and check it's progress... if someone thinks it's better then...then I won't try to argue with him...
It's too easy for such people to open tickets via ABRT and then ignore a maintainer's NEEDINFO request.
Correct - But the same applies to maintainers.
My experience is, most of them ignore ABRT reports, probably because the ABRT reports are not helpful to them and/or don't contain sufficient infos.
- again and again and again - We know ABRT is not able to provide a good debug informations for every application we have, but the solution is not ignoring the bugs, but send us email or create a RFE in bugzilla describing what additional info you'd like and how/where to get it ...
It's disheartening in some cases, but it's a people-problem not a tool-problem.
I disagree - IMO; ABRT is not end-user ready. It presumes end-users to be familiar with redhat's infrastructure, which is a developer infrastructure and them to be interested to get involved into Fedora development. This simply does not apply.
Also, this produces incomplete traceback in many (IMO all) cases.
Cannot confirm that.
In almost all cases, I am observing missting debuginfos even after executing debuginfo-installs.
There seem to be some issues with not finding the needed debuginfo packages, which may be related to frequent updates of repos and older packages getting pruned. It may also be related to users updating their boxes at strange times, e.g. seldomly but immediately after a crash.
Possible. This certainly this applies in some cases.
However, I am experiencing missing debuginfos after debuginfo-install even with what is supposed to be "uptodate" Fedora installations.
- not ABRT problem,, but there are some projects trying to deal with this which I mentioned in one of my previous emails.. (debuginfofs and retrace server)
Ralf
On 11/08/2010 01:34 PM, Jiri Moskovcak wrote:
On 11/06/2010 02:53 AM, Ralf Corsepius wrote:
On 11/05/2010 09:46 PM, Michael Schwendt wrote:
On Fri, 05 Nov 2010 17:56:51 +0100, Ralf wrote:
ABRT
It doesn't tell the user that core dumps without reproducer are worthless in most cases but blindly sends out reports
Parts of the Fedora user base "abuse" ABRT in that they refuse to fill in the empty fields. Blame the reporters not the tool.
A matter of point of view: To me this is an ABRT GUI issue. It currently doesn't suck as much as it did before, nevertheless its usability still leaves much to be desired.
- please, send me some ideas or mockups and I will be more than happy to
change the GUI... but just complaining "it sucks" doesn't give me much information what to fix ...
ABRT is your baby. You can't expect others doing your job.
Some food for you to think about: - get rid of bugzilla accounts - get rid of forcing users to fillup their systems with debuginfos. - make the layout usable. ...
As yourself: What would you do if you were a "simple computer user" and are facing this "flash bulb icon" asking you to become "root"
- this is not true, you don't need a root for user crashes, so please
don't lie ...
Ignoring the rudity of this part of your respone, debuginfo-install requires root. Remove the debuginfo-install stuff and what you say will become true.
You'd call your sys-admin, who'll deinstall or deactivate ABRT pretty
soon, when you call him for the "Nth time".
- don't understand, why would you call admin?
... because a "simple computer user", will not understand what this "flash bulb" etc. is about, what debuginfos are, what a core dump is, has never heard about bugzilla, kerneloopes etc.
maybe this comes from the wrong presumption that ABRT needs root...
No. It comes from you apparently being the father of ABRT and being too close to it.
Take a person, without a IT background and without Linux familarity, e.g. somebody whose computer usage basically is working with a handful of GUI apps (firefox, thunderbird, openoffice) and confront this person with a nautilus ARBT (without having him told in advance)
... watch for what will happen ...
As a user you'd also think "what kind of crap is this Fedora/Linux -
the WinXP I have at home is better".
- hm, wxp bug reporting is nice, because end-users can't even see where
the bug went and check it's progress... if someone thinks it's better then...then I won't try to argue with him...
correct ... WinXP hides those details "uneducated users" will not be able to understand.
From an "uneducated user's POV" this is the easier to use alternative. From an educated user's POV it's the worst of all possible solutions.
- again and again and again - We know ABRT is not able to provide a good
debug informations for every application we have, but the solution is not ignoring the bugs, but send us email or create a RFE in bugzilla describing what additional info you'd like and how/where to get it ...
Again and again, I say: Critical serious and reproducable bugs have always been manually reported before ABRT was around. ABRT does not provide substantial benefits wrt. the qualtiy of Fedora and fixing "critical and serious" bugs.
However, I am experiencing missing debuginfos after debuginfo-install even with what is supposed to be "uptodate" Fedora installations.
- not ABRT problem,,
Pardon - What? The foundations of your works are based on, are flawed and you are saying this is not your problem?
With all due respect, but you can't be serious.
On Sat, Nov 06, 2010 at 04:22:29PM +0200, Alexander Kurtakov wrote:
We can argue about this a lot (e.e. submitter can reopen bug whenever he finds the time to verify the bug).
The problem is, there is no proper way to track whether a bug has been verified, because the result may also be, that it is fixed.
So the real problem is the notice period? Will it help if there is 6 weeks notice instead of 4? Any other idea?
It would also help if the bugs won't be closed when F12 is EOL to allow some time to migrate to the next Fedora release, handle the new issues and then take the time to check for old ones. So maybe first notify 6 weeks before the EOL date, then when it is EOLed again and close the bug 6 weeks after the EOL date.
Nevertheless, I would welcome it more if bug submitters would only be asked to verify a bug when there is some maintainer available to fix the verified bug.
Regards Till
fre 2010-11-05 klockan 12:53 +0000 skrev "Jóhann B. Guðmundsson":
Reports came in --><-- Auto responce reply back to the reporter --> QA verified try to duplicate bug --> Bug set to maintainer --> Bug stayed like that until EOL....
You forgot
Bug was actually fixed from upstream relase, but the maintainer overlooked the bugreport when doing the update as there is no integration between update process and bugzilla reminding maintainers there is open bug reports for their package.
What I'd like to see as maintainer is:
* A reminder about open bugs when making an update.
* The ability to easily ping bug reports from an update request, asking for the bug to be retested on the update while in updates-testing. Similar to how confirmed bugs can be pinged but without directly linking those bugs as fixed by the update.
* Enabling those who retest bugs as a result of this to add their bug as fixed by the update and positive karma on the update.
* Filter karma assignments so testers don't give negative karma on the update if the update as such works but do not fix their bug (not explicitly listed as fixed by the update).
Suggested method:
* automatically list open bug reports as a comment in the update request template, notifying the maintainer about their presence.
* A new update field where maintainer can populate for possibly fixed bugs. When the update is filed those bugzilla reports gets an update notice similar to that added on fixed bugs, but not otherwise included in automatic bug closing etc.
* In the bugzilla notice there is a link to provide feedback on the update, automatically including the bug #.
* New bug # field when providing update feedback, linking update feedback to relevan bugreports.
* Slight adjustment of karma to provide choices "Works for me", "Problem still present" and "New problems seen"
* "Works for me" is a +1, and also adds the refereced bug as fixed by the update if not already in the list of fixed bugs.
* "Problem still present" is a -1 if the bug is listed as fixed. Otherwise a +/-0.
* "Regression causing new problems" is a -1, and requires a comment explaining the issue and explicit confirmation that the issue is not seen in earlier version.
* All three choices automatically update any referenced bugzilla # with the status and comment, avoiding the need to use both tools to keep track of the bug status.
Regards Henrik
lör 2010-11-06 klockan 14:08 +0100 skrev Till Maas:
I have no problem to verify a bug when the maintainer is ready to fix it. But it is pretty annoying to verify it within a small time window regularly just to have it ignored till the next EOL date.
Understood. And the same issue is also on maintainers in different manners. But I am sad to hear that you see bugs you reconfirm to a new release ignored for a full cycle again.
The EOL bugzapper is really no more than a patch to a symptom (garbage collecting in bugzilla due to lack of attention of both maintainer and reporter) than a cure to the cause. Until a better model is found it's the best we have, but the goal should be get rid of the bug or push it forward to next release before EOL.
Regards Henrik
fre 2010-11-05 klockan 21:37 +0100 skrev Michael Schwendt:
Something is terribly wrong here, if reporter adjusts F12 -> F13 -> F14 over a period of N months in reply to the automated NEEDINFO requests and still doesn't get any response other than another automated one after six more months.
Yes, if a maintainer do not react on a bug which the reporter actively have reproduced in the next Fedora release before that release as well is EOL then yes something is very wrong.
This is something we as a project should pick up and make sure it does not happen, just as any other where reporter have provided feedback but maintainer do not respond in reasonable time.
But it's really a separate issue from the bugzapper, just made more obviously visible in that context.
Look in the archives. It's not the first time I've criticized what this bugzapping script does. It has stopped me from filing lots of issues, both with regard to packaging bugs as well as other problems, because I simply cannot handle the flood of NEEDINFO requests.
Agreed, and mentioned some ideas how to mitigate that in another response in this thread.
An alternative approach to what I suggested there would be to adjust the flood by starting to nag the reporter much earlier to retest on those reports where there is a newer version of the package available either as an update or in next release. Probably only based on package Version ignoring Release to avoid detecting mass rebuilds as new versions.
Regards Henrik
Henrik Nordström wrote:
- Slight adjustment of karma to provide choices "Works for me", "Problem
still present" and "New problems seen"
- "Works for me" is a +1, and also adds the refereced bug as fixed by
the update if not already in the list of fixed bugs.
- "Problem still present" is a -1 if the bug is listed as fixed.
Otherwise a +/-0.
- "Regression causing new problems" is a -1, and requires a comment
explaining the issue and explicit confirmation that the issue is not seen in earlier version.
That should work for bugfix updates, but updates that don't fix bugs will never get any positive karma. You might argue that no update should be done if there are no bugs to fix, but what about bugfixes where the bugs have been reported upstream but not in Red Hat's Bugzilla?
I also think there should be separate choices for "still works for me" and "fixes my problem". "Fixes my problem" would be what you called "works for me", while "still works for me" would be for testers who had no problem before and don't see any regressions.
Björn Persson
mån 2010-11-22 klockan 18:51 +0100 skrev Björn Persson:
Henrik Nordström wrote:
- Slight adjustment of karma to provide choices "Works for me", "Problem
still present" and "New problems seen"
- "Works for me" is a +1, and also adds the refereced bug as fixed by
the update if not already in the list of fixed bugs.
- "Problem still present" is a -1 if the bug is listed as fixed.
Otherwise a +/-0.
- "Regression causing new problems" is a -1, and requires a comment
explaining the issue and explicit confirmation that the issue is not seen in earlier version.
That should work for bugfix updates, but updates that don't fix bugs will never get any positive karma. You might argue that no update should be done if there are no bugs to fix, but what about bugfixes where the bugs have been reported upstream but not in Red Hat's Bugzilla?
It was not meant to read that "Works for me" require a bug entry. Just that when you get to the update via a bug you get it filled in automatically and you have the option to reference a bug.
I also think there should be separate choices for "still works for me" and "fixes my problem". "Fixes my problem" would be what you called "works for me", while "still works for me" would be for testers who had no problem before and don't see any regressions.
Good idea.
Regards Henrik
04.11.2010 06:10, Orcan Ogetbil wrote:
On Wed, Nov 3, 2010 at 10:59 PM, Adam Williamson wrote:
On Wed, 2010-11-03 at 22:12 -0400, Orcan Ogetbil wrote:
On Wed, Nov 3, 2010 at 9:55 PM, Adam Williamson wrote:
On Wed, 2010-11-03 at 21:02 -0400, Orcan Ogetbil wrote:
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is.
I disagree. I have seen many bugs fixed with the aid of abrt feedback. It beats the hell out of a bug report which says 'it crashed'.
Does it compare to this number? (it takes a while to open)
Not hard to run the numbers. There've been 31,603 bugs reported to Bugzilla by abrt. There are 2,216 bugs reported by abrt that have been closed as CURRENTRELEASE, RAWHIDE, ERRATA or NEXTRELEASE (which are the resolutions that usually imply 'it got fixed'). I think a tool that's resulted in 2,216 fixes for crasher bugs is pretty cool. :)
I am pretty sure a subset of these closed bugs are "mass-closing" of bugs when a maintainer updates the software. Sometimes, when you forward the report upstream, they don't understand the output either, and say "it may be fixed, just update and try". You update the software, put it to testing, and ask the user if it is fixed for him. The user doesn't respond as usual. Then you mark it as fixed without really knowing what's going on. Then you have such statistics. YAY!
Orcan
I think abrt is mostly useful tool, but it should be more interactive to our users. No, most problem from it (at my experience and by other answers there) because we got many reports dead at begining. Users encountered fill bug report, but if it is new user, it in 90% cases even do not answer on question how it may be reproduced. I assume it is main bad there. Can we add functionality track user bugreports and allow answer on requests (as minimum with 'needinfo' state) directly from abrt?? I think it may serious increase percentage of usefull bug reports from abrt.
On 11/25/2010 11:38 PM, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
I think abrt is mostly useful tool, but it should be more interactive to our users. No, most problem from it (at my experience and by other answers there) because we got many reports dead at begining. Users encountered fill bug report, but if it is new user, it in 90% cases even do not answer on question how it may be reproduced. I assume it is main bad there. Can we add functionality track user bugreports and allow answer on requests (as minimum with 'needinfo' state) directly from abrt?? I think it may serious increase percentage of usefull bug reports from abrt.
I think I agree with what you are saying - would be nice for bugzappers to be able to filter out [abrt] bugs without debug symbols and steps to reproduce - has anyone done this? If not I could probably have a crack at it using the bugzilla commandline over the weekend.
26.11.2010 00:43, Brendan Jones пишет:
On 11/25/2010 11:38 PM, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
I think abrt is mostly useful tool, but it should be more interactive to our users. No, most problem from it (at my experience and by other answers there) because we got many reports dead at begining. Users encountered fill bug report, but if it is new user, it in 90% cases even do not answer on question how it may be reproduced. I assume it is main bad there. Can we add functionality track user bugreports and allow answer on requests (as minimum with 'needinfo' state) directly from abrt?? I think it may serious increase percentage of usefull bug reports from abrt.
I think I agree with what you are saying - would be nice for bugzappers to be able to filter out [abrt] bugs without debug symbols and steps to reproduce - has anyone done this? If not I could probably have a crack at it using the bugzilla commandline over the weekend.
Main suggestion meantime was to continue dialog with user directly via abrt. It fill it via abrt and save credential. If I request something from user - abrt should show it information for user and provide possibility (at least) answer immediately.
Furthermore, step to reproduce also is very important, and may be we should enforce users fill it? For example put it in separate required field and check it is not empty (or may be some minimal heuristic against fill it like '123', 'qwerty', 'qaz' like: longer than 10 symbols, contains at least 2 spaces).
On 11/26/2010 08:24 AM, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
Furthermore, step to reproduce also is very important, and may be we should enforce users fill it? For example put it in separate required field and check it is not empty (or may be some minimal heuristic against fill it like '123', 'qwerty', 'qaz' like: longer than 10 symbols, contains at least 2 spaces).
(I know this thread has been done to death - but anyway) I'm sure there are maintainers who find the 'weightless' [abrt] bugs useful in certain scenarios (if only for gauging prevalence). There is a lot of clutter, I think it would be nice to filter these somehow via query in bugzilla. Insisting on debuginfo and comments will mean that the average joe will never use abrt, and I see that as a loss somehow (ha ha - that would reduce the clutter)
On 11/25/2010 11:24 PM, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
Furthermore, step to reproduce also is very important, and may be we should enforce users fill it?
This doesn't seem a clever idea to me, because at least for me, many abrt alerts originate from breakdowns without any obvious direct user-interaction involved. Demanding a reproducer for this incidents is hardly possible.
Ralf
26.11.2010 11:38, Ralf Corsepius wrote:
On 11/25/2010 11:24 PM, Pavel Alexeev (aka Pahan-Hubbitus) wrote:
Furthermore, step to reproduce also is very important, and may be we should enforce users fill it?
This doesn't seem a clever idea to me, because at least for me, many abrt alerts originate from breakdowns without any obvious direct user-interaction involved. Demanding a reproducer for this incidents is hardly possible.
Ralf
Good catch. I did not thin about this case. For that may be provided checkbox like "it happened without my interaction, don't known". In conjunction with possibility set by maintainer accept such reports for particular package or not it will be cool.
[Finally returning to this issue. If your mail client doesn't thread across this time span, see https://lists.fedoraproject.org/pipermail/devel/2010-November/145105.html for the previous part of the thread.]
On Fri, 2010-11-05 at 12:19 -0700, Adam Williamson wrote:
On Thu, 2010-11-04 at 16:10 -0400, Matt McCutchen wrote:
On Thu, 2010-11-04 at 09:38 -0700, Adam Williamson wrote:
The practical point is that F12 is about to go EOL which means the bug must be closed...
Why? Obviously it needs to be clear that nothing further should be expected from the maintainer unless/until the version is bumped. But the project can choose to indicate that by closing the bugs as WONTFIX or some other way,
That's, um, exactly the process we're discussing here. We close all bugs for a given release when that release goes EOL. (I forget what resolution is used, it may well be WONTFIX).
The resolution is indeed WONTFIX.
We send a warning note to all bugs that will be closed under this process, a short while before they're closed, so the reporters can check if they exist in a newer version and bump the report to that version to keep it open, if they like.
I'm well aware of the process. The principle behind it is that maintainers are not expected to act on bugs that have not been reproduced in a currently maintained version of Fedora, and such bugs should be marked so that users know not to expect any action. I am not disputing this.
However, the generally accepted definition of WONTFIX is that the bug has at least some validity but the maintainer has decided not to address it because the benefit fails to outweigh the cost (implementation and maintenance effort + any negative side effects, to include going outside the intended scope of the software). Zapping bugs by marking them WONTFIX is semantically incorrect and makes then hard to distinguish from bugs that meet the accepted definition of WONTFIX; it has also seemed on some occasions to lead maintainers to abuse NOTABUG to mean WONTFIX. Fedora is the only project I am aware of that does this.
I urge that bug zapping should be accomplished:
(1) With a different resolution, like Mozilla's EXPIRED (I can file the bug against Red Hat Bugzilla), or
(2) Without mutating bugs in any way, but by publicizing that non-FutureFeature bugs open against EOL Fedora versions are considered expired and no action should be expected (GNOME seems to operate this way informally). Optionally, Bugzilla could be customized to return the resolution of such bugs as EXPIRED to facilitate the exclusion of expired bugs from counts/queries of "open" bugs as desired.
If we don't auto-close bugs we wind up with a huge pile of ancient bugs which just gets in the way of people who want to come along and actually clean up the bug list for a package. It's harder to do that if you're looking at reports from the Stone Age.
What you're really saying is that most maintainers want to work from a list of unexpired bugs. But there are ways to achieve that other than marking all the expired bugs WONTFIX. Maintainers can always filter on the currently maintained Fedora versions, but it becomes tedious to configure that, which is where a virtual EXPIRED resolution exposed by Bugzilla would come in handy.
My broader point is that calling expired bugs closed is an oversimplification, and possibly a disingenuously generous interpretation of the situation. I'd guess that among non-ABRT bugs, well over 50% of expired bugs are still valid two Fedora versions later. But regardless of the figure, I believe that each client querying Bugzilla should be allowed to decide whether or not to include expired bugs, as distinguished from true closed bugs, based on its own needs. By stuffing expired bugs into the WONTFIX category, Fedora is depriving them of that choice.
[I am not on the list; please keep me in replies.]
On Fri, 2011-09-02 at 14:01 -0400, Matt McCutchen wrote:
What you're really saying is that most maintainers want to work from a list of unexpired bugs. But there are ways to achieve that other than marking all the expired bugs WONTFIX. Maintainers can always filter on the currently maintained Fedora versions, but it becomes tedious to configure that, which is where a virtual EXPIRED resolution exposed by Bugzilla would come in handy.
Mostly your proposal makes sense, but we're trying very hard to stick to upstream Bugzilla since 3.x, as heavy customization of 2.x caused more problems than it solved. So we're reluctant to add resolutions and statuses that don't exist upstream - even if Mozilla have hacked up their own copy of their own upstream bug reporting system to add resolutions...
(if EXPIRED really exists in upstream bugzilla, that'd be a different case.)
On Fri, 2011-09-02 at 12:29 -0700, Adam Williamson wrote:
On Fri, 2011-09-02 at 14:01 -0400, Matt McCutchen wrote:
What you're really saying is that most maintainers want to work from a list of unexpired bugs. But there are ways to achieve that other than marking all the expired bugs WONTFIX. Maintainers can always filter on the currently maintained Fedora versions, but it becomes tedious to configure that, which is where a virtual EXPIRED resolution exposed by Bugzilla would come in handy.
Mostly your proposal makes sense,
Thanks for the response.
but we're trying very hard to stick to upstream Bugzilla since 3.x, as heavy customization of 2.x caused more problems than it solved. So we're reluctant to add resolutions and statuses that don't exist upstream - even if Mozilla have hacked up their own copy of their own upstream bug reporting system to add resolutions...
I don't buy that: Red Hat Bugzilla currently has 4 upstream resolutions to 7 custom ones. Are all the custom resolutions actively being phased out? Otherwise, can you give some examples to illustrate the marginal harm likely to occur if an 8th custom resolution is added?
I'm disappointed that you don't appear to buy that this is important enough to merit discussion of alternatives, rather than just raising a problem with one of the ones I mentioned. The status quo may be fine for a maintainer or triager going down a work list, but when I as a user review old bugs related to a topic (perhaps to see whether a new bug is merited or I should join an old one), "expired" is equivalent to NEW rather than WONTFIX as far as I'm concerned, and it's annoying to have to open each WONTFIX bug to determine which kind it is.
We have a number of options here which vary in implementation effort and how much burden they impose on user and/or maintainer to get what they want from an inadequate representation:
1. Status quo: hard to distinguish expired from WONTFIX. 2a. Add EXPIRED resolution and use it. 2b. Co-opt an existing little-used custom resolution, e.g., CANTFIX (semantically questionable on its face, but maybe reasonable in light of the explanation on https://bugzilla.redhat.com/page.cgi?id=fields.html#status ). 3. Do not change the bug state, and have maintainers apply the same conditions now used by the bug zapper on all of their searches. Reducing mutable state is generally good in that it reduces the possible ways for things to get out of whack. But then it takes more work to see whether a non-CLOSED bug is expired. 3a. Like #3, but make it easier with a virtual EXPIRED resolution. Probably an undesirable level of customization to Bugzilla. 4. Add an "Expired" keyword or custom field, use it, and: 4a. Continue to close the bugs WONTFIX. Ugh, but I can use the keyword/field in search and maybe even get it to show as a column on search results. 4b. Do not change the status, and have maintainers use the keyword/field in their search.
No one should object to 4a as a change (though I recognize I am still asking someone to do work, especially if existing bugs are to be reclassified). We could start with that and at least stop losing the data in the next bug zapping cycle.
I would appreciate your honest consideration (Adam and any other relevant parties).
Matt McCutchen (matt@mattmccutchen.net) said:
We have a number of options here which vary in implementation effort and how much burden they impose on user and/or maintainer to get what they want from an inadequate representation:
- Status quo: hard to distinguish expired from WONTFIX.
2a. Add EXPIRED resolution and use it. 2b. Co-opt an existing little-used custom resolution, e.g., CANTFIX (semantically questionable on its face, but maybe reasonable in light of the explanation on https://bugzilla.redhat.com/page.cgi?id=fields.html#status ).
This (using CANTFIX instead of WONTFIX) seems like the simplest one to me.
Bill
On Fri, 2011-09-02 at 16:43 -0400, Matt McCutchen wrote:
On Fri, 2011-09-02 at 12:29 -0700, Adam Williamson wrote:
On Fri, 2011-09-02 at 14:01 -0400, Matt McCutchen wrote:
What you're really saying is that most maintainers want to work from a list of unexpired bugs. But there are ways to achieve that other than marking all the expired bugs WONTFIX. Maintainers can always filter on the currently maintained Fedora versions, but it becomes tedious to configure that, which is where a virtual EXPIRED resolution exposed by Bugzilla would come in handy.
Mostly your proposal makes sense,
Thanks for the response.
but we're trying very hard to stick to upstream Bugzilla since 3.x, as heavy customization of 2.x caused more problems than it solved. So we're reluctant to add resolutions and statuses that don't exist upstream - even if Mozilla have hacked up their own copy of their own upstream bug reporting system to add resolutions...
I don't buy that: Red Hat Bugzilla currently has 4 upstream resolutions to 7 custom ones. Are all the custom resolutions actively being phased out? Otherwise, can you give some examples to illustrate the marginal harm likely to occur if an 8th custom resolution is added?
Hum, I didn't realize our resolutions were so customized, I thought they were the upstream ones; this is what I've been told when discussing custom resolutions in the past. It's certainly something you could propose as an enhancement by filing a bug against Bugzilla, then.
2b. Co-opt an existing little-used custom resolution, e.g., CANTFIX (semantically questionable on its face, but maybe reasonable in light of the explanation on https://bugzilla.redhat.com/page.cgi?id=fields.html#status ).
As noted at the top of that page, that is the policy for RHEL, not for Fedora. Fedora policy is https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#CLOSED . It states only "The resolutions CANTFIX, WONTFIX, and WORKSFORME are for use by maintainers only, and are self-explanatory."
- Do not change the bug state, and have maintainers apply the same
conditions now used by the bug zapper on all of their searches. Reducing mutable state is generally good in that it reduces the possible ways for things to get out of whack. But then it takes more work to see whether a non-CLOSED bug is expired. 3a. Like #3, but make it easier with a virtual EXPIRED resolution. Probably an undesirable level of customization to Bugzilla. 4. Add an "Expired" keyword or custom field, use it, and: 4a. Continue to close the bugs WONTFIX. Ugh, but I can use the keyword/field in search and maybe even get it to show as a column on search results. 4b. Do not change the status, and have maintainers use the keyword/field in their search.
I think if we're going to change this, the only sensible change is to use a different CLOSED resolution. All the others seem like hacks which are likely to cause more trouble/confusion than they resolve. We clearly want to bugs to be CLOSED, not open with a quasi-closed keyword or whiteboard field.
On Fri, 2011-09-02 at 13:54 -0700, Adam Williamson wrote:
Hum, I didn't realize our resolutions were so customized, I thought they were the upstream ones; this is what I've been told when discussing custom resolutions in the past. It's certainly something you could propose as an enhancement by filing a bug against Bugzilla, then.
OK, I will do that and post the link here. Any assessment of difficulty provided by the Bugzilla team can inform a decision between 2a and 2b.
2b. Co-opt an existing little-used custom resolution, e.g., CANTFIX (semantically questionable on its face, but maybe reasonable in light of the explanation on https://bugzilla.redhat.com/page.cgi?id=fields.html#status ).
As noted at the top of that page, that is the policy for RHEL, not for Fedora. Fedora policy is https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#CLOSED . It states only "The resolutions CANTFIX, WONTFIX, and WORKSFORME are for use by maintainers only, and are self-explanatory."
You are right. But taking a step back, the project has the power to change the policy to best meet its needs. My point stands that the resolution is little-used (less than 2% [1]), and its use for expired bugs would harmonize with the current RHEL policy. None of my 131 bugs have been marked CANTFIX [2]; maintainers seem to find that the better-known WONTFIX and NOTABUG cover the range of cases.
[1] https://bugzilla.redhat.com/report.cgi?x_axis_field=version&y_axis_field...) [2] https://bugzilla.redhat.com/report.cgi?x_axis_field=version&y_axis_field...
- Do not change the bug state, and have maintainers apply the same
conditions now used by the bug zapper on all of their searches. Reducing mutable state is generally good in that it reduces the possible ways for things to get out of whack. But then it takes more work to see whether a non-CLOSED bug is expired. 3a. Like #3, but make it easier with a virtual EXPIRED resolution. Probably an undesirable level of customization to Bugzilla. 4. Add an "Expired" keyword or custom field, use it, and: 4a. Continue to close the bugs WONTFIX. Ugh, but I can use the keyword/field in search and maybe even get it to show as a column on search results. 4b. Do not change the status, and have maintainers use the keyword/field in their search.
I think if we're going to change this, the only sensible change is to use a different CLOSED resolution. All the others seem like hacks which are likely to cause more trouble/confusion than they resolve.
Fair assessment.
We clearly want to bugs to be CLOSED, not open with a quasi-closed keyword or whiteboard field.
I'm not sure who "we" is, but I disagree. The generally accepted definition of CLOSED is that the resolution is final unless subsequent events invalidate the original rationale. (C.f. the RHEL policy: "The bug is considered dead, the resolution is correct.") All it takes for an expired bug to be reopened is for someone to have enough interest to retest it in a maintained Fedora version. To claim that this meets the definition of CLOSED is a big stretch. I believe that "expired" should properly be its own major state alongside "open" and "closed", but we have alternatives that are less radical and still solve the immediate problem with search.
On Fri, 2011-09-02 at 18:33 -0400, Matt McCutchen wrote:
We clearly want to bugs to be CLOSED, not open with a quasi-closed keyword or whiteboard field.
I'm not sure who "we" is, but I disagree. The generally accepted definition of CLOSED is that the resolution is final unless subsequent events invalidate the original rationale. (C.f. the RHEL policy: "The bug is considered dead, the resolution is correct.") All it takes for an expired bug to be reopened is for someone to have enough interest to retest it in a maintained Fedora version. To claim that this meets the definition of CLOSED is a big stretch. I believe that "expired" should properly be its own major state alongside "open" and "closed", but we have alternatives that are less radical and still solve the immediate problem with search.
The reason for the auto-closing is 'problems with search': developers do not want to have searches for open bugs cluttered up with bugs for ancient versions. Any change which involves not closing the old bugs will result in the auto-close procedure not solving this problem any more, because the bugs will show up in a default search, and - as you mentioned - developers will have to remember to customize their searches every time to cover only currently-active versions. If we were to do that we might as well not do anything to old bugs automatically at all, because it's about as easy to customize a search to 'fedora 14, fedora 15, fedora 16, rawhide' as it is to customize it to 'no bugs with keyword EXPIRED'.
* Adam Williamson [03/09/2011 00:21] :
Hum, I didn't realize our resolutions were so customized, I thought they were the upstream ones; this is what I've been told when discussing custom resolutions in the past. It's certainly something you could propose as an enhancement by filing a bug against Bugzilla, then.
Custom resolutions these days fall in the configration scope. There is no hacking of code required.
Emmanuel
On Fri, 2011-09-02 at 15:43 -0700, Adam Williamson wrote:
On Fri, 2011-09-02 at 18:33 -0400, Matt McCutchen wrote:
We clearly want to bugs to be CLOSED, not open with a quasi-closed keyword or whiteboard field.
I'm not sure who "we" is, but I disagree. The generally accepted definition of CLOSED is that the resolution is final unless subsequent events invalidate the original rationale. (C.f. the RHEL policy: "The bug is considered dead, the resolution is correct.") All it takes for an expired bug to be reopened is for someone to have enough interest to retest it in a maintained Fedora version. To claim that this meets the definition of CLOSED is a big stretch. I believe that "expired" should properly be its own major state alongside "open" and "closed", but we have alternatives that are less radical and still solve the immediate problem with search.
The reason for the auto-closing is 'problems with search': developers do not want to have searches for open bugs cluttered up with bugs for ancient versions.
Yes, of course. I was only responding to your apparent claim (at the top) that the use of CLOSED is semantically desirable.
Any change which involves not closing the old bugs will result in the auto-close procedure not solving this problem any more, because the bugs will show up in a default search, and - as you mentioned - developers will have to remember to customize their searches every time to cover only currently-active versions.
You are assuming that developers start from the default search to bring up their work lists. Do they? There are alternatives:
- We can set up a shortened URL for a "Fedora developer default search" that pre-fills the appropriate fields on the query form, e.g., https://bugzilla.redhat.com/query.cgi?classification=Fedora&product=Fedo... . This would also save the "Refresh Components" latency.
- They could use a saved query, which would change either every 6 months or not at all.
- They could use http://bugz.fedoraproject.org/%s, which can be changed to do whatever they generally want.
If we insist that the default search exclude expired bugs, it is already customized (compare https://bugzilla.redhat.com/query.cgi to https://landfill.bugzilla.org/bugzilla-tip/query.cgi?format=advanced), so we may be able to make a further customization to exclude expired Fedora bugs without affecting other products. But IMO, the default search should target the most common use case, which may well be users if developers do most of their queries a different way.
My intent in putting forth this argument is to get past preconceptions and accurately assess the real drawbacks of approaches that do not close the bugs, since they are slightly better semantically. If the community still feels the idea is too radical, using an EXPIRED or CANTFIX resolution would still solve my problem.
If we were to do that we might as well not do anything to old bugs automatically at all, because it's about as easy to customize a search to 'fedora 14, fedora 15, fedora 16, rawhide' as it is to customize it to 'no bugs with keyword EXPIRED'.
Not quite: you don't have to remember which Fedora versions are maintained, or alternatively, update your saved queries every six months. And aside from search, marking expired bugs has the important function of cluing in the reporter that they should expect no action under the expiration policy.
Dne 2.9.2011 22:54, Adam Williamson napsal(a):
Hum, I didn't realize our resolutions were so customized, I thought they were the upstream ones; this is what I've been told when discussing custom resolutions in the past. It's certainly something you could propose as an enhancement by filing a bug against Bugzilla, then.
If we had upstream’s UNCONFIRMED we wouldn't have to play with the Triaged keyword (although the meaning is subtly different).
Matěj
Dne 3.9.2011 00:33, Matt McCutchen napsal(a):
bugs would harmonize with the current RHEL policy. None of my 131 bugs have been marked CANTFIX [2]; maintainers seem to find that the better-known WONTFIX and NOTABUG cover the range of cases.
I use it routinely as a polite version of WONTFIX for Xorg bugs with nvidia binary driver. But yes, that's not a big deal.
Matěj
On Sat, 2011-09-03 at 10:45 +0200, Matej Cepl wrote:
Dne 2.9.2011 22:54, Adam Williamson napsal(a):
Hum, I didn't realize our resolutions were so customized, I thought they were the upstream ones; this is what I've been told when discussing custom resolutions in the past. It's certainly something you could propose as an enhancement by filing a bug against Bugzilla, then.
If we had upstream’s UNCONFIRMED we wouldn't have to play with the Triaged keyword (although the meaning is subtly different).
More than subtly. We explicitly *don't* require triagers to confirm bugs on their own systems.
devel@lists.stg.fedoraproject.org