Re: dropping bug-buddy reports for old version of gnome automatically
On Sat, Apr 07, 2007 at 05:13:04PM +0200, Paolo Borelli wrote: As far as I am concerned I'd like to drop any reports from 2.16 and below, but I see how that may be a little to aggressive. What about dropping reports from 2.14 and below? Bug-Buddy reports from 2.14 and older are now rejected at the mail server (with a pointer to either upgrade or use the webinterface). -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dropping bug-buddy reports for old version of gnome automatically
El mar, 10-04-2007 a las 19:02 -0600, Elijah Newren escribió: On 4/9/07, Federico Mena Quintero [EMAIL PROTECTED] wrote: Still, this can be an indication that your fixes are not reaching the affected people. Maybe you need to explicitly poke the distro(s) in question and tell them, this fixes a bug that 5000 of your users have reported; can you release a new package through your update channels?. Which won't necessarily reach them either, as that assumes the users will all update their packages and there won't be new installations without automatic updates before usage. (Bug 94625 received duplicate filings for _years_ after RedHat pushed out updates to fix the problem. In fact, it received another one just last month.) Could this happen: 1. bug-buddy tells bugzilla which distro/version you are using, and the package version/revision. 2. bugzilla tells bug-buddy I know this has been fixed in version'/revision' for that distro 3. bug-buddy tells you, This bug is already fixed in your distro. Please update to package-version'-revision'. This assumes that someone feeds bugzilla with the info it needs to do (2), but that sounds doable with a little coordination in distributor-list :) Or maybe this can't happen during a run of bug-buddy, since the duplicate bug needs to be triaged. I don't know if we can steal some ideas from here to make triaging automatic for frequent crashers: http://www.fogcreek.com/FogBugz/docs/40/Articles/GetCrashReportsFromUsersA.html [Are we ensuring that bugs reported through bug-buddy have a valid email address? Those bugs would be rather useless for the reporter without one, because we can't notify the reporter later when the bug is fixed.] Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dropping bug-buddy reports for old version of gnome automatically
El mié, 11-04-2007 a las 10:31 -0600, Elijah Newren escribió: In other words, yes, what you ask can be done and _is_ being done. This is totally awesome :) I didn't know our Bugzilla infrastructure was so nice. But to avoid false-positives, we require human intervention (and only a few people have the appropriate privileges) involving manual entry of data that should uniquely match the given bug. OK. What sort of data would you need? Or can it be inferred from (say) a bunch of duplicate bugs? If you have such a bug you'd like put on the auto-rejection list, contact the bugsquad with the information about the bug and a specifically tailored message you want bug-buddy to show the user. This is great to know. Is there a way we can notify all maintainers about this? [I don't seem to be getting bugmail for sabayon... I'll go poke the bugmasters] :) Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dropping bug-buddy reports for old version of gnome automatically
On 4/11/07, Federico Mena Quintero [EMAIL PROTECTED] wrote: This is totally awesome :) I didn't know our Bugzilla infrastructure was so nice. Olav rocks. :-) But to avoid false-positives, we require human intervention (and only a few people have the appropriate privileges) involving manual entry of data that should uniquely match the given bug. OK. What sort of data would you need? Or can it be inferred from (say) a bunch of duplicate bugs? edittraces.cgi currently asks for 1) Product 2) Product version (can be blank, makes comparison test ignore this field) 3) GNOME version (can be blank; bug-buddy can't always detect GNOME version) 4) Complete stack trace 5) Reason (explanatory text sent to user when report is rejected) I didn't develop it and haven't yet used it myself; further questions are probably best directed to Olav or perhaps Andre or Karsten. If you have such a bug you'd like put on the auto-rejection list, contact the bugsquad with the information about the bug and a specifically tailored message you want bug-buddy to show the user. This is great to know. Is there a way we can notify all maintainers about this? Good question. I have no idea. Cheers, Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dropping bug-buddy reports for old version of gnome automatically
On 4/9/07, Federico Mena Quintero [EMAIL PROTECTED] wrote: El sáb, 07-04-2007 a las 16:39 +0100, Richard Hughes escribió: I'm sure other maintainers must be getting as demoralised as myself when dealing with so many duplicates of a fixed bug. Still, this can be an indication that your fixes are not reaching the affected people. Maybe you need to explicitly poke the distro(s) in question and tell them, this fixes a bug that 5000 of your users have reported; can you release a new package through your update channels?. Which won't necessarily reach them either, as that assumes the users will all update their packages and there won't be new installations without automatic updates before usage. (Bug 94625 received duplicate filings for _years_ after RedHat pushed out updates to fix the problem. In fact, it received another one just last month.) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dropping bug-buddy reports for old version of gnome automatically
On 4/8/07, Olav Vitters [EMAIL PROTECTED] wrote: On Sun, Apr 08, 2007 at 04:01:14PM +0200, Josselin Mouette wrote: Given the length of Redhat, SuSE and Debian release cycles, this will just make bug-buddy useless for many stable users. Ideally you could Honestly, I think that =2.14 bugreports are useless. Dropping =2.16 feels way too soon, however, I also want to keep Bugzilla usable (the incoming bug rate is way too high). Further, as soon as a GNOME is released as stable, the old one is forgotten about. Note: we don't receive many =2.14 bug-buddy bugreports (mostly due to using sendmail to send it). And it was going to be ceased with the release of 2.20 anyway. [Responding a bit slowly...] I'm all in favor of dropping = 2.14 bugreports, mainly because of the sendmail and yet-another-bugzilla-parsing-script issue. So +1 from me on that. I wouldn't want to see 2.16 bugreports dropped, especially not this early. It'd be really cool if we could make this kind of thing product-specific and have it be a maintainer choice on which bugreports are considered old enough to be automatically dropped in the future. Just my $0.02 (even though you probably already knew my answers) since I didn't see too many other people responding to this specific issue... Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dropping bug-buddy reports for old version of gnome automatically
On Sun, Apr 08, 2007 at 04:19:12PM +0200, Olav Vitters wrote: On Sun, Apr 08, 2007 at 04:01:14PM +0200, Josselin Mouette wrote: Le dimanche 08 avril 2007 à 14:20 +0200, Olav Vitters a écrit : On Sat, Apr 07, 2007 at 05:13:04PM +0200, Paolo Borelli wrote: As far as I am concerned I'd like to drop any reports from 2.16 and below, but I see how that may be a little to aggressive. What about dropping reports from 2.14 and below? If there are no objections, I'll start with dropping bug-buddy reports created with bug-buddy =2.14 (meaning: GNOME versions before =2.14) starting Mon 9 April. I'll probably setup an [EMAIL PROTECTED] auto responder which tells them to upgrade their GNOME to the latest version available. Given the length of Redhat, SuSE and Debian release cycles, this will just make bug-buddy useless for many stable users. Ideally you could Honestly, I think that =2.14 bugreports are useless. Dropping =2.16 feels way too soon, however, I also want to keep Bugzilla usable (the incoming bug rate is way too high). Further, as soon as a GNOME is released as stable, the old one is forgotten about. Note: we don't receive many =2.14 bug-buddy bugreports (mostly due to using sendmail to send it). And it was going to be ceased with the release of 2.20 anyway. Adding some numbers (I mentioned this in http://blogs.gnome.org/view/ovitters/2007/04/08/0): Based on server stats over the last week, we: * Created 23 GNOME =2.14 bug-buddy reports. Update: To clarify, the =2.14 bug-buddy programs updated themselves 9603 times (it does that when you start it and it wasn't updated for at least 1 day, plus the server config changed). Obviously that method of reporting bugs is so broken that killing it wouldn't have a big impact. * Received 5513 XML-RPC GNOME 2.15 + 2.16 bug-buddy reports. I assume 60% are auto-rejected (received!=created). * Received 475 XML-RPC bug-buddy report for other GNOME versions (sometimes the bug-buddy version couldn't be determined). * Created 2405 bugreports in total (over the last 7 days instead of last week). I hope above clarifies why I will kill =2.14, but want further input on the other versions. Note: The blog also has a comment (finally found why my comments weren't working!:) about very hard to understand XML error messages. Someone seen that as well? -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dropping bug-buddy reports for old version of gnome automatically
El sáb, 07-04-2007 a las 16:39 +0100, Richard Hughes escribió: I'm sure other maintainers must be getting as demoralised as myself when dealing with so many duplicates of a fixed bug. Still, this can be an indication that your fixes are not reaching the affected people. Maybe you need to explicitly poke the distro(s) in question and tell them, this fixes a bug that 5000 of your users have reported; can you release a new package through your update channels?. Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dropping bug-buddy reports for old version of gnome automatically
On Sat, Apr 07, 2007 at 05:13:04PM +0200, Paolo Borelli wrote: As far as I am concerned I'd like to drop any reports from 2.16 and below, but I see how that may be a little to aggressive. What about dropping reports from 2.14 and below? If there are no objections, I'll start with dropping bug-buddy reports created with bug-buddy =2.14 (meaning: GNOME versions before =2.14) starting Mon 9 April. I'll probably setup an [EMAIL PROTECTED] auto responder which tells them to upgrade their GNOME to the latest version available. For dropping =2.16 I want to wait a bit longer for objections. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dropping bug-buddy reports for old version of gnome automatically
Le dimanche 08 avril 2007 à 14:20 +0200, Olav Vitters a écrit : On Sat, Apr 07, 2007 at 05:13:04PM +0200, Paolo Borelli wrote: As far as I am concerned I'd like to drop any reports from 2.16 and below, but I see how that may be a little to aggressive. What about dropping reports from 2.14 and below? If there are no objections, I'll start with dropping bug-buddy reports created with bug-buddy =2.14 (meaning: GNOME versions before =2.14) starting Mon 9 April. I'll probably setup an [EMAIL PROTECTED] auto responder which tells them to upgrade their GNOME to the latest version available. Given the length of Redhat, SuSE and Debian release cycles, this will just make bug-buddy useless for many stable users. Ideally you could detect their distribution and tell them to report the issue directly in the distribution's tracking system. BTW, I'm working on a non-GNOME-dependent replacement to bug-buddy, which will report crashes in the Debian BTS instead. In the future, it should save you the Debian-related bugs (if we can manage the number of bugs...) -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dropping bug-buddy reports for old version of gnome automatically
On Sun, Apr 08, 2007 at 04:01:14PM +0200, Josselin Mouette wrote: Le dimanche 08 avril 2007 à 14:20 +0200, Olav Vitters a écrit : On Sat, Apr 07, 2007 at 05:13:04PM +0200, Paolo Borelli wrote: As far as I am concerned I'd like to drop any reports from 2.16 and below, but I see how that may be a little to aggressive. What about dropping reports from 2.14 and below? If there are no objections, I'll start with dropping bug-buddy reports created with bug-buddy =2.14 (meaning: GNOME versions before =2.14) starting Mon 9 April. I'll probably setup an [EMAIL PROTECTED] auto responder which tells them to upgrade their GNOME to the latest version available. Given the length of Redhat, SuSE and Debian release cycles, this will just make bug-buddy useless for many stable users. Ideally you could Honestly, I think that =2.14 bugreports are useless. Dropping =2.16 feels way too soon, however, I also want to keep Bugzilla usable (the incoming bug rate is way too high). Further, as soon as a GNOME is released as stable, the old one is forgotten about. Note: we don't receive many =2.14 bug-buddy bugreports (mostly due to using sendmail to send it). And it was going to be ceased with the release of 2.20 anyway. detect their distribution and tell them to report the issue directly in the distribution's tracking system. You mean in the auto responder right? I can add a comment that their should report it to their distribution. I assume people will know what distribution they use. BTW, I'm working on a non-GNOME-dependent replacement to bug-buddy, which will report crashes in the Debian BTS instead. In the future, it should save you the Debian-related bugs (if we can manage the number of bugs...) Suggest to work together on this. Ubuntu has something which already works (apport). Fedora wants something similar, etc for other distributions. Oh, and a warning: without having some system in place to detect duplicates automatically, you will be overwhelmed. I do wonder about the 'non-GNOME-dependent' comment though? Does it mean 'GTK+' / 'Qt' or just like apport that it works for every app (kernel integrated)? Ideally the major distributions would have something like apport, where at least most of the code is shared between the distributions. This should work for every application in the distribution. It would still need to handle the jhbuild / GARNOME case though. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dropping bug-buddy reports for old version of gnome automatically
On Sun, 2007-04-08 at 16:01 +0200, Josselin Mouette wrote: BTW, I'm working on a non-GNOME-dependent replacement to bug-buddy, which will report crashes in the Debian BTS instead. In the future, it should save you the Debian-related bugs (if we can manage the number of bugs...) What's wrong with Apport? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dropping bug-buddy reports for old version of gnome automatically
Le dimanche 08 avril 2007 à 16:19 +0200, Olav Vitters a écrit : Oh, and a warning: without having some system in place to detect duplicates automatically, you will be overwhelmed. Definitely. This, and the fact such reports are mostly useless without debugging symbols available. I have some ideas on how to handle the first issue, but it's quite entangled with the BTS and I want to see the system in action before. For the debugging symbols issue, we have some ideas about their automated installation, but it remains to be done. Reports on stable releases are another issue, and I'm reluctant to ship such automated tools (including bug-buddy) in stable releases unless we find ways to identify bugs that we'll really want to fix (like security issues). I do wonder about the 'non-GNOME-dependent' comment though? Does it mean 'GTK+' / 'Qt' or just like apport that it works for every app (kernel integrated)? I chose the LD_PRELOAD way, so that it remains entirely optional and can run with any kernel. Ideally the major distributions would have something like apport, where at least most of the code is shared between the distributions. This should work for every application in the distribution. It turns out that the shared code would be very small. The LD_PRELOAD library (that's mostly stolen from libgnomeui) is a tiny piece of code, and I suspect the kernel patch is likewise. The more important part of the code is the integration with the distribution's own packaging system and bug tracker. It would still need to handle the jhbuild / GARNOME case though. Currently Debreaper doesn't override applications setting their own signal handlers, but for GNOME it overrides gnome_segv2. As GARNOME installations have their own gnome_segv2, this should bring bug-buddy as expected. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dropping bug-buddy reports for old version of gnome automatically
On 07/04/07 16:13, Paolo Borelli wrote: Hi, [...] Personally I am not able anymore to handle my bugmail anymore and even useful bugreports get lost in the noise. I usually mark any Crash: ... bugmail as read without even looking at it nowadays. As a first step, what do you think of just dropping silently at least crash reports from older versions of gnome? All bugs coming from there are either already fixed or will be reported anyway if still present in newer versions. Is there any way to do it non-silently? There needs to be something to at least inform the user they have an ancient version of GNOME and should consider upgrading. Regards, Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dropping bug-buddy reports for old version of gnome automatically
On Sat, 2007-04-07 at 17:13 +0200, Paolo Borelli wrote: Personally I am not able anymore to handle my bugmail anymore and even useful bugreports get lost in the noise. Tell me about it. gnome-power-manager 2.18.0 had a bug where it would segfault when you locked the screen if HAL was not running. 2.18.1 fixed the bug, but that still means I get about 5-10 duplicate bugzillas a day. The guys triaging this stuff have been great, but it's still more and more emails for me. I'm really thinking the auto-submit thing to bugzilla should have more text like: 1. You do not have debuginfo packages installed, the trace may not be useful to the developer. 2. [click here to check to see if the crash was already reported] 3. You are running an old version. This crash may be fixed in newer versions of the product. Point 1 assumes we can tell what useful debuginfo packages should be installed for each package. Point 2 assumes we can automatically check for similar stacktraces. Point 3 assumes the bugbuddy can query the servers for the latest version. I'm sure other maintainers must be getting as demoralised as myself when dealing with so many duplicates of a fixed bug. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dropping bug-buddy reports for old version of gnome automatically
Richard Hughes wrote: On Sat, 2007-04-07 at 17:13 +0200, Paolo Borelli wrote: Personally I am not able anymore to handle my bugmail anymore and even useful bugreports get lost in the noise. Tell me about it. gnome-power-manager 2.18.0 had a bug where it would segfault when you locked the screen if HAL was not running. 2.18.1 fixed the bug, but that still means I get about 5-10 duplicate bugzillas a day. The guys triaging this stuff have been great, but it's still more and more emails for me. We can auto reject specific stack traces [1] for this very reason. Get in touch with your local bugsquadder/bugmaster for more information. I'm really thinking the auto-submit thing to bugzilla should have more text like: 1. You do not have debuginfo packages installed, the trace may not be useful to the developer. This happens [2] if we manage to detect it.. Thanks, Andrew [1] http://blogs.gnome.org/view/ovitters/2006/11/12/0 [2] http://blogs.gnome.org/view/ovitters/2007/01/06/0 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dropping bug-buddy reports for old version of gnome automatically
[Just noticed that Andrew made most of my email obsolete before I finished. Maybe you'll see something useful, though, so I'll still send it.] On 4/7/07, Richard Hughes [EMAIL PROTECTED] wrote: On Sat, 2007-04-07 at 17:13 +0200, Paolo Borelli wrote: Personally I am not able anymore to handle my bugmail anymore and even useful bugreports get lost in the noise. Tell me about it. gnome-power-manager 2.18.0 had a bug where it would segfault when you locked the screen if HAL was not running. 2.18.1 fixed the bug, but that still means I get about 5-10 duplicate bugzillas a day. The guys triaging this stuff have been great, but it's still more and more emails for me. You can have such bugs automatically rejected with a specialized notice (Thanks for the bug report, but this issue has been fixed in gnome-power-manager 2.18.1; please update your software.) One example is bug 352592 which has had over 3000 duplicates automatically rejected[1]. See http://live.gnome.org/Bugsquad/AutoReject for more details. I believe Olav set the system up so that only a few users (maybe 3 or 4?) had permissions to add bugs to the auto-reject list, so you'll probably need to email the bugsquad to ask someone to do it for you. I'm really thinking the auto-submit thing to bugzilla should have more text like: 1. You do not have debuginfo packages installed, the trace may not be useful to the developer. http://live.gnome.org/ImprovingDebugging 2. [click here to check to see if the crash was already reported] We have no fail proof method for determining if two bugs are indeed a duplicate. Having that would be great, but we simply don't have it. Help welcome (Olav may already be working on it, so ask him first instead of starting from scratch.) 3. You are running an old version. This crash may be fixed in newer versions of the product. Rejecting on age would need to be product-specific, as which versions to reject probably depends on the volume of email the product receives. We've asked maintainers if they wanted to have bugsquadders automatically close bugs if against versions that are too old and what too old meant for their product, so moving that logic into bugzilla itself seems like a reasonable enhancement. Default would be to not reject anything based on version, of course. Point 1 assumes we can tell what useful debuginfo packages should be installed for each package. Point 2 assumes we can automatically check for similar stacktraces. Point 3 assumes the bugbuddy can query the servers for the latest version. I'm sure other maintainers must be getting as demoralised as myself when dealing with so many duplicates of a fixed bug. [1] I suggest only doing this for fixed bugs, where further reports won't be helpful; otherwise, you miss out on potential extra details that future bug submitters might provide. Hope that helps, Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
