Re: Killing bug-buddy?

[Olav Vitters <olav vitters nl>]

On Fri, Aug 26, 2011 at 07:25:06AM +0200, Milan Crha wrote:
> On Fri, 2011-08-26 at 00:05 +0200, Olav Vitters wrote:
> > That all said, I propose killing bug-buddy and recommending the usage
> > of ABRT.
> 
> well, there are things about ABRT you might want to know. The feature of
> "ABRT talking to bugzilla" is not that great, as it talks to downstream
> bugzilla only, it doesn't know how to talk to upstream bugzilla like the
> Gnome's. You might notice significantly less bug crashers reported by

I checked the following presentation after sending the initial email:
https://fedorahosted.org/abrt/attachment/wiki/Features/abrt20_vda.odp

It has the following:
"Example: coreutils wants reports to go to their Bugzilla

Coreutils installs /etc/abrt/events.d/coreutils.conf:
EVENT=report_Bugzilla component=coreutils
      abrt-action-bugzilla -c /etc/abrt/plugins/CoreutilsBugzilla.conf

      Coreutils installs /etc/abrt/plugins/CoreutilsBugzilla.conf with
      URL pointing to their Bugzilla."

I'm guessing it does this based on the rpm package name. Further, when
trying to use ABRT on Mageia it eventually tried to load a Yum Python
library which obviously failed. I guess there is some work to do here. :P

> regular users since ABRT got in use, those bugs are usually moved
> manually to Gnome's bugzilla. Though 'usually' here doesn't mean much,
> because there is no enough man power to investigate and move each ABRT
> downstream report to upstream, basically the work I would expect triage
> team does, thus one might become a monkey for moving bugs between
> bugzillas instead of fixing those bugs. What's the gain of ABRT then?

Every jhbuild ABRT bugreport should automatically go to GNOME bugzilla.
For standard packages, it depends if there are patches.

> But to be correct, I was told that there is only a matter of writing a
> plugin for Gnome bugzilla (I do not know whether it is written already
> or not, I lost track of it after more than a year), so maybe once that
> is written, and downstream packagers will be able to instruct ABRT to
> use certain bugzilla instead of the distribution's (which might be
> already possible with latest ABRT, I suppose), then that will be the
> time when ABRT will be usable for upstream projects too.

To get a new Bugzilla we'd need development work anyway:
1. Change Bug-Buddy to work with standard Bugzilla
2. Change new Bugzilla to work with Bug-Buddy method (dislike this)
3. Make use of ABRT and change that to suit our needs

I prefer #3; ideally a distribution should just have one way to report
crashes (like packagekit). Not sure how feasible that is though. I know
Ubuntu has different infra

I do dislike the ABRT UI (looked at 2.x version). It seems *way* too
complicated (exposes too much of the underlying configurability).

> I guess you want to kill bug-buddy for regular users only, as you was
> talking about bugzilla connection, because ABRT is unusable for
> developers, as it silently ignores crashes in applications which are not
> packaged, furthermore, if you enable to catch crashes of unpackaged

Do you know how difficult would it to change that behaviour in ABRT?
Make it support jhbuild?

> applications, then it is not able to get the backtrace right. That's a
> reason why I resurrected bug-buddy on my machine, also for gtk3
> applications, thus I know why my application is crashing, and when.

Doesn't it just run gdb? I'd still think it is best to fix ABRT than to
have multiple tools to report crashers.

> Anyway, from my point of view, if there will be a real replacement of
> bug-buddy, which for ABRT means being able to directly report to
> upstream bugzilla for upstream projects, then I'm totally for it.

That is the idea for jhbuild stuff. For distro stuff: I'd prefer if it
checks:
1. If the GNOME version is not too old
2. If there aren't any patches (hopefully we can have some magic in the
spec file?)
-- 
Regards,
Olav