ABRT unusable again

[Christoph Wickert]

What's wrong with ABRT? ALl the backtraces I get are unusable again. If
Thunar crashes, not even Thunar-debuginfo gets installed. 

abrt 1.0 worked here, then came 1.0.2 which was broken. 1.0.3 was
working again, but got superseded be 1.0.4 only a few of days later.
This means that most of the time, all the bugs submitted are basically
useless.

For me as the maintainer it is a lot of work to reply to all these
useless reports and for our users it's just frustrating if all their
reports get closed INSUFFICIENT_DATA.

If the situation doesn't change any time soon, we IMHO should consider
disabling abrt until the issues are fixed.

Regards,
Christoph

[Ralf Corsepius]

On 02/05/2010 09:46 PM, Christoph Wickert wrote:

>  If the situation doesn't change any time soon, we IMHO should
> consider
>  disabling abrt until the issues are fixed. 
Agreed.

However, I went one step further: I removed ABRT from my systems, not 
because of issues I would have with it as a Fedora package maintainer, 
but because of usability issues I am having with it on the user-side and 
because of other issues I am having with it as sys-admin.

Worse, in this case, I feel the Fedora community is being abused to 
evaluate a semi-functional piece of SW's "yet uncooked" concepts.

Ralf

[Kevin Kofler]

Ralf Corsepius wrote:
>  However, I went one step further: I removed ABRT from my systems,
> not
>  because of issues I would have with it as a Fedora package maintainer,
>  but because of usability issues I am having with it on the user-side and
>  because of other issues I am having with it as sys-admin.
>  
>  Worse, in this case, I feel the Fedora community is being abused to
>  evaluate a semi-functional piece of SW's "yet uncooked" concepts. 
+1. ABRT is just broken in so many ways it's not even funny and should never 
have been shipped in its current state.

        Kevin Kofler

[Till Maas]

On Sat, Feb 06, 2010 at 12:23:31PM +0100, Kevin Kofler wrote:
>  Ralf Corsepius wrote:
>  > However, I went one step further: I removed ABRT from my systems, not
>  > because of issues I would have with it as a Fedora package maintainer,
>  > but because of usability issues I am having with it on the user-side and
>  > because of other issues I am having with it as sys-admin.
>  > 
>  > Worse, in this case, I feel the Fedora community is being abused to
>  > evaluate a semi-functional piece of SW's "yet uncooked" concepts.
>  
>  +1. ABRT is just broken in so many ways it's not even funny and should never 
>  have been shipped in its current state. 
For yum related python backtrace bugs, it worked pretty well here and
made bug reporting a lot easier. So maybe it should only be activated
for cases where additional debuginfo is not needed.

Regards
Till

[Christoph Wickert]

Am Samstag, den 06.02.2010, 16:22 +0100 schrieb Till Maas:
>  On Sat, Feb 06, 2010 at 12:23:31PM +0100, Kevin Kofler wrote: 
>  > +1. ABRT is just broken in so many ways it's not even funny
> and should never 
>  > have been shipped in its current state.
>  
>  For yum related python backtrace bugs, it worked pretty well here and
>  made bug reporting a lot easier. So maybe it should only be activated
>  for cases where additional debuginfo is not needed. 
Nice idea. IMO it should only allow to submit reports after some sanity
checks. In my case where Thunar crashed and Thunar-debuginfo (and I have
lots of these for other package as well) was not installed, it certainly
would not have passed these tests.

>  Regards
>  Till 
Regards,
Christoph

[Till Maas]

On Sat, Feb 06, 2010 at 04:22:27PM +0100, Till Maas wrote:

>  For yum related python backtrace bugs, it worked pretty well here
> and
>  made bug reporting a lot easier. So maybe it should only be activated
>  for cases where additional debuginfo is not needed. 
This time it did not catch the bug:
https://bugzilla.redhat.com/show_bug.cgi?id=563368

Regards
Till

[Jiri Moskovcak]

On 02/10/2010 01:12 AM, Till Maas wrote:
>  On Sat, Feb 06, 2010 at 04:22:27PM +0100, Till Maas wrote:
>
> > For yum related python backtrace bugs, it worked pretty well here and
> > made bug reporting a lot easier. So maybe it should only be activated
> > for cases where additional debuginfo is not needed.
>
>  This time it did not catch the bug:
>  https://bugzilla.redhat.com/show_bug.cgi?id=563368
>
>  Regards
>  Till
>  
I think I did catch it (if ABRT was running), but ordinary users can't 
see other user's crashes (the command from this bz has to be run under 
root) unless root doesn't change this behaviour in abrt's config file.

J.

[Till Maas]

On Wed, Feb 10, 2010 at 10:23:48AM +0100, Jiri Moskovcak wrote:

>  I think I did catch it (if ABRT was running), but ordinary users
> can't 
>  see other user's crashes (the command from this bz has to be run under 
>  root) unless root doesn't change this behaviour in abrt's config file. 
What do I have to change? The manpage (man abrt.conf) or default config
(/etc/abrt/abrt.conf) does not give me a hint. Btw. can you maybe use
PolicyKit to determine whether abrt-gui and the crashed program are
run by the same person in case both happens via the local console?

Regards
Till

[Jiri Moskovcak]

On 02/10/2010 10:42 AM, Till Maas wrote:
>  On Wed, Feb 10, 2010 at 10:23:48AM +0100, Jiri Moskovcak wrote:
>
> > I think I did catch it (if ABRT was running), but ordinary users can't
> > see other user's crashes (the command from this bz has to be run under
> > root) unless root doesn't change this behaviour in abrt's config file.
>
>  What do I have to change? The manpage (man abrt.conf) or default config
>  (/etc/abrt/abrt.conf) does not give me a hint. Btw. can you maybe use 
You need to add this to the respective analyzer's configs:

InformAllUsers = yes

CCpp.conf - C/C++ xrashes analyzer
Python.conf - python analyzer
Kerneloops.conf - kerneloops (already has this enabled)

But this applies only to new crashes, the old ones will still be 
invisible for ordinary users.
Working on updating the man-pages and wiki right now.

>  PolicyKit to determine whether abrt-gui and the crashed program are
>  run by the same person in case both happens via the local console?
>  
Yes, we're changing the behavior right now.

>  Regards
>  Till
>

[Till Maas]

On Wed, Feb 10, 2010 at 10:58:03AM +0100, Jiri Moskovcak wrote:

>  You need to add this to the respective analyzer's configs:
>  
>  InformAllUsers = yes
>  
>  CCpp.conf - C/C++ xrashes analyzer
>  Python.conf - python analyzer
>  Kerneloops.conf - kerneloops (already has this enabled)
>  
>  But this applies only to new crashes, the old ones will still be 
>  invisible for ordinary users.
>  Working on updating the man-pages and wiki right now. 
Thank you, after adding this to the Python.conf file and running
service abrtd restart
it now catches the python crash.

Regards
Till

[Michael Schwendt]

On Fri, 05 Feb 2010 21:46:54 +0100, Christoph wrote:

>  What's wrong with ABRT? ALl the backtraces I get are unusable
> again. If
>  Thunar crashes, not even Thunar-debuginfo gets installed. 
>  
>  abrt 1.0 worked here, then came 1.0.2 which was broken. 1.0.3 was
>  working again, but got superseded be 1.0.4 only a few of days later.
>  This means that most of the time, all the bugs submitted are basically
>  useless.
>  
>  For me as the maintainer it is a lot of work to reply to all these
>  useless reports and for our users it's just frustrating if all their
>  reports get closed INSUFFICIENT_DATA.
>  
>  If the situation doesn't change any time soon, we IMHO should consider
>  disabling abrt until the issues are fixed. 
Which kernel release?
Perhaps related to this sweet little "war" about ABRT:
http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1237

[Christoph Wickert]

Am Samstag, den 06.02.2010, 10:51 +0100 schrieb Michael Schwendt:
>  On Fri, 05 Feb 2010 21:46:54 +0100, Christoph wrote:
>  
>  > What's wrong with ABRT? ALl the backtraces I get are unusable again. If
>  > Thunar crashes, not even Thunar-debuginfo gets installed. 
>  
>  Which kernel release?
>  Perhaps related to this sweet little "war" about ABRT:
>  http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1237 
I am still using 2.6.31.12-174.2.3.fc12 and so do the submitters of the
bug reports.

Regards,
Christoph

[leigh scott]

IMO ABRT isn't that useful as a lot of the reports don't include steps
to reproduce (I just close the bugs after a month if they don't respond
to the "needinfo" request).
I believe ABRT shouldn't file a bug report unless it is filled in
properly.

[Michael Schwendt]

On Sat, 06 Feb 2010 10:53:14 +0000, Leigh wrote:

>  IMO ABRT isn't that useful as a lot of the reports don't
> include steps
>  to reproduce (I just close the bugs after a month if they don't respond
>  to the "needinfo" request).
>  I believe ABRT shouldn't file a bug report unless it is filled in
>  properly. 
Yeah, some of us have pointed out that before.

I'm happy about every detailed backtrace I get, but I would be even more
happy if users contributed a tiny bit more and added comments to their
tickets and responded to NEEDINFO queries and gave feedback on Test
Updates.  ABRT has lowered the hurdle so much that people dump generated
reports into bugzilla but otherwise they appear like /dev/null and only
show rarely that they care about a package.

[Stefan Schulze Frielinghaus]

On Sa, 2010-02-06 at 14:08 +0100, Michael Schwendt wrote:
[...]
>  I'm happy about every detailed backtrace I get, but I would be
> even more
>  happy if users contributed a tiny bit more and added comments to their
>  tickets and responded to NEEDINFO queries and gave feedback on Test
>  Updates.  ABRT has lowered the hurdle so much that people dump generated
>  reports into bugzilla but otherwise they appear like /dev/null and only
>  show rarely that they care about a package. 
On the one hand I agree with you on the other hand I see it from an
users point of view and feel a bit in a pickle. For example, every
second login gnome-panel crashes, removes Gnote from the panel and ABRT
shows me a core dump. I cannot reproduce this problem except from a
logout and login. So I cannot provide a detailed description what was
going on and how to reproduce it (except as I already said: logout and
login). But since it crashes that frequently I decided to report it
anyway just in the hope that the package maintainer sees from the
backtrace what is going wrong. Maybe this is not the best thing to do
but after a couple of weeks seeing the red flash light several times a
day you go crazy ;-)

However, in the meantime I stopped reporting crashes via ABRT because I
think it raises the load for a package maintainer to high while the
report should go directly to upstream. Bothering the maintainer first
instead of upstream is not the right thing to do.

Just my experience.

cheers,
Stefan

[Laurent Rineau]

Le samedi 06 février 2010 15:53:03, Stefan Schulze Frielinghaus a écrit :
>  On Sa, 2010-02-06 at 14:08 +0100, Michael Schwendt wrote:
>  [...]
>  
>  > I'm happy about every detailed backtrace I get, but I would be even more
>  > happy if users contributed a tiny bit more and added comments to their
>  > tickets and responded to NEEDINFO queries and gave feedback on Test
>  > Updates.  ABRT has lowered the hurdle so much that people dump generated
>  > reports into bugzilla but otherwise they appear like /dev/null and only
>  > show rarely that they care about a package.
>  
>  On the one hand I agree with you on the other hand I see it from an
>  users point of view and feel a bit in a pickle. For example, every
>  second login gnome-panel crashes, removes Gnote from the panel and ABRT
>  shows me a core dump. I cannot reproduce this problem except from a
>  logout and login. So I cannot provide a detailed description what was
>  going on and how to reproduce it (except as I already said: logout and
>  login). But since it crashes that frequently I decided to report it
>  anyway just in the hope that the package maintainer sees from the
>  backtrace what is going wrong. Maybe this is not the best thing to do
>  but after a couple of weeks seeing the red flash light several times a
>  day you go crazy ;-) 
Same for me. I reported a crash in abrt-gui, without knowing what has caused 
it, with the hope that the maintainer can understand that from the backtrace.


-- 
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau

[Kevin Kofler]

Stefan Schulze Frielinghaus wrote:
>  However, in the meantime I stopped reporting crashes via ABRT because
> I
>  think it raises the load for a package maintainer to high while the
>  report should go directly to upstream. Bothering the maintainer first
>  instead of upstream is not the right thing to do. 
+1, in fact that's the biggest design failure in ABRT (in its current state) 
and basically makes it useless. Gathering backtraces is something that needs 
to be handled by upstream projects (like KDE does with KCrash/DrKonqi), not 
distributions.

        Kevin Kofler

[Neil Horman]

On Sat, Feb 06, 2010 at 06:53:31PM +0100, Kevin Kofler wrote:
>  Stefan Schulze Frielinghaus wrote:
>  > However, in the meantime I stopped reporting crashes via ABRT because I
>  > think it raises the load for a package maintainer to high while the
>  > report should go directly to upstream. Bothering the maintainer first
>  > instead of upstream is not the right thing to do.
>  
>  +1, in fact that's the biggest design failure in ABRT (in its current state) 
>  and basically makes it useless. Gathering backtraces is something that needs 
>  to be handled by upstream projects (like KDE does with KCrash/DrKonqi), not 
>  distributions.
>  
>          Kevin Kofler
>   
Seems like upstream projects managing app specific captures leads to either
framentation of the capture method, or a lack of scalability (1 app per app to
collect dumps for that app).

Might be better to have the bugzilla maintainers look at xml proxy methods to
forward abrt captured backtraces to specific upstream project logging sites.

Neil

>  -- 
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Karel Klic]

Kevin Kofler wrote:
>  Stefan Schulze Frielinghaus wrote:
> > However, in the meantime I stopped reporting crashes via ABRT because I
> > think it raises the load for a package maintainer to high while the
> > report should go directly to upstream. Bothering the maintainer first
> > instead of upstream is not the right thing to do.
>
>  +1, in fact that's the biggest design failure in ABRT (in its current state)
>  and basically makes it useless. Gathering backtraces is something that needs
>  to be handled by upstream projects (like KDE does with KCrash/DrKonqi), not
>  distributions. 
Some maintainers fix crashes in their packages and then send the fixes 
to the upstream, and some don't. Some crashes are caused by 
distribution-specific environment, and some are not :) It's not clear 
whether we should report crashes directly to the upstream.

For some packages, reporting upstream could work well (Firefox, 
OpenOffice.org come to my mind). However, many packages have 
unresponsive/dead upstream, upstream without issue tracker etc.

See rhbz#532307 for a beautiful example of cross-package bugfixing, 
which is very hard to do in upstream. At least eight applications will 
be fixed at the end (e.g. #542277, #547030, #550165, #558329, #561592, 
#561059)

Karel

[Ralf Corsepius]

On 02/07/2010 03:15 AM, Karel Klic wrote:
>  Kevin Kofler wrote:
> > Stefan Schulze Frielinghaus wrote:
> >> However, in the meantime I stopped reporting crashes via ABRT because I
> >> think it raises the load for a package maintainer to high while the
> >> report should go directly to upstream. Bothering the maintainer first
> >> instead of upstream is not the right thing to do.
> >
> > +1, in fact that's the biggest design failure in ABRT (in its current state)
> > and basically makes it useless. Gathering backtraces is something that needs
> > to be handled by upstream projects (like KDE does with KCrash/DrKonqi), not
> > distributions. 
To end-users, it's irrelevant "who is supposed to fix something". Their 
complaints are against the product call Fedora and thus expect "Fedora 
to fix their product".

That said: It's irrelevant to Toyota car owners, which supplier 
manufactured the parts which have caused Toyota to call back 1000 of 
their cars - To them it's Toyota who is reponisible, and Toyota's duty 
to fix this issue.

>  Some maintainers fix crashes in their packages and then send the
> fixes
>  to the upstream, and some don't. Some crashes are caused by
>  distribution-specific environment, and some are not :) It's not clear
>  whether we should report crashes directly to the upstream. 
History tells, low quality automated bug reports to be ignored and to 
cause a lot of bad blood. Debian for instance has an unfortunate history 
in doing so - You're better off to learn from their historic mistakes!

>  For some packages, reporting upstream could work well (Firefox,
>  OpenOffice.org come to my mind). 
You mean big, well-known projects with a
fully-blown up infrastructure 
and bureaucracy in place. It's naive to expect such an infrastructure to 
be in place for all projects.

>  However, many packages have
>  unresponsive/dead upstream, upstream without issue tracker etc. 
Read my previous
sentence.

Also take into account that many upstreams will consider automated bug 
reports, to be "simply SPAM", esp. when the find them to be of low 
quality. If you're lucky, they will simply ignore them, if you're less 
lucky, they will confront you with very harsh responses.


Finally: Why are we discussing this here?

This is all should have been part of ABRT's concepts, its upstream 
should have considered and resolved before unleashing ABRT.

[Stefan Schulze Frielinghaus]

On So, 2010-02-07 at 09:03 +0100, Ralf Corsepius wrote:
>  On 02/07/2010 03:15 AM, Karel Klic wrote:
>  > Kevin Kofler wrote:
>  >> Stefan Schulze Frielinghaus wrote:
>  >>> However, in the meantime I stopped reporting crashes via ABRT because I
>  >>> think it raises the load for a package maintainer to high while the
>  >>> report should go directly to upstream. Bothering the maintainer first
>  >>> instead of upstream is not the right thing to do.
>  >>
>  >> +1, in fact that's the biggest design failure in ABRT (in its current
> state)
>  >> and basically makes it useless. Gathering backtraces is something that needs
>  >> to be handled by upstream projects (like KDE does with KCrash/DrKonqi), not
>  >> distributions.
>  
>  To end-users, it's irrelevant "who is supposed to fix something". Their 
>  complaints are against the product call Fedora and thus expect "Fedora 
>  to fix their product".
>  
>  That said: It's irrelevant to Toyota car owners, which supplier 
>  manufactured the parts which have caused Toyota to call back 1000 of 
>  their cars - To them it's Toyota who is reponisible, and Toyota's duty 
>  to fix this issue. 
But Toyota's employees do not do that after work in their free time.
They get paid for it. If someone is paying me to fix bugs for upstream
that's fine and I will try to fix every reported bug. I guess a lot of
Fedora package maintainers do their packaging stuff in their spare free
time and would say it is not the right thing to offload the work to
them.

The analogy between Toyota and Fedora does not convince me ;-)

cheers,
Stefan

[Michael Schwendt]

On Sun, 07 Feb 2010 11:20:04 +0100, Stefan wrote:

>  On So, 2010-02-07 at 09:03 +0100, Ralf Corsepius wrote:
>  > 
>  > To end-users, it's irrelevant "who is supposed to fix something".
> Their 
>  > complaints are against the product call Fedora and thus expect "Fedora 
>  > to fix their product".
>  > 
>  > That said: It's irrelevant to Toyota car owners, which supplier 
>  > manufactured the parts which have caused Toyota to call back 1000 of 
>  > their cars - To them it's Toyota who is reponisible, and Toyota's duty 
>  > to fix this issue.
>  
>  But Toyota's employees do not do that after work in their free time.
>  They get paid for it. If someone is paying me to fix bugs for upstream
>  that's fine and I will try to fix every reported bug. I guess a lot of
>  Fedora package maintainers do their packaging stuff in their spare free
>  time and would say it is not the right thing to offload the work to
>  them.
>  
>  The analogy between Toyota and Fedora does not convince me ;-) 
That's likely.  Because the analogy isn't obvious - and reducing it to a
relationship between a paying customer and a paid worker makes it even
less obvious.

There is an analogy actually. Regardless of whether the Fedora Project
consists of many volunteers, who do unpaid stuff in their spare time,
Fedora delivers a product and will have to deal with its consumers and
negative feedback. The fact that the product is free (as in "free beer")
should not imply that it is worse than a commercial product. How far would
you want to go with regard to a fat disclaimer about "no warranties",
"free of charge", "no support", "hobbyist developers", to
lower a
consumer's expectations?  A huge sticker on top of the product to
advertise against trying it out? What is the added value we [at Fedora]
try to add? Surely it isn't that we just lump together software in form of
RPM packages _without_ testing and _without_ carefully picking releases
and compatible components. Even if we don't guarantee anything, there must
be something quality related, which _we_ _try_ to offer.

It's clear that if upstream software quality is poor and if nobody works
on improving the software, it is more difficult for the Fedora packager to
deliver quality. To shrug one's shoulders in reply to problem reports is
the wrong way, however. And the more problem reports, the more important
it gets to do something. As a last resort, software could get retired and
removed from "The Product".

-- 
Michael Schwendt
Fedora release 12 (Constantine) - Linux 2.6.31.12-174.2.3.fc12.i686.PAE
http://mschwendt.fedorapeople.org/staticbutstat.html

[Stefan Schulze Frielinghaus]

On So, 2010-02-07 at 12:52 +0100, Michael Schwendt wrote:
[...]
>  There is an analogy actually. Regardless of whether the Fedora
> Project
>  consists of many volunteers, who do unpaid stuff in their spare time,
>  Fedora delivers a product and will have to deal with its consumers and
>  negative feedback. The fact that the product is free (as in "free beer")
>  should not imply that it is worse than a commercial product.  
I completely agree and most open source software proofs that, but this
was not the question. The question was if the package maintainer should
be triggered first instead of upstream which increases the load for the
package maintainer who might not be able to handle all of these requests
in the end because it is not his/her full time job.

>  It's clear that if upstream software quality is poor and if
> nobody works
>  on improving the software, it is more difficult for the Fedora packager to
>  deliver quality. To shrug one's shoulders in reply to problem reports is
>  the wrong way, however. And the more problem reports, the more important
>  it gets to do something. As a last resort, software could get retired and
>  removed from "The Product". 
This is at least a good point to me. ABRT might point out software which
needs more attention. If it is not possible to provide the needed power,
then the package should be removed to keep the expected stability of
Fedora.

cheers,
Stefan

[Michael Schwendt]

On Sun, 07 Feb 2010 14:23:13 +0100, Stefan wrote:

>  The question was if the package maintainer should
>  be triggered first instead of upstream which increases the load for the
>  package maintainer who might not be able to handle all of these requests
>  in the end because it is not his/her full time job. 
Well, that isn't straight-forward to answer IMO.

First of all, upstream may not be paid either for working on the software
_and_ on incoming problem reports. What sort of "support" and response
time can you expect from upstream in that case?

Secondly, the package maintainer should be informed about what is broken
with the chosen/packaged software release. Certainly you don't ask for
upstream to filter out *all* reports from all distributions, to return
distribution-specific ones into a dist's own bug tracking system, and to
work on incomplete backtraces or problems that aren't trivial to reproduce
in the absence of the original bug reporter. Depending on the software
quality it may be that upstream cannot handle all that either.

Fedora packages are not fire'n'forget releases. Even if you forwarded
every bugzilla ticket to upstream, you would still need to monitor the
status of the forwarded reports or fix issues yourself, provided that they
matter to you. Whether they should matter to you also depends on project
strategies and goals and whether Fedora wants to deliver added value. In
some cases, the product (or individual packages) may suffer from
insufficient contributor resources, and a single package maintainer
may not be enough.

>  ABRT might point out software which
>  needs more attention. 
That is not its task. Bugzilla statistical queries could examine packages
for a high number of open/unresponded tickets, a growing number of
tickets closed by the bugzapper scripts at dist EOL, a low update
frequency, and a package owner who isn't responsive for other packages
either.


-- 
Michael Schwendt
Fedora release 12 (Constantine) - Linux 2.6.31.12-174.2.3.fc12.i686.PAE
http://mschwendt.fedorapeople.org/staticbugstat.html

[Stefan Schulze Frielinghaus]

On So, 2010-02-07 at 15:34 +0100, Michael Schwendt wrote:
>  On Sun, 07 Feb 2010 14:23:13 +0100, Stefan wrote:
>  
>  > The question was if the package maintainer should
>  > be triggered first instead of upstream which increases the load for the
>  > package maintainer who might not be able to handle all of these requests
>  > in the end because it is not his/her full time job.
>  
>  Well, that isn't straight-forward to answer IMO.
>  
>  First of all, upstream may not be paid either for working on the software
>  _and_ on incoming problem reports. What sort of "support" and response
>  time can you expect from upstream in that case?
>  
>  Secondly, the package maintainer should be informed about what is broken
>  with the chosen/packaged software release. Certainly you don't ask for
>  upstream to filter out *all* reports from all distributions, to return
>  distribution-specific ones into a dist's own bug tracking system, and to
>  work on incomplete backtraces or problems that aren't trivial to reproduce
>  in the absence of the original bug reporter. Depending on the software
>  quality it may be that upstream cannot handle all that either.
>  
>  Fedora packages are not fire'n'forget releases. Even if you forwarded
>  every bugzilla ticket to upstream, you would still need to monitor the
>  status of the forwarded reports or fix issues yourself, provided that they
>  matter to you. Whether they should matter to you also depends on project
>  strategies and goals and whether Fedora wants to deliver added value. In
>  some cases, the product (or individual packages) may suffer from
>  insufficient contributor resources, and a single package maintainer
>  may not be enough. 
Hmm yeah. I see the problem. It would even get worse when e.g. some
patches are applied to the package, then upstream couldn't even debug
properly.

Nasty situation ;-) I will think about it. Hopefully it was not too off
topic.

Thanks for letting me know,
Stefan

[Kevin Kofler]

Michael Schwendt wrote:
>  Secondly, the package maintainer should be informed about what is
> broken
>  with the chosen/packaged software release. Certainly you don't ask for
>  upstream to filter out *all* reports from all distributions, to return
>  distribution-specific ones into a dist's own bug tracking system, 
Most problems are not distribution-specific. For the ones which are, they 
can close the bugs as DOWNSTREAM, NOTOURBUG or whatever their Bugzilla uses 
for that case and tell the user to report them to the distribution. It's 
less work for them do to that for the few bugs which happen to be 
distribution-specific than for us to do the opposite for the common case.

>  and to work on incomplete backtraces or problems that aren't
> trivial to
>  reproduce in the absence of the original bug reporter. 
That's why bugs should not be forwarded by us, but filed directly upstream.

>  Fedora packages are not fire'n'forget releases. 
Once upstream fixes the issue (which will result in bugmail to the 
reporter), it's OK to file a bug to us asking us to backport the fix. But if 
the package is maintained properly (like e.g. KDE), the next release with 
the fix will be pushed soon anyway.

        Kevin Kofler

[Ralf Corsepius]

On 02/07/2010 07:46 PM, Kevin Kofler wrote:
>  Michael Schwendt wrote:
> > Secondly, the package maintainer should be informed about what is broken
> > with the chosen/packaged software release. Certainly you don't ask for
> > upstream to filter out *all* reports from all distributions, to return
> > distribution-specific ones into a dist's own bug tracking system,
>
>  Most problems are not distribution-specific. 
Yes.

>  For the ones which are, they
>  can close the bugs as DOWNSTREAM, NOTOURBUG or whatever their Bugzilla uses
>  for that case and tell the user to report them to the distribution. 
No.

A Fedora maintainer acting this way, is cheating at his users and at 
himself.

All he does, is delegating responsibility on bugs around, while
* "bug remains unfixed" in Fedora
* "user remains exposed to the bug"

Overall, this results into Fedora consisting of packages suffering from 
known bugs. Depending on the severity of such bugs and the amount of the 
such bugs, this easily ends up in a low quality distro.

Ralf

[Kevin Kofler]

Michael Schwendt wrote:
>  As a last resort, software could get retired and removed from
> "The
>  Product". 
I'm not sure not shipping something at all is better for the user than 
shipping it with bugs, even if they never get fixed. Often even a buggy 
software is better than nothing.

        Kevin Kofler

[Ralf Corsepius]

On 02/07/2010 12:52 PM, Michael Schwendt wrote:
>  On Sun, 07 Feb 2010 11:20:04 +0100, Stefan wrote:
>
> > On So, 2010-02-07 at 09:03 +0100, Ralf Corsepius wrote:
> >>
> >> To end-users, it's irrelevant "who is supposed to fix something".
> Their
> >> complaints are against the product call Fedora and thus expect "Fedora
> >> to fix their product".
> >>
> >> That said: It's irrelevant to Toyota car owners, which supplier
> >> manufactured the parts which have caused Toyota to call back 1000 of
> >> their cars - To them it's Toyota who is reponisible, and Toyota's duty
> >> to fix this issue.
> >
> > But Toyota's employees do not do that after work in their free time.
> > They get paid for it. If someone is paying me to fix bugs for upstream
> > that's fine and I will try to fix every reported bug. I guess a lot of
> > Fedora package maintainers do their packaging stuff in their spare free
> > time and would say it is not the right thing to offload the work to
> > them.
> >
> > The analogy between Toyota and Fedora does not convince me ;-)
>
>  That's likely.  Because the analogy isn't obvious - and reducing it to a
>  relationship between a paying customer and a paid worker makes it even
>  less obvious.
>  There is an analogy actually. Regardless of whether the Fedora Project
>  consists of many volunteers, who do unpaid stuff in their spare time,
>  Fedora delivers a product and will have to deal with its consumers and
>  negative feedback. The fact that the product is free (as in "free beer")
>  should not imply that it is worse than a commercial product. 
Exactly. As a "user" I consider the "Fedora distro" to be a product of

the "Fedora Project", regardless of who the people behind this vendor 
actually are and regardless of its price.

>  How far would
>  you want to go with regard to a fat disclaimer about "no warranties",
>  "free of charge", "no support", "hobbyist developers", to
> lower a
>  consumer's expectations? 
To me, "free of charge" only implies "user will not sue vendor".
It's 
not a "card blanche" for "low quality" nor for
"carelessness/negligence" 
nor for "unprofessionalism".

>  A huge sticker on top of the product to
>  advertise against trying it out? What is the added value we [at Fedora]
>  try to add? Surely it isn't that we just lump together software in form of
>  RPM packages _without_ testing and _without_ carefully picking releases
>  and compatible components. Even if we don't guarantee anything, there must
>  be something quality related, which _we_ _try_ to offer.
>
>  It's clear that if upstream software quality is poor and if nobody works
>  on improving the software, it is more difficult for the Fedora packager to
>  deliver quality. 
Right, in such cases "the Fedora product vendor's representative in 
charge" of the "low quality component of the Fedora product" has decide 
upon consequences.

Car manufacturers do the same: It's called QA.

  If a supplier doesn't supply the quality they want, they decide upon 
what to do: "refurbish/fix the component", "return component to 
supplier", switch "supplier", redesign the "component" or even
redesign 
a larger part of the "product", such that other component vendors' 
products can replace the "low quality component".

It's the same in Fedora: If a piece of SW in Fedora is broken, then the 
Fedora maintainers needs to take care about it to prevent to Fedora 
user-base to be exposed to this bugs. Of course, he can optionally 
consult upstream, consult others etc. ... nevertheless it's still the 
Fedora package maintainer who is responsible for is "user-base".

>  To shrug one's shoulders in reply to problem reports is
>  the wrong way, however. And the more problem reports, the more important
>  it gets to do something. As a last resort, software could get retired and
>  removed from "The Product". 
Agreed - ABRT is such a case, IMNSHO. Remove it from the distro and send 
its devs "back to the drawing board".

Ralf

[Kevin Kofler]

Michael Schwendt wrote:
>  I'm happy about every detailed backtrace I get, but I would be
> even more
>  happy if users contributed a tiny bit more and added comments to their
>  tickets and responded to NEEDINFO queries and gave feedback on Test
>  Updates.  ABRT has lowered the hurdle so much that people dump generated
>  reports into bugzilla but otherwise they appear like /dev/null and only
>  show rarely that they care about a package. 
Requests to report the crash upstream usually also fall on deaf ears (when 
all they'd really need to do is copy&paste the generated text and a link to 
the attached backtrace into the upstream bug tracker).

Without some mechanism to either make ABRT file bugs directly upstream or 
automatically forward them (in a way which keeps the reporter in the loop, 
in the hope that they might actually care!), it's basically useless.

There's no way I can fix the dozens of crashes in Gnash myself.

        Kevin Kofler

[drago01]

On Sat, Feb 6, 2010 at 6:56 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Michael Schwendt wrote:
> > I'm happy about every detailed backtrace I get, but I would be even more
> > happy if users contributed a tiny bit more and added comments to their
> > tickets and responded to NEEDINFO queries and gave feedback on Test
> > Updates.  ABRT has lowered the hurdle so much that people dump generated
> > reports into bugzilla but otherwise they appear like /dev/null and only
> > show rarely that they care about a package.
>
>  Requests to report the crash upstream usually also fall on deaf ears (when
>  all they'd really need to do is copy&paste the generated text and a link to
>  the attached backtrace into the upstream bug tracker).
>
>  Without some mechanism to either make ABRT file bugs directly upstream or
>  automatically forward them (in a way which keeps the reporter in the loop,
>  in the hope that they might actually care!), it's basically useless.
>
>  There's no way I can fix the dozens of crashes in Gnash myself. 
Well reports should go to the maintainer first, he should forward it
to upstream as needed.

What needs to be fixed here is bugzilla not ABRT, we need a "report
upstream" button.

[Christoph Wickert]

Am Samstag, den 06.02.2010, 19:27 +0100 schrieb drago01:

>  Well reports should go to the maintainer first, he should forward it
>  to upstream as needed. 
I disagree. Basically there are two situations:
     1. The backtrace or the bug report is incomplete. In 95% of these
        cases submitters don't bother to provide any more info and the
        bug gets closed INSUFFICIENT_DATA. This should not get filed
        upstream at all, nether in Fedora, not somewhere upstream.
     2. The backtrace is fine and self-explanatory for the developer. In
        this case it should go directly to upstream.

>  What needs to be fixed here is bugzilla not ABRT, we need a
> "report
>  upstream" button. 
Ok, and where is the "submit downstream" button in upstream's bug
tracker? The Fedora maintainer still will have to forward replies,
questions, calls for testing etc. from upstream back to the user and
this is a lot of work.

Regards,
Christoph

[Thomas Spura]

Am Samstag, den 06.02.2010, 20:18 +0100 schrieb Christoph Wickert:
>  Am Samstag, den 06.02.2010, 19:27 +0100 schrieb drago01:
>  > What needs to be fixed here is bugzilla not ABRT, we need a "report
>  > upstream" button.
>  
>  Ok, and where is the "submit downstream" button in upstream's bug
>  tracker? The Fedora maintainer still will have to forward replies,
>  questions, calls for testing etc. from upstream back to the user and
>  this is a lot of work. 
Maybe he wants to have our bugzilla and upstreams bugzilla connected, so
that the developer can directly talk to the reporter and propose a fix,
that the maintainer can submit to the testing repos.
Not a bad idea.

	Thomas

[drago01]

On Sat, Feb 6, 2010 at 9:01 PM, Thomas Spura
<spurath(a)students.uni-mainz.de&gt; wrote:
>  Am Samstag, den 06.02.2010, 20:18 +0100 schrieb Christoph Wickert:
> > Am Samstag, den 06.02.2010, 19:27 +0100 schrieb drago01:
> > > What needs to be fixed here is bugzilla not ABRT, we need a "report
> > > upstream" button.
> >
> > Ok, and where is the "submit downstream" button in upstream's bug
> > tracker? The Fedora maintainer still will have to forward replies,
> > questions, calls for testing etc. from upstream back to the user and
> > this is a lot of work.
>
>  Maybe he wants to have our bugzilla and upstreams bugzilla connected, so
>  that the developer can directly talk to the reporter and propose a fix,
>  that the maintainer can submit to the testing repos.
>  Not a bad idea. 
Yeah exactly, I wasn't suggesting that the maintainer should act as a
proxy between user and upstream developer (that would be insane).

[Christoph Wickert]

Am Samstag, den 06.02.2010, 21:59 +0100 schrieb drago01:
>  On Sat, Feb 6, 2010 at 9:01 PM, Thomas Spura
>  <spurath(a)students.uni-mainz.de&gt; wrote:
>  > Am Samstag, den 06.02.2010, 20:18 +0100 schrieb Christoph Wickert:
>  >> Am Samstag, den 06.02.2010, 19:27 +0100 schrieb drago01:
>  >> > What needs to be fixed here is bugzilla not ABRT, we need a "report
>  >> > upstream" button.
>  >>
>  >> Ok, and where is the "submit downstream" button in upstream's bug
>  >> tracker? The Fedora maintainer still will have to forward replies,
>  >> questions, calls for testing etc. from upstream back to the user and
>  >> this is a lot of work.
>  >
>  > Maybe he wants to have our bugzilla and upstreams bugzilla connected, so
>  > that the developer can directly talk to the reporter and propose a fix,
>  > that the maintainer can submit to the testing repos.
>  > Not a bad idea.
>  
>  Yeah exactly, I wasn't suggesting that the maintainer should act as a
>  proxy between user and upstream developer (that would be insane). 
Right, but this is what I am currently spending a lot of my time on. :(

Regards,
Christoph

[Adam Williamson]

On Sat, 2010-02-06 at 14:08 +0100, Michael Schwendt wrote:
>  On Sat, 06 Feb 2010 10:53:14 +0000, Leigh wrote:
>  
>  > IMO ABRT isn't that useful as a lot of the reports don't include steps
>  > to reproduce (I just close the bugs after a month if they don't respond
>  > to the "needinfo" request).
>  > I believe ABRT shouldn't file a bug report unless it is filled in
>  > properly.
>  
>  Yeah, some of us have pointed out that before. 
And, IIRC, Jiri has already agreed and said this will be implemented, so
why bring it up again?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[leigh scott]

On Sat, 2010-02-06 at 13:32 -0800, Adam Williamson wrote:

>  And, IIRC, Jiri has already agreed and said this will be implemented,
> so
>  why bring it up again?
>  -- 
>  Adam Williamson
>  Fedora QA Community Monkey
>  IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
>  http://www.happyassassin.net
>   

I have only recently subscribed to the devel-list and haven't had the
time to trawl though it all.

[Adam Williamson]

On Sat, 2010-02-06 at 21:48 +0000, Leigh Scott wrote:
>  On Sat, 2010-02-06 at 13:32 -0800, Adam Williamson wrote:
>  
>  > And, IIRC, Jiri has already agreed and said this will be implemented, so
>  > why bring it up again?
>  > -- 
>  > Adam Williamson
>  > Fedora QA Community Monkey
>  > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
>  > http://www.happyassassin.net 
>  I have only recently subscribed to the devel-list and haven't had
> the
>  time to trawl though it all. 
Yeah, I actually only meant to send the more polite version of that
email. Damn Evolution :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Adam Williamson]

On Sat, 2010-02-06 at 14:08 +0100, Michael Schwendt wrote:
>  On Sat, 06 Feb 2010 10:53:14 +0000, Leigh wrote:
>  
>  > IMO ABRT isn't that useful as a lot of the reports don't include steps
>  > to reproduce (I just close the bugs after a month if they don't respond
>  > to the "needinfo" request).
>  > I believe ABRT shouldn't file a bug report unless it is filled in
>  > properly.
>  
>  Yeah, some of us have pointed out that before. 
I believe Jiri has already agreed and said this will be implemented.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Frank Ch. Eigler]

Michael Schwendt <mschwendt(a)gmail.com&gt; writes:

> > I believe ABRT shouldn't file a bug report unless it is
> filled in
> > properly.
>
>  Yeah, some of us have pointed out that before.
>  I'm happy about every detailed backtrace I get, but I would be even more
>  happy if users contributed a tiny bit more and added comments to their
>  tickets and responded to NEEDINFO queries and gave feedback on Test
>  Updates. [...] 
How much more useful would it be if ABRT had a mode where executables
that recently reported crashes are subsequently/temporarily run with
syscall tracing in the background, so that if they crash again, then
recent process syscall history can also be optionally included in an
ABRT report?  This would not be hard to do with e.g. systemtap.

- FChE

[Jiri Moskovcak]

On 02/08/2010 05:36 PM, Frank Ch. Eigler wrote:
>  Michael Schwendt<mschwendt(a)gmail.com>  writes:
>
> >> I believe ABRT shouldn't file a bug report unless it is filled in
> >> properly.
> >
> > Yeah, some of us have pointed out that before.
> > I'm happy about every detailed backtrace I get, but I would be even more
> > happy if users contributed a tiny bit more and added comments to their
> > tickets and responded to NEEDINFO queries and gave feedback on Test
> > Updates. [...]
>
>  How much more useful would it be if ABRT had a mode where executables
>  that recently reported crashes are subsequently/temporarily run with
>  syscall tracing in the background, so that if they crash again, then
>  recent process syscall history can also be optionally included in an
>  ABRT report?  This would not be hard to do with e.g. systemtap.
>
>  - FChE 
Such log would be nice, but it might take some time (even days) before 
the app crashes again and I can imagine that could generate quite a 
large log :-/ Maybe if it would store just last few syscalls...

J.

[Frank Ch. Eigler]

Jiri Moskovcak <jmoskovc(a)redhat.com&gt; writes:

>  Such log would be nice, but it might take some time (even days)
> before
>  the app crashes again and I can imagine that could generate quite a
>  large log :-/ Maybe if it would store just last few syscalls... 
Sure, some circular logging, the last few thousand syscalls, no problem.

- FChE

[Denys Vlasenko]

On Sat, 2010-02-06 at 10:53 +0000, Leigh Scott wrote:
>  IMO ABRT isn't that useful as a lot of the reports don't
> include steps
>  to reproduce (I just close the bugs after a month if they don't respond
>  to the "needinfo" request). 
You can do it even sooner. If backtrace is unusable and there is no
description whatsoever, then *this* user is not likely to bother
to do anything to help you.

>  I believe ABRT shouldn't file a bug report unless it is filled
> in
>  properly. 
Sadly, this is impossible to achieve. Sure, we can

if (description == "") yell("Fill the description dammit!");

but then user might well enter description consisting of
"I dont care" (or worse).

-- 
vda

[leigh scott]

On Wed, 2010-02-10 at 15:48 +0100, Denys Vlasenko wrote:

>  but then user might well enter description consisting of
>  "I dont care" (or worse).
>  
>  -- 
>  vda
>  
>   
That would ease my conscience when I closed the bug report :-)

[Nils Philippsen]

On Wed, 2010-02-10 at 15:48 +0100, Denys Vlasenko wrote:
>  On Sat, 2010-02-06 at 10:53 +0000, Leigh Scott wrote:
>  > IMO ABRT isn't that useful as a lot of the reports don't include steps
>  > to reproduce (I just close the bugs after a month if they don't respond
>  > to the "needinfo" request).
>  
>  You can do it even sooner. If backtrace is unusable and there is no
>  description whatsoever, then *this* user is not likely to bother
>  to do anything to help you.
>  
>  > I believe ABRT shouldn't file a bug report unless it is filled in
>  > properly.
>  
>  Sadly, this is impossible to achieve. Sure, we can
>  
>  if (description == "") yell("Fill the description dammit!");
>  
>  but then user might well enter description consisting of
>  "I dont care" (or worse). 
You're contradicting yourself here. First you say we should close bugs
without a description even sooner (like, immediately?), then you don't
want abrt to not file a report without a description. I don't see why we
should manually do the work abrt fails to do automatically -- while it
is automatable.

What strikes me as very puzzling is why abrt has this humongous dialog
instead of leading the user step-by-step through this... I know you just
changed the UI in a stable release. But doing it twice is twice fun ;-),
so why not use a wizard (taking the user by the hand, doing it step by
step...) and do it like this:

1. Check if the bug has been reported yet (via that abrt BZ id thingy).
If yes, ask user to review the description (in their browser?) and
eventually add any additional details (see below in step 3a. for hints
abrt could provide for that), then stop here. Otherwise continue.

2. Check that all debuginfos can be installed etc, then continue. If
not, tell the user that "important debugging data" can't be assembled
right now and a) if they would like to postpone the bug report, if you
assume that it's a temporary problem or b) "there's an update for
package(s) ... which are used by your application, would you like to
install them?", as this seems to be the most common case of debuginfos
not being available.

3a. Display wizard window. Ask users (politely!) for a description of
what they did before the crash happened:

"Please describe what you did before the application crashed. Provide as
much detail as you can, this is important for the person getting the bug
report to help you. If this is too much work for you right now, you can
make some notes about details that are hard to remember in this field,
click on "Postpone report" below

_Hints for filling out this form_

...

[Cancel report] [Postpone report] [Back] [Forward]"

The buttons would be visible on any page in the wizard, [Back] would be
insensitive here because it's the first step. "_Hints for filling out
this form_" would be a link which would open a help page going into much
more detail, e.g.:

"... If you didn't use the app for a long while, state that, but try to
remember what you did when you last used it. Please also describe what
else you did immediately before the crash. ..."

Also provide examples of good and bad descriptions in this.

3b. While the user fills out the description, abrt loads debuginfo
packages in the background. If the user is ready before all are
downloaded, display the usual progress bar.

4. Next wizard page. Display backtrace, ask for review and removal of
sensitive data like passwords. "You don't need to understand most of
this, but if you see data )like passwords) you would not like to be put
into the bug report (which may be seen by anybody), please replace it
with a placeholder (like '<password>')." 

5. Last wizard page. Get confirmation for filing the bug report. "You
can review what will be submitted by using the Back and Forward buttons
at the bottom of this dialog." Fields for Bugzilla username and
password, pre-filled if we have that information already. "[ ] Remember
this information" checkbox.

If the user postponed this, they must have a means of continuing this,
so the applet may not be hidden in this case. While I'm at it, the
applet shouldn't flash forever, this breaks energy-saving measures (if
the user ignored it for a minute, they'll ignore it for an hour -- maybe
wake up it screensaver gets active, then inactive/unlocked).

In my opinion this would be much less intimidating to users and give us
bug reports where we can actually help instead of having to tell most of
them "sorry, too few info, can't help" right away.

Those who don't care enough to fill out the description probably won't
care enough to create a BZ account in the first place. If there are
trolls who would put nonsense into the description or worse, well those
could do that via web-based BZ as well. And they can be dealt with.

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils(a)redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

[Jiri Moskovcak]

On 02/12/2010 03:15 AM, Nils Philippsen wrote:
>  On Wed, 2010-02-10 at 15:48 +0100, Denys Vlasenko wrote:
> > On Sat, 2010-02-06 at 10:53 +0000, Leigh Scott wrote:
> >> IMO ABRT isn't that useful as a lot of the reports don't include steps
> >> to reproduce (I just close the bugs after a month if they don't respond
> >> to the "needinfo" request).
> >
> > You can do it even sooner. If backtrace is unusable and there is no
> > description whatsoever, then *this* user is not likely to bother
> > to do anything to help you.
> >
> >> I believe ABRT shouldn't file a bug report unless it is filled in
> >> properly.
> >
> > Sadly, this is impossible to achieve. Sure, we can
> >
> > if (description == "") yell("Fill the description dammit!");
> >
> > but then user might well enter description consisting of
> > "I dont care" (or worse).
>
>  You're contradicting yourself here. First you say we should close bugs
>  without a description even sooner (like, immediately?), then you don't
>  want abrt to not file a report without a description. I don't see why we
>  should manually do the work abrt fails to do automatically -- while it
>  is automatable.
>
>  What strikes me as very puzzling is why abrt has this humongous dialog
>  instead of leading the user step-by-step through this... I know you just
>  changed the UI in a stable release. But doing it twice is twice fun ;-),
>  so why not use a wizard (taking the user by the hand, doing it step by
>  step...) and do it like this:
>
>  1. Check if the bug has been reported yet (via that abrt BZ id thingy).
>  If yes, ask user to review the description (in their browser?) and
>  eventually add any additional details (see below in step 3a. for hints
>  abrt could provide for that), then stop here. Otherwise continue.
>
>  2. Check that all debuginfos can be installed etc, then continue. If
>  not, tell the user that "important debugging data" can't be assembled
>  right now and a) if they would like to postpone the bug report, if you
>  assume that it's a temporary problem or b) "there's an update for
>  package(s) ... which are used by your application, would you like to
>  install them?", as this seems to be the most common case of debuginfos
>  not being available.
>
>  3a. Display wizard window. Ask users (politely!) for a description of
>  what they did before the crash happened:
>
>  "Please describe what you did before the application crashed. Provide as
>  much detail as you can, this is important for the person getting the bug
>  report to help you. If this is too much work for you right now, you can
>  make some notes about details that are hard to remember in this field,
>  click on "Postpone report" below
>
>  _Hints for filling out this form_
>
>  ...
>
>  [Cancel report] [Postpone report] [Back] [Forward]"
>
>  The buttons would be visible on any page in the wizard, [Back] would be
>  insensitive here because it's the first step. "_Hints for filling out
>  this form_" would be a link which would open a help page going into much
>  more detail, e.g.:
>
>  "... If you didn't use the app for a long while, state that, but try to
>  remember what you did when you last used it. Please also describe what
>  else you did immediately before the crash. ..."
>
>  Also provide examples of good and bad descriptions in this.
>
>  3b. While the user fills out the description, abrt loads debuginfo
>  packages in the background. If the user is ready before all are
>  downloaded, display the usual progress bar.
>
>  4. Next wizard page. Display backtrace, ask for review and removal of
>  sensitive data like passwords. "You don't need to understand most of
>  this, but if you see data )like passwords) you would not like to be put
>  into the bug report (which may be seen by anybody), please replace it
>  with a placeholder (like '<password>')."
>
>  5. Last wizard page. Get confirmation for filing the bug report. "You
>  can review what will be submitted by using the Back and Forward buttons
>  at the bottom of this dialog." Fields for Bugzilla username and
>  password, pre-filled if we have that information already. "[ ] Remember
>  this information" checkbox.
>
>  If the user postponed this, they must have a means of continuing this,
>  so the applet may not be hidden in this case. While I'm at it, the
>  applet shouldn't flash forever, this breaks energy-saving measures (if
>  the user ignored it for a minute, they'll ignore it for an hour -- maybe
>  wake up it screensaver gets active, then inactive/unlocked).
>
>  In my opinion this would be much less intimidating to users and give us
>  bug reports where we can actually help instead of having to tell most of
>  them "sorry, too few info, can't help" right away.
>
>  Those who don't care enough to fill out the description probably won't
>  care enough to create a BZ account in the first place. If there are
>  trolls who would put nonsense into the description or worse, well those
>  could do that via web-based BZ as well. And they can be dealt with.
>
>  Nils 
Hi,
Thanks for good hints, I'm already working on a wizard style gui for 
ABRT, to walk the user thru the reporting proccess, so I'll definitely 
implement some of you ideas into it.

Thanks,
Jirka

[Till Maas]

On Fri, Feb 12, 2010 at 03:15:39AM +0100, Nils Philippsen wrote:

>  What strikes me as very puzzling is why abrt has this humongous
> dialog
>  instead of leading the user step-by-step through this... I know you just
>  changed the UI in a stable release. But doing it twice is twice fun ;-),
>  so why not use a wizard (taking the user by the hand, doing it step by
>  step...) and do it like this: 
For me the dialog works pretty well and I suspect a wizard would only
slowdown it. So if there is some wizard added, please make it optional.

Regards
Till

[Nils Philippsen]

On Fri, 2010-02-12 at 10:42 +0100, Till Maas wrote:
>  On Fri, Feb 12, 2010 at 03:15:39AM +0100, Nils Philippsen wrote:
>  
>  > What strikes me as very puzzling is why abrt has this humongous dialog
>  > instead of leading the user step-by-step through this... I know you just
>  > changed the UI in a stable release. But doing it twice is twice fun ;-),
>  > so why not use a wizard (taking the user by the hand, doing it step by
>  > step...) and do it like this:
>  
>  For me the dialog works pretty well and I suspect a wizard would only
>  slowdown it. So if there is some wizard added, please make it optional. 
I guess the normal all-in-one dialog is simple enough that it can be
kept as an option.

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils(a)redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

[Karel Klic]

Christoph Wickert wrote:
>  What's wrong with ABRT? ALl the backtraces I get are unusable
> again. If
>  Thunar crashes, not even Thunar-debuginfo gets installed. 
There is a flaw in ABRT 1.0.4, which allows to submit incomplete 
backtraces. It got into the source code during the GUI rewrite.

There is abrt-1.0.6 in Fedora 12 testing repository, which contains a 
fix for this issue.

>  abrt 1.0 worked here, then came 1.0.2 which was broken. 1.0.3 was
>  working again, but got superseded be 1.0.4 only a few of days later.
>  This means that most of the time, all the bugs submitted are basically
>  useless. 
It became better with later releases, but the bug you described made it 
bad again (for this release).

As far as I can tell, the last large-scale change (the new GUI) was 
finished in 1.0.4. It introduced some bugs, but those are fixed now.
A lot of people complained about the old GUI, so it seemed to us (the 
ABRT team) that the GUI overhaul was mandatory. Well, some people 
complain about the current GUI, but IMHO its better.

The latest version (1.0.6) contains mostly bug fixes, so it should not 
break things, it should make ABRT reports sane again.

>  For me as the maintainer it is a lot of work to reply to all these
>  useless reports and for our users it's just frustrating if all their
>  reports get closed INSUFFICIENT_DATA. 
IMHO it's not so frustrating for users, as it is frustrating for some 
maintainers. Users want to help by reporting crashes, but it doesn't 
make you sad when the crash you just reported was not useful at the end 
(you invested a few clicks in reporting that crash).

ABRT hurt some maintainers in Fedora 12. I believe the following Fedora 
releases will benefit from ABRT, as the crashes in the bleeding edge 
software introduced in every release will be quickly detected and fixed.

I am now going to write a script which detects all the backtraces 
without debuginfo in Bugzilla, and closes the bugs as INSUFFICIENT_DATA 
with an apology. I do not know how many of them are in Bugzilla, but 
those can be detected and closed automatically (more info soon, it 
should be hacked together quickly).

>  If the situation doesn't change any time soon, we IMHO should
> consider
>  disabling abrt until the issues are fixed. 
Please consider testing and adding +1 karma to ABRT 1.0.6 in Bodhi.

Also a script [1] which finds all the duplicate backtraces (we can find) 
in Bugzilla has been written. Those duplicates were made by older ABRT 
versions without good duplicate detection. ~900 bugs can be closed with 
this script. Hopefully it removes some burden from package maintainers.

[1] https://fedorahosted.org/abrt/browser/src/Backtrace/abrt-bz-dupchecker

Best Regards,
Karel

[Laurent Rineau]

Le samedi 06 février 2010 18:03:23, Karel Klic a écrit :
>  Christoph Wickert wrote:
>  > What's wrong with ABRT? ALl the backtraces I get are unusable again. If
>  > Thunar crashes, not even Thunar-debuginfo gets installed.
>  
>  There is a flaw in ABRT 1.0.4, which allows to submit incomplete
>  backtraces. It got into the source code during the GUI rewrite. 
Anyway, there should be a tool in ABRT suite, that allows a package maintainer 
to reconstruct a complete backtrace from an incomplete on, using only the list 
of involved packages, with there evr(+arch).

-- 
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau

[Mathieu Bridon]

On Sat, Feb 6, 2010 at 18:03, Karel Klic <kklic(a)redhat.com&gt; wrote:
>  It became better with later releases, but the bug you described made
> it
>  bad again (for this release).
>
>  As far as I can tell, the last large-scale change (the new GUI) was
>  finished in 1.0.4. It introduced some bugs, but those are fixed now. 
Was it really a good idea to push it to a stable release of Fedora if
it was such a « large-scale change » ?


----------
Mathieu Bridon

[Kevin Fenzi]

On Sat, 06 Feb 2010 18:03:23 +0100
Karel Klic <kklic(a)redhat.com&gt; wrote:

...snip...

>  Please consider testing and adding +1 karma to ABRT 1.0.6 in Bodhi.
Sadly, I don't think it's going to get much testing currently. 

The only folks who can test it are those that just enable
updates-testing and update abrt. Anyone who keeps updates-testing
enabled fully will have the newer kernel that doesn't work with
abrt. ;( 

So, I think we need a fixed kernel in updates-testing and wait a bit
before pushing this to stable, IMHO. 

kevin

[Genes MailLists]

On 02/06/2010 03:50 PM, Kevin Fenzi wrote:
rt. ;(
>  
>  So, I think we need a fixed kernel in updates-testing and wait a bit
>  before pushing this to stable, IMHO. 
>  
>  kevin
>   
 Surely you're not suggesting holding up a decent kernel from going to
stable while waiting for Abrt ?

[Karel Klic]

Karel Klic wrote:
>  Christoph Wickert wrote:
> > For me as the maintainer it is a lot of work to reply to all these
> > useless reports and for our users it's just frustrating if all their
> > reports get closed INSUFFICIENT_DATA.
>
>  I am now going to write a script which detects all the backtraces
>  without debuginfo in Bugzilla, and closes the bugs as INSUFFICIENT_DATA
>  with an apology. I do not know how many of them are in Bugzilla, but
>  those can be detected and closed automatically (more info soon, it
>  should be hacked together quickly). 
The script to find backtraces without debuginfo has been written[1]. I 
placed the list of found bugs to the Fedora wiki [2]. IMHO only bugs 
with 2 comments should be closed, because 2 comments mean that the 
package maintainer did not touch the bug (ABRT adds 2 comments to every 
bug it creates). We can close 129 bugs this way.

>  Also a script [1] which finds all the duplicate backtraces (we can
> find)
>  in Bugzilla has been written. Those duplicates were made by older ABRT
>  versions without good duplicate detection. ~900 bugs can be closed with
>  this script. Hopefully it removes some burden from package maintainers.
>
>  [1] https://fedorahosted.org/abrt/browser/src/Backtrace/abrt-bz-dupchecker 
Its 551
bugs that can be closed as duplicates, not 900. I placed the 
list of affected bugs to the Fedora wiki [3].

So I'd like to close over 600 bugs in Bugzilla using scripts. Is there 
some Fedora policy regulating this?

[1] https://fedorahosted.org/abrt/browser/scripts/abrt-bz-ratingfixer
[2] https://fedoraproject.org/wiki/User:Kklic/ABRT_Incomplete_Backtraces
[3] https://fedoraproject.org/wiki/User:Kklic/ABRT_Duplicates

Best Regards,
Karel

[Christoph Wickert]

Am Sonntag, den 07.02.2010, 22:26 +0100 schrieb Karel Klic:

>  The script to find backtraces without debuginfo has been written[1]. 
Thanks a lot for your work and for your latest mail as well!

>  I 
>  placed the list of found bugs to the Fedora wiki [2]. IMHO only bugs 
>  with 2 comments should be closed, because 2 comments mean that the 
>  package maintainer did not touch the bug (ABRT adds 2 comments to every 
>  bug it creates). We can close 129 bugs this way. 
This means that the active maintainers, who responded to their reports
and asked for more info will have no benefit from the script and the
ones who ignored the abrt reports did right. Isn't it ironic?

>  > [1]
> https://fedorahosted.org/abrt/browser/src/Backtrace/abrt-bz-dupchecker
>  Its 551 bugs that can be closed as duplicates, not 900. I placed the 
>  list of affected bugs to the Fedora wiki [3]. 
IMO all lists should be sorted by package owner. I own ~ 120 packages
and it is a quite lot of work to search all these packages in your
lists.

Regards,
Christoph

[Karel Klic]

On 02/08/2010 02:22 AM, Christoph Wickert wrote:
>  Am Sonntag, den 07.02.2010, 22:26 +0100 schrieb Karel Klic:
> > I
> > placed the list of found bugs to the Fedora wiki [2]. IMHO only bugs
> > with 2 comments should be closed, because 2 comments mean that the
> > package maintainer did not touch the bug (ABRT adds 2 comments to every
> > bug it creates). We can close 129 bugs this way.
>
>  This means that the active maintainers, who responded to their reports
>  and asked for more info will have no benefit from the script and the
>  ones who ignored the abrt reports did right. Isn't it ironic? 
Yes, that is
unfortunate. However, it is not polite to close a bug in 
the middle of some discussion. I can go through the remaining 80 bugs 
and close some of them manually.

> >> [1]
> https://fedorahosted.org/abrt/browser/src/Backtrace/abrt-bz-dupchecker
> > Its 551 bugs that can be closed as duplicates, not 900. I placed the
> > list of affected bugs to the Fedora wiki [3].
>
>  IMO all lists should be sorted by package owner. I own ~ 120 packages
>  and it is a quite lot of work to search all these packages in your
>  lists. 
I'll try to do it.

Karel

[Karel Klic]

On 02/08/2010 06:11 PM, Karel Klic wrote:
>  On 02/08/2010 02:22 AM, Christoph Wickert wrote:
> > Am Sonntag, den 07.02.2010, 22:26 +0100 schrieb Karel Klic:
> > IMO all lists should be sorted by package owner. I own ~ 120 packages
> > and it is a quite lot of work to search all these packages in your
> > lists.
>  I'll try to do it. 
Both lists are now sorted by package owner:
https://fedoraproject.org/wiki/User:Kklic/ABRT_Duplicates
https://fedoraproject.org/wiki/User:Kklic/ABRT_Incomplete_Backtraces

[Adam Williamson]

On Sun, 2010-02-07 at 22:26 +0100, Karel Klic wrote:

>  So I'd like to close over 600 bugs in Bugzilla using scripts. Is
> there 
>  some Fedora policy regulating this? 
It would be best to contact the maintainer of RH Bugzilla, Dave
Lawrence; he'll be able to advise you how to proceed.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Jiri Moskovcak]

I don't want to answer all of the messages, so I'll try to sum all of it 
in this one...

On 02/05/2010 09:46 PM, Christoph Wickert wrote:
>  What's wrong with ABRT? ALl the backtraces I get are unusable
> again. If
>  Thunar crashes, not even Thunar-debuginfo gets installed.
>
>  abrt 1.0 worked here, then came 1.0.2 which was broken. 1.0.3 was
>  working again, but got superseded be 1.0.4 only a few of days later.
>  This means that most of the time, all the bugs submitted are basically
>  useless.
>  
Unfortunately that's true, it was different problem every time, but the 
result is the useless backtrace. This shouldn't happen anymore as we now 
have more extensive testing before releasing a new version.

>  For me as the maintainer it is a lot of work to reply to all these
>  useless reports and for our users it's just frustrating if all their
>  reports get closed INSUFFICIENT_DATA.
>  
If the current situation is really so bad, we can auto-close all of the 
bugs reported by the broken versions of ABRT, because I guess they would 
just sit there until bugzapping period.

>  If the situation doesn't change any time soon, we IMHO should
> consider
>  disabling abrt until the issues are fixed.
>  
It's already fixed in 1.0.6, which sits in testing repo. In F12 there is 
a pending kernel update which (if gets to F12 without change) will 
prevent ABRT from detecting C/C++ apps crashes, so it will probably make 
abrt silent for a while.


Now some answers for issues mentioned in this thread:

ABRT doesn't work by design:
- it actually does work, but it's bug detection/analyse is too general 
for some apps, this is something we know about and it's not in our 
powers to fix (it's not even considered a bug). This is actually the 
reason why is ABRT extendible by plugins and every devel who maintains 
some bigger app can write it's own abrt plugin to make the reports to 
suit his needs. If devel doesn't want to get ABRT reports at all, he can 
always send me an email and it can be added to ABRT blacklist.

I feel the Fedora community is being abused to evaluate a 
semi-functional piece of SW's "yet uncooked" concepts:
- tha ABRT's concept is used for a while in other distros and ABRT 
itself is in Fedora since F10, but nobody cared to take a look at it and 
add some comments/ideas. I don't want to start a fight about 
non-finished apps in Fedora, but I won't silently ignore it, I remeber 
quite well the how finished and stable was the last major release of one 
of the major desktop environment or I remember times when I had to use 
web mail instead of my favourite client to write an email, because it 
wasn't stable (and both were in stable Fedora release).


Nice idea. IMO it should only allow to submit reports after some sanity
checks:
- ABRT uses the code from Dr.Konqui to rate the backtrace and doesn't 
allow user to send it if the rate is bellow 3 (the scale is 0-4), but 
the bug in GUI let user to send even the bad BT.

I believe ABRT shouldn't file a bug report unless it is filled in
properly:

- we can change to GUI, so it won't let users fill a report without 
providing a steps to reproduce

History tells, low quality automated bug reports to be ignored and to
cause a lot of bad blood. Debian for instance has an unfortunate history 
in doing so - You're better off to learn from their historic mistake:
- times changes, Linux is now used by people who actually use it for 
work not for the "fun of using Linux" and these people doesn't want to 
spend time going thru bugzilla and filling some report. Yes, I agree we 
should learn and in this we should learn from someone more desktop 
oriented then Debian (maybe even from some non-Linux os??)

What needs to be fixed here is bugzilla not ABRT, we need a "report
upstream" button:
- the best would be to fix both. what we need to ease the life of 
maintainers is a middle layer between ABRT (users) and 
bugzilla(developers) something like mozilla 
has(http://crash-stats.mozilla.com/).


Surely you're not suggesting holding up a decent kernel from going to
stable while waiting for Abrt ?
- there is no need to wait for ABRT when talking about the pending 
kernel update update for F12, there is nothing what ABRT can do to work 
with that kernel.


Anyway, there should be a tool in ABRT suite, that allows a package 
maintainer to reconstruct a complete backtrace from an incomplete on, 
using only the list of involved packages, with there evr(+arch):
- you can never get the whole BT without a coredump - you can get 
recreating should be a matter of a simple script and we can provide it 
as part of ABRT if devels would use it.


I hope I've cleared few things and will be happy to answer any of you 
further questions and RFEs.

Jirka

[Jerry James]

On Sun, Feb 7, 2010 at 6:16 AM, Jiri Moskovcak <jmoskovc(a)redhat.com&gt; wrote:
>  - it actually does work, but it's bug detection/analyse is too
> general for
>  some apps, this is something we know about and it's not in our powers to fix
>  (it's not even considered a bug). This is actually the reason why is ABRT
>  extendible by plugins and every devel who maintains some bigger app can
>  write it's own abrt plugin to make the reports to suit his needs. If devel
>  doesn't want to get ABRT reports at all, he can always send me an email and
>  it can be added to ABRT blacklist. 
Where can information about the plugin API be found?  The abrt-plugins
man page has very little information.  It basically just says to read
PLUGINS-HOWTO "in the documentation directory".  Which documentation
directory is that?  I don't see such a file in any of the abrt-*
packages.  (I expected to find it in abrt-devel, BTW.  That package
contains only 2 symlinks.  Where are the header files?  Are they not
needed by plugin authors?)

Thanks,
-- 
Jerry James
http://www.jamezone.org/

[Jiri Moskovcak]

On 02/08/2010 05:05 PM, Jerry James wrote:
>  On Sun, Feb 7, 2010 at 6:16 AM, Jiri
> Moskovcak<jmoskovc(a)redhat.com>  wrote:
> > - it actually does work, but it's bug detection/analyse is too general for
> > some apps, this is something we know about and it's not in our powers to fix
> > (it's not even considered a bug). This is actually the reason why is ABRT
> > extendible by plugins and every devel who maintains some bigger app can
> > write it's own abrt plugin to make the reports to suit his needs. If devel
> > doesn't want to get ABRT reports at all, he can always send me an email and
> > it can be added to ABRT blacklist.
>
>  Where can information about the plugin API be found?  The abrt-plugins
>  man page has very little information.  It basically just says to read
>  PLUGINS-HOWTO "in the documentation directory".  Which documentation
>  directory is that?  I don't see such a file in any of the abrt-*
>  packages.  (I expected to find it in abrt-devel, 
Yes, it should be in devel package, will fix this.

http://git.fedorahosted.org/git/abrt.git?p=abrt.git;a=blob_plain;f=doc/PL...

>  BTW.  That package
>  contains only 2 symlinks.  Where are the header files?  Are they not
>  needed by plugin authors?)
>  
Good point, so far nobody wrote a plugin outside of abrt git, so the 
devel package wasn't actually never used :-/ I will add the required .h 
files into the package and it will be fixed in 1.0.7. Until it's fixed 
in rpm, you can download and hack the code using our git from here:

https://fedorahosted.org/abrt/wiki/AbrtInstallation

Jirka

[Adam Williamson]

On Sun, 2010-02-07 at 14:16 +0100, Jiri Moskovcak wrote:

>  because I guess they would just sit there until bugzapping period. 
There's no 'bugzapping period', exactly. BugZappers work all the time,
but only on a small subset of all Fedora packages, we simply do not have
the manpower to cover all of them. So for the many packages which are
not covered by Bugzappers, reports just sit there until the maintainer
chooses to deal with them, or they get killed due to the release for
which they were filed going EOL.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Jiri Moskovcak]

On 02/09/2010 04:17 AM, Adam Williamson wrote:
>  On Sun, 2010-02-07 at 14:16 +0100, Jiri Moskovcak wrote:
>
> > because I guess they would just sit there until bugzapping period.
>  
>  or they get killed due to the release for
>  which they were filed going EOL. 
That's what I meant :)

J.

[Adam Williamson]

On Tue, 2010-02-09 at 09:42 +0100, Jiri Moskovcak wrote:
>  On 02/09/2010 04:17 AM, Adam Williamson wrote:
>  > On Sun, 2010-02-07 at 14:16 +0100, Jiri Moskovcak wrote:
>  >
>  >> because I guess they would just sit there until bugzapping period.
>  >
>  
>  > or they get killed due to the release for
>  > which they were filed going EOL.
>  
>  That's what I meant :) 
ahh. doh. /me feels silly :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Christoph Wickert]

Am Sonntag, den 07.02.2010, 14:16 +0100 schrieb Jiri Moskovcak:

>  - ABRT uses the code from Dr.Konqui to rate the backtrace and
> doesn't 
>  allow user to send it if the rate is bellow 3 (the scale is 0-4), but 
>  the bug in GUI let user to send even the bad BT. 
I think this bug should be fixed now in 1.0.6, but the rating doesn't
work. A backtrace with no debuginfo was rated 3 (while it should be 0 I
guess).

https://bugzilla.redhat.com/show_bug.cgi?id=565387

Regards,
Christoph