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

http://tinyurl.com/39yr832

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

http://tinyurl.com/39yr832

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

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)

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.

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

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

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

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

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

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

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

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

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

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

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?

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

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.

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

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)

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 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 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, 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 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.)

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:

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

This (using CANTFIX instead of WONTFIX) seems like the simplest one to me.

Bill

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

...

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.

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

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

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 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, 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 :)

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