it is an unclean (my diplomatic term for dirty) solution. There is no feedback to the user except that the crash report has been 'accepted'. There really should be a message displayed that it has been reported before, and preferrably some information on the progress (e.g. problem is not confirmed yet, problem has been fixed and will be gone with the next update)
Definitely. The most important thing we need to remember about any solution is that the bug process must stay transparent for the user. Personally, that the transparency is the most exciting part about open source, and having my well typed bug report disappear into the void would be very dissatisfying. Stu Hood On 12/6/06, Christian Kirbach <[EMAIL PROTECTED]> wrote:
On Wed, 29 Nov 2006 13:53:12 +0100, Fernando Herrera <[EMAIL PROTECTED]> wrote: > On 11/28/06, Andre Klapper <[EMAIL PROTECTED]> wrote: >> more reports, which either means that the bugsquad needs more volunteer >> triagers, or that we need more automation. I'd say we require some automation here. I started work on some kind of "exact-dup-finder" that could be of use to bugsquad and bug-buddy. Due to time and skill constraints I did no make any progress yet. >> 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). it is an unclean (my diplomatic term for dirty) solution. There is no feedback to the user except that the crash report has been 'accepted'. There really should be a message displayed that it has been reported before, and preferrably some information on the progress (e.g. problem is not confirmed yet, problem has been fixed and will be gone with the next update) > 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 Recall that there are distributions with long upgrade cycles like Debian. Users of these simply may not be able to upgrade at all. > 3) Check distribution version/release; if there are updates out there > don't allow to send if/ask for upgrade Some list could be manually maintained and checked by bug-buddy for this purpose. > 4) Same as 3, but at package level The best way to do this is probably by using the package management system provided by the distribution. -- Christian Kirbach [EMAIL PROTECTED] +49 176 23861781 _______________________________________________ Gnome-bugsquad mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-bugsquad
_______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
