On 11/28/06, Andre Klapper <[EMAIL PROTECTED]> 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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
