Re: bug-buddy was branched silently some time ago

["Fernando Herrera" <fherrera onirica com>]

On 11/28/06, Andre Klapper <ak-47 gmx net> wrote:
> as the GNOME community and user base grows, we have to handle more and
> more reports, which either means that the bugsquad needs more volunteer
> triagers, or that we need more automation.
> the latter one should be the way to go.

I'm trying to make some numbers here.

in one week (from 22th Nov to today) we got 401 new bugs for the
nautilus-* components. Of those 375 where opened with the new
bud-buddy and 26 by hand of by older bug-buddy.

So basically we are getting a x14 more bugs, taking into account that
maybe only 10% of GNOME users are using a 2.16 version.

Looking at those 375 bugs filled by the new bud-buddy, 236 have been
marked as duplicated, that is more than 62%!!! Doing that work by hand
is too much, and it's not going to scale very well when we get more
deployments of GNOME > 2.16.


> what will be possible by achieving this?
> we can reject duplicates and tell the user about this (okay - we can do
> this already by pretending that the user has filed the original bug
> report[1], but this is more a hack than a solution).

Well, Olav stack-trace autorejection is working great but now we need
to add this traces by hand. Maybe in the future we can have a module
detecting automatically those common backtraces and doing the
autorejection without any user intervention.

> we can tell the user that he is using an obsolete version, and directly
> reject the bug report.

We were doing that on previous versions of bug-buddy. We could add
this check. I have some diffrent ideas here:
1) Warn the user that its software is 1 year old and should update
2) Don't allow the user to send the report if he is using 1 year old
distribution
3) Check distribution version/release; if there are updates out there
don't allow to send if/ask for upgrade
4) Same as 3, but at package level

1) and 2) are trivial to reimplement
3) and 4) Could be difficult, but if we are able to build the debug
server infrastructure we would have a database of every common
package/distro out there, so we would be able to easily check if one
offending program/dependency has a new updated version, and expose
this using an XML-RPC for bug-buddy checkings.


> if every gnome bugzilla product has a boolean value providing its
> maintenance state, we can also tell the user that he/she should not
> expect fixes, as that product is currently unmaintained.
> we can tell the user that his issue has been fixed already and that his
> distribution provides an update (a result of this could be to provide a
> direct "update" button for each distribution).

For implementing this sutff we would need to extend our bugzilla/debug
server to collect some info about what upstream package fixed every
version of our bugs. This could be a big amount of work. Maybe we
could set the rule to set the target milestion entry in bugzilla to
the next released version including the fix, so for example:

1) User get a crash
2) bug-buddy send minidump to debug server
3) debug server finds that that trace is a dup of bug 555
4) debug server contacts b.g.o to check if 555 is fixed
5) if 555 is fixed, check TM version, let say version XYZ has the fix
6) debug server looks its package database for a XYZ version of the
offending package. If that XYZ version is in debug server database for
the user distro (bug-buddy told about that in the minidump file).
Check if that package is an update for current user distribution
version or it is only present in the next distro release, respond the
user.

So the user could finally see:

"Thank you for your report. We have already fixed this problem [click
here for a detailed track of it]."

and
"There is not current single update for this issue available for you
and you should update your whole distribution"

or
"Click here to install an update that fixes this problem"

Of course this update thing should containg specific backend for every distro.

Anyway, as said, this is a big amount of work and I don't spec to have
it for the first versions of the debug server infrastructure, but we
can keep it in mind during design so we could implement it later.


> we should also take care of i18n here by having bug-buddy submit the
> user's LANG setting, so the feedback language could be
> adjusted/translated.

Yup, that would be a nice and easy adition to bug-buddy report. Want
to write a patch? :)


> can i expect some work on this?

Yes from my side, but as every Free Software project as many
contributors/help we got, earlier we will get results. Also keep in
mind that we would need the mentioned hardware/bandwith at some point.

Salu2