Re: Firefox bugs mass-closed.
On Mon, 01 Oct 2007, Juliusz Chroboczek wrote: > Since this particular bug is trivial to reproduce (ls > ~/.mozilla/firefox/), it would appear that the Firefox maintainers > are mass-closing bug reports without even checking what they are > about. Considering that the message which has been sent to you does not close the bug, nor does it do anything but request the submitter or those who have seen the bug to replicate it, it's perfectly reasonable. The bug in question was (at the time the message was sent out) assigned to a package which is no longer distributed in Debian. Furthmore, the bug in question is additionally marked wontfix; merely closing it after this time would also have been perfectly appropriate. Efforts like this to actively engage old reports and try to whittle them down to a series of reports which are still relevant is far superior to ignoring them entirely. If you would prefer that osmething more involved be done to the bugs, then feel free to jump in and help triage. I'm sure the iceweasel maintainers would appreciate assistance. Don Armstrong -- America was far better suited to be the World's Movie Star. The world's tequila-addled pro-league bowler. The world's acerbic bi-polar stand-up comedian. Anything but a somber and tedious nation of socially responsible centurions. -- Bruce Sterling, _Distraction_ p122 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox bugs mass-closed.
>> Since this particular bug is trivial to reproduce (ls >> ~/.mozilla/firefox/), it would appear that the Firefox maintainers >> are mass-closing bug reports without even checking what they are >> about. > Considering that the message which has been sent to you does not close > the bug, nor does it do anything but request the submitter or those > who have seen the bug to replicate it, it's perfectly reasonable. They are requiring me (the submitter) to take explicit action just to make sure that an easy to reproduce and perfectly current bug report is not closed. This is reasonable? > feel free to jump in and help triage. I am already actively helping with those projects for which I know the upstream code intimately. I don't expect to be required to actively participate in all of the Debian packaging efforts I submit bug reports against. Juliusz pgphdKqeM3QA9.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
On Mon, Oct 01, 2007 at 08:00:22PM +0200, Juliusz Chroboczek wrote: > While I realise that it is sometimes difficult to deal with hundreds > of old bug reports, there are other ways of dealing with this kind of > issue, such as tagging old bugs when they lack submitter input, or at > least going through old reports to check whether the information they > contain is useful. > I certainly did not expect this kind of approach from Debian. > > I would like to recommend > > http://www.jwz.org/doc/cadt.html If you feel more work should be done walking through old bugs, the best way is to work with the team in question. Free software is all about people scratching their own itches. If you can't find the time to triage old bugs, it's kinda hard to convince a volunteer to do it for you. Cheers, Riku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox bugs mass-closed.
> If you can't find the time to triage old bugs, it's kinda hard to > convince a volunteer to do it for you. I am not quite sure what you mean. Are you saying that in order to submit a bug against a Debian package without it being summarily closed, I need to be a member of the development team for that very package? (And yes, I am actively helping with triage of Debian bugs, and have been doing so since the late 1990s. But that's pretty much irrelevant for this discussion.) Juliusz pgpSfnUwFFm9y.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
On Mon, Oct 01, 2007 at 07:08:19PM +, Juliusz Chroboczek wrote: > >> Since this particular bug is trivial to reproduce (ls > >> ~/.mozilla/firefox/), it would appear that the Firefox maintainers > >> are mass-closing bug reports without even checking what they are > >> about. > > > Considering that the message which has been sent to you does not close > > the bug, nor does it do anything but request the submitter or those > > who have seen the bug to replicate it, it's perfectly reasonable. > > They are requiring me (the submitter) to take explicit action just to > make sure that an easy to reproduce and perfectly current bug report > is not closed. This is reasonable? > > > feel free to jump in and help triage. > > I am already actively helping with those projects for which I know the > upstream code intimately. I don't expect to be required to actively > participate in all of the Debian packaging efforts I submit bug reports > against. that's sad for you. When you report a bug, you can thing it's a fire and forget thing. But then think that teams that the KDE one, the firefox one, the Gnome one have thousands of bugs to deal with. And not later than today on IRC we discussed that, and _I_ find perfectly sensible that bugs that are opened for say 1 year, get a "ping" mail to the submitter to say (basically): heya this bug is opened for [X months], and since last version ([VER]) the maintainer uploaded [X] new upstream releases, and maybe your bug was fixed. If you can check it, you would save us a lot of work. If the bug is closed, please send a mail to [EMAIL PROTECTED] containing: fixed n [CURRENT VERSION] thanks or if it is still reproducible: found n [CURRENT VERSION] thanks Thanks in advance. If you _just_ do that, we could often save a _LOT_ of time to maintainers, as it makes things distributed, hence unload maintainers. We could of course skip +wontfix bugs that are likely to never been fixed. But I really believe it to be _excellent_ practice. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpQV8NI3nM1H.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
On Mon, 01 Oct 2007 20:00:22 +0200, Juliusz Chroboczek <[EMAIL PROTECTED]> wrote: >I have just received the attached mail. The relevant bit is at the end: > >> As this bug is quite old, I intend to close it if you don't update >> your bug report in the next 6 weeks. > >Since this particular bug is trivial to reproduce (ls ~/.mozilla/firefox/), >it would appear that the Firefox maintainers are mass-closing bug >reports without even checking what they are about. This has become quite common for larger packages. The KDE and WNPP people do the same, which I - as a user - consider quite annoying and disrespectful, but I - as a maintainer - can understand, on the other hand. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Firefox bugs mass-closed.
Pierre Habouzit wrote: > later than today on IRC we discussed that, and _I_ find perfectly > sensible that bugs that are opened for say 1 year, get a "ping" mail to > the submitter to say (basically): But not if the bug is a security bug, and not if the bug is forwarded to an upstream BTS, where it's still open and being discussed. Both were the case for #320539, which I just received a ping for. I've now gotten a total of 2 pings for #276576, which is fairly easily reproducible. (And quite annoyingly old for such an apparently simple bug.) So I can see how this particular mass-ping would piss people off.. -- see shy jo signature.asc Description: Digital signature
Re: Firefox bugs mass-closed.
On Mon, Oct 01, 2007 at 07:43:37PM +, Joey Hess wrote: > Pierre Habouzit wrote: > > later than today on IRC we discussed that, and _I_ find perfectly > > sensible that bugs that are opened for say 1 year, get a "ping" mail to > > the submitter to say (basically): > > But not if the bug is a security bug, and not if the bug is forwarded to > an upstream BTS, where it's still open and being discussed. Both were the > case for #320539, which I just received a ping for. > > I've now gotten a total of 2 pings for #276576, which is fairly easily > reproducible. (And quite annoyingly old for such an apparently simple > bug.) > > So I can see how this particular mass-ping would piss people off.. I'm not specifically discussing _this_ mass ping, but mass pings as a general issue, because I believe it can help. There is (especially in huge packages with a huge user base) numerous bugs the submitter did not really cared about, and it's a pain to have answers more than a week later. Now that the BTS has versionning, one can use the last version with the bug marked as "found" to know if the ping is necessary or not. If it's a BTS feature (and not done by the maintainer themselves) that would be, say, 2 mails a year (if those are triggered every 6 months without activity on the bug), IFF there has been a new upstream (aka debian revision uploads assume that if the bug isn't closed the bug is still here and the submitter won't get pinged). It seems sane to me, and will help big teams a lot. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpOGDt3y63EX.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
Pierre Habouzit wrote: > Now that the BTS has versionning, one can use the last version with > the bug marked as "found" to know if the ping is necessary or not. If > it's a BTS feature (and not done by the maintainer themselves) that > would be, say, 2 mails a year (if those are triggered every 6 months > without activity on the bug), IFF there has been a new upstream (aka > debian revision uploads assume that if the bug isn't closed the bug is > still here and the submitter won't get pinged). I have 524 open bug reports that I filed in the Debian BTS. What percentage of these are you suggesting I be pinged for on a yearly basis? Doesn't this tend to send the message that a bug submitter's time is less valuable than the package maintainer's time? Is this really a message we want to send to exactly the people who tend to file lots of bugs? -- see shy jo signature.asc Description: Digital signature
Re: Firefox bugs mass-closed.
On Mon, Oct 01, 2007 at 08:36:51PM +, Joey Hess wrote: > Pierre Habouzit wrote: > > Now that the BTS has versionning, one can use the last version with > > the bug marked as "found" to know if the ping is necessary or not. If > > it's a BTS feature (and not done by the maintainer themselves) that > > would be, say, 2 mails a year (if those are triggered every 6 months > > without activity on the bug), IFF there has been a new upstream (aka > > debian revision uploads assume that if the bug isn't closed the bug is > > still here and the submitter won't get pinged). > > I have 524 open bug reports that I filed in the Debian BTS. What > percentage of these are you suggesting I be pinged for on a yearly > basis? Doesn't this tend to send the message that a bug submitter's time > is less valuable than the package maintainer's time? Is this really a > message we want to send to exactly the people who tend to file lots of > bugs? How many are not alive (meaning that nothing changed from the maintainer or submitter -aka you- side ? in 6 months ?), and how many are on packages that have a new release since ? And no the message is that for most of the bug submitters (one should get some stats to be sure, but I would be surprised that DD and jidanni take aside, most of the submitters have less than 10 bugs that match such criteria) have few bugs to deal with on their end. It works in a distributed way. In a team with thousands of bug, the maintainer is definitely the single point of failure. So if additionally to the bugs he already watch specifically, he can get say some dozens closed thanks to that, or some dozens which get marked as 'found in the latest upstream' release again, I see that as a win/win scenario. Also node that many bugs are sometimes hard to reproduce, because you need a very specific environment that the maintainer not always have (e.g. the issue I have is that as a glibc maintainer, I've no large enough and used pam-ldap or NIS setups, and we have some bugs that rot because I don't have either the time or the resource to test them properly). Asking *kindly* some help from the submiter, once or twice a day, is not an insult. And if you don't feel like helping, you can discard these one or two mails away. And hopefully, less than a dozen submitters will fell cranky about it. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpGqqQD8AGzu.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
On Mon, 01 Oct 2007, Joey Hess wrote: > I have 524 open bug reports that I filed in the Debian BTS. What > percentage of these are you suggesting I be pinged for on a yearly > basis? Doesn't this tend to send the message that a bug submitter's > time is less valuable than the package maintainer's time? Is this > really a message we want to send to exactly the people who tend to > file lots of bugs? Pinging bugs is definetly not optimal, but if the alternative is ignoring them entirely, or being unable to concentrate on the bugs that actually exist because of older bugs which have been neglected, it's certainly better. With all of that said though, maintainers (and everyone else who wants to help with bug triaging of large packages) would be best off by starting with bugs which haven't received any love in a long period of time: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=debbugs;ordering=age;repeatmerged=0; or similar will help you start with those bugs. Don Armstrong -- There are two types of people in this world, good and bad. The good sleep better, but the bad seem to enjoy the waking hours much more. -- Woody Allen http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox bugs mass-closed.
On Mon, Oct 01, 2007 at 08:57:07PM +, Pierre Habouzit wrote: > properly). Asking *kindly* some help from the submiter, once or twice a > day, is not an insult. And if you don't feel like helping, you can ^^^ eeew I obviously meant year. And we also could not ping bugs with severity < normal either, and find other limiting factors to make this beneficial to the overall Debian quality, without putting a tremendous pressure on the submitters. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpeXZJ5W0cPx.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
> Also node that many bugs are sometimes hard to reproduce, because you > need a very specific environment that the maintainer not always have > (e.g. the issue I have is that as a glibc maintainer, I've no large > enough and used pam-ldap or NIS setups, and we have some bugs that rot > because I don't have either the time or the resource to test them > properly). I have no problem with the maintainer (a human being) asking me to do something sensible about my bug report, such as confirming that the bug still happens with the version in experimental, testing on a setup he doesn't have access to, producing a backtrace, running random commands on my system (as long as I understand what they do) etc. What Joey and I are specifically complaining about are three bugs that we have described in enough detail and that are trivial to reproduce. The maintainer did not send us personal mail asking for help; he sent us an automated mass mailing threatening to discard our perfectly valid reports unless we take some arbitrary action. This is clearly not the case that you are describing. Juliusz pgpAklwmaNBm6.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
On Mon, Oct 01, 2007 at 09:34:56PM +, Juliusz Chroboczek wrote: > What Joey and I are specifically complaining about are three bugs that > we have described in enough detail and that are trivial to reproduce. > The maintainer did not send us personal mail asking for help; he sent > us an automated mass mailing threatening to discard our perfectly > valid reports unless we take some arbitrary action. > > This is clearly not the case that you are describing. I'm trying to discuss a sensible default pinging mechanism for bugs that matters the most. And the fact that the bug is trivial to reproduce is irrelevant: when it's one bug among 1000 others, you don't have the time to check if this particular one is fixed or not. And yes, 1-3k bugs is the amount of bug a team like: X, KDE, Gnome, firefox, … has to deal with. Don't ask them to do more than what is humanly doable please. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpUJomP0HgxN.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
Pierre Habouzit <[EMAIL PROTECTED]> writes: > On Mon, Oct 01, 2007 at 08:57:07PM +, Pierre Habouzit wrote: > > Asking *kindly* some help from the submiter, once or twice a > > [year], is not an insult. The insult isn't the request for help. The insult is the implication that if there's no response, the bug will be summarily closed with no attempt made to see if the problem reported is fixed. -- \ "There is more to life than increasing its speed." -- Mahatma | `\Gandhi | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox bugs mass-closed.
On Mon, Oct 01, 2007 at 10:02:25PM +, Ben Finney wrote: > Pierre Habouzit <[EMAIL PROTECTED]> writes: > > > On Mon, Oct 01, 2007 at 08:57:07PM +, Pierre Habouzit wrote: > > > Asking *kindly* some help from the submiter, once or twice a > > > [year], is not an insult. > > The insult isn't the request for help. The insult is the implication > that if there's no response, the bug will be summarily closed with no > attempt made to see if the problem reported is fixed. FWIW I don't think a ping should threaten to close the bug. That is wrong. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpDE2sMl3Mhq.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
> The insult isn't the request for help. The insult is the implication > that if there's no response, the bug will be summarily closed with no > attempt made to see if the problem reported is fixed. Very well put. That's exactly the bit that got me annoyed. Juliusz pgp1Cd4Ibr5pe.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
On Mon, Oct 01, 2007 at 10:10:35PM +0300, Riku Voipio wrote: > On Mon, Oct 01, 2007 at 08:00:22PM +0200, Juliusz Chroboczek wrote: > > While I realise that it is sometimes difficult to deal with hundreds > > of old bug reports, there are other ways of dealing with this kind of > > issue, such as tagging old bugs when they lack submitter input, or at > > least going through old reports to check whether the information they > > contain is useful. > > > I certainly did not expect this kind of approach from Debian. > > > > I would like to recommend > > > > http://www.jwz.org/doc/cadt.html > > If you feel more work should be done walking through old bugs, the best > way is to work with the team in question. Free software is all about > people scratching their own itches. If you can't find the time to triage > old bugs, it's kinda hard to convince a volunteer to do it for you. FWIW, it's what *is* happening. Lior Kaplan is not part of the Mozilla team, and offered to help for bug triaging, which he is just doing right now. So yes, as not being very familiar with the packages and the existing bugs, he may be pinging bugs not worth pinging, but hey, can you blame him for trying to help ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox bugs mass-closed.
Quoting Pierre Habouzit ([EMAIL PROTECTED]): > FWIW I don't think a ping should threaten to close the bug. That is > wrong. Threaten, no. Suggest that it could be closed, yes. I personnally assume the concept of being pretty "aggressive" wrt bugs in packages that have a non manageable amount of bugs (above a few dozens per package maintainer is my own definition of manageable). In such situations, it becomes completely impossible to focus on issues that may deserve attention, for instance identifying issues that deserve to be reported upstream. So, well, despite all arguments developed by Joey in this thread, I still think that mass pings can really help maintainers in their work, particularly when someone takes over a package that has been neglected for some time. And, well, this is IIRC something we decided in a very recent D-I meeting for all old installation reports, suggesting to reproduce possible issues with the Etch installer, as we know we will never be able to identify reported issues, nor even identifiy what bugs report issues. So, in short, I would leave maintainers with the credit that they will conduct such actions only in cases they needed and useful *and* with the appropriate care , just like any mass action. signature.asc Description: Digital signature
Re: Firefox bugs mass-closed.
Quoting Juliusz Chroboczek ([EMAIL PROTECTED]): > What Joey and I are specifically complaining about are three bugs that > we have described in enough detail and that are trivial to reproduce. > The maintainer did not send us personal mail asking for help; he sent > us an automated mass mailing threatening to discard our perfectly > valid reports unless we take some arbitrary action. Have you considered the fact that this action may take place after the package was neglected for some time, so the person asking you for confirmation is not the person who received the initial bug report? I have no idea whether this is true for firefox, but that is a pretty common situation: one of the first tasks of someone taking a package over is to try digging in old bugs and triage them. So, well, during the time we're having this discussion, you could probably have confirmed all such bugs already by just answering "as I already wrote in the bug report, this is a trivial to reproduce bug and it is still there". signature.asc Description: Digital signature
Re: Firefox bugs mass-closed.
Hi Pierre! You wrote: > and _I_ find perfectly sensible that bugs that are opened for say 1 > year, get a "ping" mail to the submitter to say (basically): > > heya this bug is opened for [X months], and since last version > ([VER]) the maintainer uploaded [X] new upstream releases, and maybe > your bug was fixed. If you can check it, you would save us a lot of > work. If the bug is closed, please send a mail to > [EMAIL PROTECTED] containing: Indeed. But the tone of the messge you are proposing here sounds much different than the one that was actually sent in this case. At least to me (a non-native speaker), the above message seems much more friendly than the one that was sent in the firefox case. I think that's actually pretty important for messages like these: let the use know that their efforts are very much appreciated and explain why it's (nearly) impossible to handle all the bugs manually. Best regards, Bas. -- Kind regards, ++ | Bas Zoetekouw | GPG key: 0644fab7 | || Fingerprint: c1f5 f24c d514 3fec 8bf6 | | [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 | ++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox bugs mass-closed.
On 01/10/07 at 16:36 -0400, Joey Hess wrote: > Pierre Habouzit wrote: > > Now that the BTS has versionning, one can use the last version with > > the bug marked as "found" to know if the ping is necessary or not. If > > it's a BTS feature (and not done by the maintainer themselves) that > > would be, say, 2 mails a year (if those are triggered every 6 months > > without activity on the bug), IFF there has been a new upstream (aka > > debian revision uploads assume that if the bug isn't closed the bug is > > still here and the submitter won't get pinged). > > I have 524 open bug reports that I filed in the Debian BTS. What > percentage of these are you suggesting I be pinged for on a yearly > basis? Doesn't this tend to send the message that a bug submitter's time > is less valuable than the package maintainer's time? Isn't this the case, that in some ways, the submitter's time is less valuable than the package maintainer's time? Seriously, if we had the bandwidth to deal with all open bugs, of course, it would be totally wrong to mass-ping bug submitters. But it's not the case. For example, in #412176, you said: Thanks for the patches. I haven't had a chance to look them over in detail, and there are some other also uncommitted patches (#412622) that touch the same part of the code, so it might be a while until I get a time slice big enough to sort that out. This was in february, and nothing happened since then. So, clearly, there's a bandwidth problem. How do we deal with it? We could decide to mass-close all bugs marked as moreinfo or unreproducible with no action for more than two months. This was done in Ubuntu a few weeks ago (see [0] and following emails). But it's clearly not something we want to do in Debian. So we have to find a good compromise, and Lior Kaplan's mass-pings seem to be a good compromise to me. Of course, it's not really nice towards submitters, so we could have some project-wide directives on how to deal with those mass-pings, to make them more tolerable. Things such as: - start with the higher-severity bugs first - start by only pinging bugs found in a version < version in etch - include a paragraph explaining why we are doing that - leave a reasonable period for submitters to comment (2 months seems enough) - also ping people who confirmed/could reproduce the bug This adds complexity, but with the SOAP interface to the BTS, it's easy to write small scripts to partially automate this. Also, while *threatening* to close the bug is not really appropriate, it's better not to lie to the submitters, and tell them that we are going to close the bugs if they don't answer. Keeping such bugs opened is a non-sense anyway. [0] https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-September/001737.html -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
Re: Firefox bugs mass-closed.
On Monday 1 October 2007 22:36, Joey Hess wrote: > Doesn't this tend to send the message that a bug submitter's time > is less valuable than the package maintainer's time? I don't think it does. Their time may be of equivalent value, but the submitter has a higher probability of being able to reproduce the bug in a shorter time than the maintainer. Since the submitter encountered the bug, he has the right setup, system and/or use case. So yes, upon triage it's in non-trivial cases probably better to ask the submitter to reproduce than the maintainer. I've sent such "ping" mails to very old bugs aswell, but only if I couldn't easily verify the bug in my own setup. That doesn't take a lot of time and doesn't bother those submitters whose bugs are obviously still valid. I'd advise the Mozilla maintainers to take this middle road. Thijs pgp5mO7gG3AdF.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
Le lundi 01 octobre 2007 à 20:00 +0200, Juliusz Chroboczek a écrit : > Since this particular bug is trivial to reproduce (ls ~/.mozilla/firefox/), > it would appear that the Firefox maintainers are mass-closing bug > reports without even checking what they are about. And that is a good thing. If the submitter doesn't care of the bug enough to reply in the next six weeks, there is no reason to let the bug rot. > While I realise that it is sometimes difficult to deal with hundreds > of old bug reports, there are other ways of dealing with this kind of > issue, such as tagging old bugs when they lack submitter input, or at > least going through old reports to check whether the information they > contain is useful. Simply tagging bug reports is going, in the end, to have a useless BTS filled with thousands of bug reports that we don't know whether they still apply or not. I'm quite shocked by your reaction against someone who kindly volunteered to sort the huge load of Mozilla-related bugs, because it is a long and boring task that we are missing manpower for. > I certainly did not expect this kind of approach from Debian. > > I would like to recommend > > http://www.jwz.org/doc/cadt.html > > which succintly summarises the impression this kind of action gives. Quoting JWZ while talking of respecting people is not going to make your point. Cheers, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Firefox bugs mass-closed.
On Tue, Oct 02, 2007 at 08:02:25AM +1000, Ben Finney wrote: > Pierre Habouzit <[EMAIL PROTECTED]> writes: > > > On Mon, Oct 01, 2007 at 08:57:07PM +, Pierre Habouzit wrote: > > > Asking *kindly* some help from the submiter, once or twice a > > > [year], is not an insult. > > The insult isn't the request for help. The insult is the implication > that if there's no response, the bug will be summarily closed with no > attempt made to see if the problem reported is fixed. This is true. However, I find more insulting the kind of mails where it is obvious that the sender has not tried the reproduction instructions given in the bug logs. I tend to answer such mails in a very irate manner (but I do answer them, and I do also do what the sender should have done - that is, try the reproduction instructions). The insult is that the sender clearly has not even read the bug logs. The situation is of course different when the sender honestly *cannot* reproduce the bug (for example, because the instructions are confusing, or the sender does not have access to the hardware required). The bug report from which this thread started is similar (but not identical). The sender should have noticed that it was a wontfix bug (this doesn't even take reading the bug log!) and not sent any mails to it as the proposed cleanup procedure is clearly not applicable to wontfix stuff (either the bug should be closed immediately or it should not be closed even with no activity, depending on the maintainer's preference). I'm grateful that people volunteer to triage bugs, but volunteering is no defense for making mistakes. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: Firefox bugs mass-closed.
On Tue, Oct 02, 2007 at 07:11:56AM +0200, Christian Perrier wrote: > So, well, despite all arguments developed by Joey in this thread, I > still think that mass pings can really help maintainers in their work, > particularly when someone takes over a package that has been neglected > for some time. It might help to do something like use the confirmed tag to flag reports which can readily be reproduced or which otherwise don't need the submitter to confirm them. This would mean that those bugs could be excluded from mass pings and we'd therefore avoid irritating users by asking them to respond on issues which can readily be tested. This would need some discipline triaging incoming bugs but it'd be useful, I think. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Re: Firefox bugs mass-closed.
On Tue, Oct 02, 2007 at 02:48:07PM +, John Goerzen wrote: > On Mon October 1 2007 5:22:24 pm Pierre Habouzit wrote: > > On Mon, Oct 01, 2007 at 10:02:25PM +, Ben Finney wrote: > > > Pierre Habouzit <[EMAIL PROTECTED]> writes: > > > > On Mon, Oct 01, 2007 at 08:57:07PM +, Pierre Habouzit wrote: > > > > > Asking *kindly* some help from the submiter, once or twice a > > > > > [year], is not an insult. > > > > > > The insult isn't the request for help. The insult is the implication > > > that if there's no response, the bug will be summarily closed with no > > > attempt made to see if the problem reported is fixed. > > > > FWIW I don't think a ping should threaten to close the bug. That is > > wrong. > > I don't know about that. Hasn't it been a long-standing policy that bugs > that get no response from the submitter to questions can be closed? The important word in the sentence was: _threaten_. Maybe it's a native/non-native speaking issue, but in french "menacer" is quite a strong word. "Do answer or foad" is wrong. "please remember that if you aren't able to follow-up, it's likely that this bug will rot and eventually be closed because of this lack of follow-up". Or something smoother that a native-speaker can come up with :) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp9dj3QI5U7F.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
On Mon October 1 2007 5:22:24 pm Pierre Habouzit wrote: > On Mon, Oct 01, 2007 at 10:02:25PM +, Ben Finney wrote: > > Pierre Habouzit <[EMAIL PROTECTED]> writes: > > > On Mon, Oct 01, 2007 at 08:57:07PM +, Pierre Habouzit wrote: > > > > Asking *kindly* some help from the submiter, once or twice a > > > > [year], is not an insult. > > > > The insult isn't the request for help. The insult is the implication > > that if there's no response, the bug will be summarily closed with no > > attempt made to see if the problem reported is fixed. > > FWIW I don't think a ping should threaten to close the bug. That is > wrong. I don't know about that. Hasn't it been a long-standing policy that bugs that get no response from the submitter to questions can be closed? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox bugs mass-closed.
On Mon October 1 2007 4:50:10 pm Pierre Habouzit wrote: > On Mon, Oct 01, 2007 at 09:34:56PM +, Juliusz Chroboczek wrote: > > What Joey and I are specifically complaining about are three bugs that > > we have described in enough detail and that are trivial to reproduce. > > The maintainer did not send us personal mail asking for help; he sent > > us an automated mass mailing threatening to discard our perfectly > > valid reports unless we take some arbitrary action. > > > > This is clearly not the case that you are describing. > > I'm trying to discuss a sensible default pinging mechanism for bugs > that matters the most. And the fact that the bug is trivial to reproduce > is irrelevant: when it's one bug among 1000 others, you don't have the > time to check if this particular one is fixed or not. As a maintainer and a user, I have often wondered lately if the practice of tracking numerous upstream bugs in the Debian BTS is something that should be ended. We nominally do this out of convenience to our users. However, I have found response time from Debian maintainers for upstream bugs, on average, to be extremely bad, and that most never get forwarded to the upstream BTS. As a maintainer, I must admit to not always being prompt with upstream bugs myself. When I have an active upstream, it is annoying to act as a human proxy when the issue could be best handled through them directly anyway. I have received a number of pings lately similar to the one that sparked this thread. Some for bugs many years old that never received any attention whatsoever. All were upstream bugs. As a rule, I try to never report upstream bugs to the Debian BTS anymore because it is a blackhole in so many cases. Perhaps we should be providing tools to let users find the appropriate upstream BTS for upstream bugs, rather than burdening our maintainers with being a human proxy? I suspect we will provide better response for the users and a better BTS for maintainers. Of course, the question is how to determine what's an upstream bug. Perhaps we could still receive reports in our Debian BTS, but provide some automated tools to send them on to popular types of upstream BTSs, and then close the Debian report with a pointer to the upstream location? -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox bugs mass-closed.
On Tue, 2 Oct 2007 08:25:21 -0500 John Goerzen <[EMAIL PROTECTED]> wrote: > As a maintainer and a user, I have often wondered lately if the practice of > tracking numerous upstream bugs in the Debian BTS is something that should > be ended. We nominally do this out of convenience to our users. However, I > have found response time from Debian maintainers for upstream bugs, on > average, to be extremely bad, and that most never get forwarded to the > upstream BTS. When that is actually all that needs to be done, it is disappointing. There are automated systems that track forwarded bugs but the sheer number and variety of upstream bug tracking methods may be a problem. Are there upstream systems that cannot be tracked by our automated scripts? How many? As long as the "Forwarded to:" location is publicly accessible and contains sane data on the status of the bug, it should be possible to track most upstream systems. For my own upstream packages, I actually prefer to use the Debian BTS because the SourceForge Trackers are a PITA. (YMMV). So with my upstream packages, there *are* no upstream bugs! :-) > As a maintainer, I must admit to not always being prompt with > upstream bugs myself. When I have an active upstream, it is annoying to act > as a human proxy when the issue could be best handled through them directly > anyway. The problem, for me, is when each upstream has a radically different bug tracking system - particularly when each one requires yet-another-username-and-password, most do not accept direct email and many are incredibly long-winded. Why should it take FIVE pages (after login) just to get to the text entry box? It's easier once you've filed a few bugs but that just means that it is a job for the maintainer rather than each user. > I have received a number of pings lately similar to the one that sparked this > thread. Some for bugs many years old that never received any attention > whatsoever. All were upstream bugs. Forwarded? If the bug has been forwarded, it is up to the person writing the ping to skip those bugs (or maybe follow the link to the upstream). > As a rule, I try to never report upstream bugs to the Debian BTS anymore > because it is a blackhole in so many cases. Not reporting to the BTS can just mean that someone else (with less knowledge of the package and possibly less useful input) files a BTS bug anyway. At least having the bug in the BTS can reduce duplicates / provide a base bug into which to merge duplicates. > Perhaps we should be providing tools to let users find the appropriate > upstream BTS for upstream bugs, rather than burdening our maintainers with > being a human proxy? I suspect we will provide better response for the > users and a better BTS for maintainers. Users don't want to create whole new username-and-password pairs either. Debian should not expect Debian users to know how to use upstream bug systems. If the upstream system can accept reports from reportbug, fine (although I suspect most will not). > Of course, the question is how to determine what's an upstream bug. Perhaps > we could still receive reports in our Debian BTS, but provide some automated > tools to send them on to popular types of upstream BTSs, and then close the > Debian report with a pointer to the upstream location? I think it would be better to identify which upstreams use systems that cannot be tracked once forwarded and prompting maintainers to use the forwarded tag that already exists. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpiAQdkE16Jy.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
On Tue, Oct 02, 2007 at 09:47:40AM +, Mark Brown wrote: > On Tue, Oct 02, 2007 at 07:11:56AM +0200, Christian Perrier wrote: > > > So, well, despite all arguments developed by Joey in this thread, I > > still think that mass pings can really help maintainers in their work, > > particularly when someone takes over a package that has been neglected > > for some time. > > It might help to do something like use the confirmed tag to flag reports > which can readily be reproduced or which otherwise don't need the > submitter to confirm them. This would mean that those bugs could be > excluded from mass pings and we'd therefore avoid irritating users by > asking them to respond on issues which can readily be tested. This > would need some discipline triaging incoming bugs but it'd be useful, I > think. Confirmed is not versionned. The fact that it was confirmed at one point does not means that the bug is still here. In that regard, using "found" with the proper version is better, as it tracks versions, and can more efficientely prevent new pings when no new upstream was released. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpWNC8XPj8uG.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
* John Goerzen <[EMAIL PROTECTED]> [071002 20:47]:
> As a maintainer and a user, I have often wondered lately if the practice of
> tracking numerous upstream bugs in the Debian BTS is something that should
> be ended. We nominally do this out of convenience to our users. However, I
> have found response time from Debian maintainers for upstream bugs, on
> average, to be extremely bad, and that most never get forwarded to the
> upstream BTS. As a maintainer, I must admit to not always being prompt with
> upstream bugs myself. When I have an active upstream, it is annoying to act
> as a human proxy when the issue could be best handled through them directly
> anyway.
> [...]
> Perhaps we should be providing tools to let users find the appropriate
> upstream BTS for upstream bugs, rather than burdening our maintainers with
> being a human proxy? I suspect we will provide better response for the
> users and a better BTS for maintainers.
Sorry for being a bit sarcastic, but that sounds like next suggesting not
burdening maintainers with compiling packages and better tell users where to
get the packages and what to change to integrate them into their Debian
system.
It's true that the current system means some blackhole and for some
packages, but I fail to see a point in declaring failure the standard.
Especially for upstream bugs, a maintainer as proxy is the best thing
that can happen. The maintainer knows Debian and the packaging of the
software in question, so the maintainer can decide which problems are
due to local modifications and which look more like upstream bugs.
The maintainer also has another Debian machine, so is much more likely
to be able to reproduce the problem than an upstream that may not even
have any linux or glibc around. (And having upstreams ranting all the
time for getting bug reports by Debian users caused by some FHS or
policy integration are neigher helpful to us nor to our users).
There is a problem to get enough manpower, especially for some large
packages. But if there are too many bugs for Debian maintainers to handle,
how should upstream maintainers cope them all, without any filtering or
qualification before it?
If we want quality software, we need to idenfity the bugs and get them
fixed. We cannot limit ourself and our upstreams to just power-users
reporting bugs. People reporting bugs do us a favour, they invest time
to write a text readable by others. They help us to identify bugs and
problems we ourselves, or some of our users, might hit later, too.
Reporting a bug will seldom directly help the reporter, as till the
problem is understood, the problem is fixed, the fixes are releases and
finally hit the next stable, there is a long time most reporters will
not even still have the problem, or they know it and can work around it
easily. Still they report it.
When we as Debian maintainers cannot do our job (which we often cannot
do, at least for some packages), it is of course true that falling back
to something else, like asking submitters to verify if some bug is still
present or even to report something somewhere else, might be better than
failing to do anything. But I think this should not be the default.
And when it is done, some little words can really make a difference.
Some little "We are sorry, but we lack people looking after this
package. Thus you would help us a lot, if you could try to reproduce
your problem with the newest version..." makes everyone happier. Noone
expects you to be perfect and helping people is much easier done when
asked politely and when commanded.
Also things like (even just expressing intend to) close bugs without even
trying to reproduce them, just because they are old should be forwned
upon. That does not mean that they should not be done. But at least if
they are better than the alternative some little words can again make a
big difference. Some little words that you know it is not good, and some
words of excuse ("We lack people to go through all bugs. By closing old
bugs without follup up after ping, we have at least hope to be able to
look at newly reported bugs." or something like this.) Some little words
can really make a difference between giving people the (hopefully false)
impression of rewarding their altruism to report bugs by treat them as
beggars and asking them for further help for all of us and all of our
users.
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox bugs mass-closed.
Josselin Mouette wrote: > Le lundi 01 octobre 2007 à 20:00 +0200, Juliusz Chroboczek a écrit : > > Since this particular bug is trivial to reproduce (ls ~/.mozilla/firefox/), > > it would appear that the Firefox maintainers are mass-closing bug > > reports without even checking what they are about. > > And that is a good thing. If the submitter doesn't care of the bug > enough to reply in the next six weeks, there is no reason to let the bug > rot. That's a depressing statement, I hope that opinion about the value of bug reports is in the minority. We encourage people to not file duplicate bug reports, and check the BTS first. So I check the BTS, the bug is there, I don't file a new one (I do send a "me too"). 6 weeks later, the bug is closed because the submitter's email is bouncing and he's on vacation anyway. -- see shy jo signature.asc Description: Digital signature
Re: Firefox bugs mass-closed.
On Tue, Oct 02, 2007 at 01:25:21PM +, John Goerzen wrote: > Of course, the question is how to determine what's an upstream bug. Perhaps > we could still receive reports in our Debian BTS, but provide some automated > tools to send them on to popular types of upstream BTSs, and then close the > Debian report with a pointer to the upstream location? you mean using the forwarded state and bts-link ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpPzOBTnaS6J.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
On Tuesday 02 October 2007 2:09:40 pm Pierre Habouzit wrote: > On Tue, Oct 02, 2007 at 01:25:21PM +, John Goerzen wrote: > > Of course, the question is how to determine what's an upstream bug. > > Perhaps we could still receive reports in our Debian BTS, but provide > > some automated tools to send them on to popular types of upstream BTSs, > > and then close the Debian report with a pointer to the upstream > > location? > > you mean using the forwarded state and bts-link ? No, that is a lot of manual work. I mean something like: $ bug-forward 456789 bacula and have it Just Work. As it is, I have to track down accounts for the individual systems, often copy and paste info from multiple messages, tag the Debian bug, then perhaps relay info between the two bug tracking systems indefinately. A huge pain. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox bugs mass-closed.
On Tue, Oct 02, 2007 at 11:01:23PM +, John Goerzen wrote: > On Tuesday 02 October 2007 2:09:40 pm Pierre Habouzit wrote: > > On Tue, Oct 02, 2007 at 01:25:21PM +, John Goerzen wrote: > > > Of course, the question is how to determine what's an upstream bug. > > > Perhaps we could still receive reports in our Debian BTS, but provide > > > some automated tools to send them on to popular types of upstream BTSs, > > > and then close the Debian report with a pointer to the upstream > > > location? > > > > you mean using the forwarded state and bts-link ? > > No, that is a lot of manual work. A _lot_ ? It's just a matter of opening an upstream bug copy&pasting the debian bug report, then run bts forwared 123456 . The rest works by itself. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp3rsBCTZTXK.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
On Tuesday 02 October 2007 6:10:33 pm Pierre Habouzit wrote: > On Tue, Oct 02, 2007 at 11:01:23PM +, John Goerzen wrote: > > On Tuesday 02 October 2007 2:09:40 pm Pierre Habouzit wrote: > > > On Tue, Oct 02, 2007 at 01:25:21PM +, John Goerzen wrote: > > > > Of course, the question is how to determine what's an upstream bug. > > > > Perhaps we could still receive reports in our Debian BTS, but > > > > provide some automated tools to send them on to popular types of > > > > upstream BTSs, and then close the Debian report with a pointer to > > > > the upstream location? > > > > > > you mean using the forwarded state and bts-link ? > > > > No, that is a lot of manual work. > > A _lot_ ? It's just a matter of opening an upstream bug copy&pasting That involves looking up a username and password in some secure storage system for such, logging on to the particular BTS, navigating the web form, going to the Debian BTS to pull up the bug, copy and pasting each relevant message, creating an upstream bug, then marking the Debian bug forwarded, and copying & pasting later correspondence between Debian submitters and the upstream in some cases. That's easily 15 minutes per bug, which does not scale. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox bugs mass-closed.
On Tue, 02 Oct 2007, John Goerzen wrote: > That involves looking up a username and password in some secure > storage system for such, logging on to the particular BTS, > navigating the web form, going to the Debian BTS to pull up the bug, > copy and pasting each relevant message, creating an upstream bug, > then marking the Debian bug forwarded, and copying & pasting later > correspondence between Debian submitters and the upstream in some > cases. The main thing that needs to be done is filing the bug upstream and then connecting the two reports by setting forwarded appropriately. Filing a bug upstream takes however much time it takes regardless of whether the bug is also filed in the Debian package or not. [I've no clue how to help reduce this step's time; perhaps for cases where maintainers are unable to do it because of time constraints they could give submitters directions on what to do for upstream bugs?] Once the upstream bug is filed, connecting the upstream bug to a Debian bug is the work of one minute or less. [As far as allowing for correspondance to flow more easily between upstream bugs and debian bug reports, that's something that can be worked on if enough people want it, but would still be dependant upon filing and connecting the two bug reports.] Don Armstrong -- Nothing is as inevitable as a mistake whose time has come. -- Tussman's Law http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox bugs mass-closed.
* Juliusz Chroboczek ([EMAIL PROTECTED]) wrote: > > Also node that many bugs are sometimes hard to reproduce, because you > > need a very specific environment that the maintainer not always have > > (e.g. the issue I have is that as a glibc maintainer, I've no large > > enough and used pam-ldap or NIS setups, and we have some bugs that rot > > because I don't have either the time or the resource to test them > > properly). > > I have no problem with the maintainer (a human being) asking me to do > something sensible about my bug report, such as confirming that the > bug still happens with the version in experimental, testing on a setup > he doesn't have access to, producing a backtrace, running random > commands on my system (as long as I understand what they do) etc. > > What Joey and I are specifically complaining about are three bugs that > we have described in enough detail and that are trivial to reproduce. > The maintainer did not send us personal mail asking for help; he sent > us an automated mass mailing threatening to discard our perfectly > valid reports unless we take some arbitrary action. > > This is clearly not the case that you are describing. So it isn't the maintainers who are doing this, but Lior. He asked if he could help and of course we said yes. I didn't vet (nor do I believe Mike did) the messages he sent out, nor do I really think we should have. Now that I've done some blame deflection, I really appreciate Lior work but I agree that narrowing the search criteria would make this a bit less spammy. Let me try to summarize some of the constructive ideas brought up in the thread. + Bugs marked unreproducible and lacking response from the submitter should very likely be closed. + Bugs with severity < normal, bugs forwarded upstream and bugs marked confirmed should probably not receive emails or perhaps just helpful reminders of its existence if the bug is older than X. + Better metrics should be come up with based on age of the bug, most recent "found" version and last activity on the bug. Not sure exactly what numbers to plug in, bug those seem like good indicators of continued relevance. + Maybe only sending a single email to a submitter with multiple open bugs. I think with some improvements like this there would reduce the false positive rate a lot. While it would be great to treat every bug individually by a human, the amount of bugs is really unmanageable and hugely time consuming by the small group of maintainers. These sort of automated reminders are a big help, even if they're not perfect yet. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Firefox bugs mass-closed.
On Wed, Oct 03, 2007 at 01:49:47AM -0400, Eric Dorland wrote: > * Juliusz Chroboczek ([EMAIL PROTECTED]) wrote: > > > Also node that many bugs are sometimes hard to reproduce, because you > > > need a very specific environment that the maintainer not always have > > > (e.g. the issue I have is that as a glibc maintainer, I've no large > > > enough and used pam-ldap or NIS setups, and we have some bugs that rot > > > because I don't have either the time or the resource to test them > > > properly). > > > > I have no problem with the maintainer (a human being) asking me to do > > something sensible about my bug report, such as confirming that the > > bug still happens with the version in experimental, testing on a setup > > he doesn't have access to, producing a backtrace, running random > > commands on my system (as long as I understand what they do) etc. > > > > What Joey and I are specifically complaining about are three bugs that > > we have described in enough detail and that are trivial to reproduce. > > The maintainer did not send us personal mail asking for help; he sent > > us an automated mass mailing threatening to discard our perfectly > > valid reports unless we take some arbitrary action. > > > > This is clearly not the case that you are describing. > > So it isn't the maintainers who are doing this, but Lior. He asked if > he could help and of course we said yes. I didn't vet (nor do I > believe Mike did) the messages he sent out, nor do I really think we > should have. > > Now that I've done some blame deflection, I really appreciate Lior > work but I agree that narrowing the search criteria would make this a > bit less spammy. Let me try to summarize some of the constructive > ideas brought up in the thread. > > + Bugs marked unreproducible and lacking response from the submitter > should very likely be closed. > > + Bugs with severity < normal, bugs forwarded upstream and bugs marked > confirmed should probably not receive emails or perhaps just helpful > reminders of its existence if the bug is older than X. > > + Better metrics should be come up with based on age of the bug, most > recent "found" version and last activity on the bug. Not sure exactly > what numbers to plug in, bug those seem like good indicators of > continued relevance. > > + Maybe only sending a single email to a submitter with multiple open > bugs. > > I think with some improvements like this there would reduce the false > positive rate a lot. While it would be great to treat every bug > individually by a human, the amount of bugs is really unmanageable and > hugely time consuming by the small group of maintainers. These sort > of automated reminders are a big help, even if they're not perfect yet. It could be worth writing a script dealing with this, especially now the BTS has "activity reporting" for bugs, that could land in devscripts. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox bugs mass-closed.
On Tue, Oct 02, 2007 at 09:48:07AM -0500, John Goerzen wrote: > I don't know about that. Hasn't it been a long-standing policy that bugs > that get no response from the submitter to questions can be closed? I know of no such policy. However, it has been common practice to do that for bugs that the maintainer cannot reproduce based on the information at hand. This is not the case being discussed. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: Firefox bugs mass-closed.
Le mardi 02 octobre 2007 à 18:01 -0500, John Goerzen a écrit : > No, that is a lot of manual work. > > I mean something like: > > $ bug-forward 456789 bacula > > and have it Just Work. When forwarding a bug report, the longest task is not opening the bug itself, which is just a copy&paste; the trouble is about finding a duplicate bug upstream. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Firefox bugs mass-closed.
On Wed, Oct 03, 2007 at 07:27:15AM +, Josselin Mouette wrote: > Le mardi 02 octobre 2007 à 18:01 -0500, John Goerzen a écrit : > > No, that is a lot of manual work. > > > > I mean something like: > > > > $ bug-forward 456789 bacula > > > > and have it Just Work. > > When forwarding a bug report, the longest task is not opening the bug > itself, which is just a copy&paste; the trouble is about finding a > duplicate bug upstream. I honestly reckon that I've many times not done this search thoroughly, and I agree. And I disagree with John about 15 minutes. When I was triaging the KDE bug tracker, here is how I worked: step 1: take the bug, try to reproduce it. - if able to reproduce it: open my browser, log (automatically because my browser remember my password for me doh!) in, report the bug (and for small upstream packages try to make sure that the bug isn't duplicated). - if not reproducible, many cases: * either it looked hard to reproduce, and then I asked the submitter about wether he still experiences the bug or not ; * either it looksed trivial to reproduce and is not anymore: depending on the age of the bug (e.g. if it was a KDE2 bug …) then I close it, else I tag it unreproducible, in a mail sent to the submitter asking if I took the right decision. Of course, unreproducible bugs without news from the submitter for a long time gets closed after a too long idling time. It took me between 5 to 15 minutes per bug. And the longest part was the "trying to reproduce" one. Forwarding upstream is rather a 5 minutes operation, especially if you do many bugs in a row. And linking the debian and upstream bug is half a second: $ bts forwarded n nn and being both in your clipboard. Then I can lazily rely on bts-link to wake me up when upstream bug report changes. So unlike John, I _do_ believe this approach scales well. Or at least not so badly, because it's an almost O(1) operation per bug. OTOH, I also do believe that the pinging mechanism I described many times already could help preventing forwarding some bugs for bugs that are long gone, but that the maintainer didn't had the chance to test in the first place because he was busy with any of the other 1000 he has to deal with, and preventing him to "lose" this O(1) time at all. So I'm really in favor of something in debbugs doing that (as it's easier from the BTS side, but it's 100% doable externally of course). This mail make me also think that forwarded bugs do not need to be pinged (or on a very less regular basis) as some upstream already apply pings, and that we don't want our pings to compete with upstream's. So right now the proper criteria for me looks like that: every trimester (?) compute the list of bugs that: * are applicable to current unstable (to avoid pinging for bugs in stable ;p) * are not yet marked as found in a current upstream (meaning that we would _not_ take the package debian revision for that, if the bug is marked as found in a 2.3-4 version, then if the current package is 2.3-12 we don't ping) * have seen no activity for more than 6 months * is not tagged wontfix, nor "forwarded" a mail would be sent to the -submitter@ asking for the submitter to send a mail to [EMAIL PROTECTED] with the correct action (mark the bug as found, or close it). Thanks to the soap interface to the BTS, we could even make those URL's the submitter would only have to click onto[0] (with some mechanism to avoid bots closing our bugs ;p). I _really_ think that this isn't very intrusive, and could help many maintainers in Debian focus on bugs that are still here. [0] we could even make a nice per-submitter form where the user could mark bugs that are fixed as such, mark the ones that are still here as found, and leave the ones he can't test anymore alone in a nice form, so that it's even simpler. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpekkNNgjjFa.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
On Tue, Oct 02, 2007 at 08:16:28PM +0200, Pierre Habouzit wrote: > On Tue, Oct 02, 2007 at 09:47:40AM +, Mark Brown wrote: > > It might help to do something like use the confirmed tag to flag reports > > which can readily be reproduced or which otherwise don't need the > > submitter to confirm them. This would mean that those bugs could be > Confirmed is not versionned. The fact that it was confirmed at one > point does not means that the bug is still here. In that regard, using > "found" with the proper version is better, as it tracks versions, and > can more efficientely prevent new pings when no new upstream was > released. You're missing the point here. What I said was that it would be an idea to use this for "bugs which can readily be reproduced or or which otherwise don't need the submitter to confirm them" and that this means that there is no need to ping the submitter to confirm that they are present in a given version. Doing this would allow pings to be done more intelligently - most of the times people get annoyed with mass pings it seems to be because they've been pinged about some trivially reproducible bug. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Re: Firefox bugs mass-closed.
On Wed, Oct 03, 2007 at 11:04:58AM +, Mark Brown wrote: > On Tue, Oct 02, 2007 at 08:16:28PM +0200, Pierre Habouzit wrote: > > On Tue, Oct 02, 2007 at 09:47:40AM +, Mark Brown wrote: > > > > It might help to do something like use the confirmed tag to flag reports > > > which can readily be reproduced or which otherwise don't need the > > > submitter to confirm them. This would mean that those bugs could be > > > Confirmed is not versionned. The fact that it was confirmed at one > > point does not means that the bug is still here. In that regard, using > > "found" with the proper version is better, as it tracks versions, and > > can more efficientely prevent new pings when no new upstream was > > released. > > You're missing the point here. What I said was that it would be an idea > to use this for "bugs which can readily be reproduced or or which > otherwise don't need the submitter to confirm them" and that this means > that there is no need to ping the submitter to confirm that they are > present in a given version. Doing this would allow pings to be done > more intelligently - most of the times people get annoyed with mass > pings it seems to be because they've been pinged about some trivially > reproducible bug. I don't miss the point, you miss the fact that the way exists, and is marking the bug as "found" in a specific version. It's not a task that only the submitter can perform, the maintainer can do that, and it will prevent pings in that case. (see the control@ refcard if you're confused, around the found/notfound fixed/notfixed commands). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpOnmgaZUcy5.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
On Wed, Oct 03, 2007 at 01:27:40PM +0200, Pierre Habouzit wrote: > I don't miss the point, you miss the fact that the way exists, and is > marking the bug as "found" in a specific version. It's not a task that > only the submitter can perform, the maintainer can do that, and it will > prevent pings in that case. (see the control@ refcard if you're > confused, around the found/notfound fixed/notfixed commands). No, both bits are useful - the point is to record how easy it is to reproduce a bug, not if it has been reproduced with a particular version. Compare, for example, a machine-specific bug in the X server (which can only be reproduced by someone with that particular hardware) with a bug where a program crashes on a particular input file (which can be reproduced by anyone with the relevant file). -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Re: Firefox bugs mass-closed.
Scribit Pierre Habouzit dies 02/10/2007 hora 20:16: > Confirmed is not versionned. The fact that it was confirmed at one > point does not means that the bug is still here. Wouldn't a generic found-by be useful? Then the bug could contain the information about not only the versions where the bug was found, but also by who. For the maintainer, confirming a bug is adding the info that he too found the bug at a current version. Generically, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Firefox bugs mass-closed.
On Wed October 3 2007 3:00:00 am Pierre Habouzit wrote: > On Wed, Oct 03, 2007 at 07:27:15AM +, Josselin Mouette wrote: > > Le mardi 02 octobre 2007 à 18:01 -0500, John Goerzen a écrit : > > > No, that is a lot of manual work. > > > > > > I mean something like: > > > > > > $ bug-forward 456789 bacula > > > > > > and have it Just Work. > > > > When forwarding a bug report, the longest task is not opening the bug > > itself, which is just a copy&paste; the trouble is about finding a > > duplicate bug upstream. > > I honestly reckon that I've many times not done this search > thoroughly, and I agree. And I disagree with John about 15 minutes. When > I was triaging the KDE bug tracker, here is how I worked: This assumes that you are doing a lot of work with one package (or related set of packages), rather than a little work on a lot of packages. My work falls into the latter category for sure. I don't maintain anything even close to the size of KDE, but I maintain many different packages.
Re: Firefox bugs mass-closed.
On Wed, Oct 03, 2007 at 04:47:50PM +, Pierre THIERRY wrote: > Scribit Pierre Habouzit dies 02/10/2007 hora 20:16: > > Confirmed is not versionned. The fact that it was confirmed at one > > point does not means that the bug is still here. > > Wouldn't a generic found-by be useful? Then the bug could contain the > information about not only the versions where the bug was found, but > also by who. For the maintainer, confirming a bug is adding the info > that he too found the bug at a current version. *g* found exists and is versionned, since sth like a year now. if not two. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgplzd4TNl4dN.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
Scribit Pierre Habouzit dies 03/10/2007 hora 21:49: > *g* found exists and is versionned, since sth like a year now. if not > two. But is the submitter of the "found" information made easily available? At least it's not shown anywhere in the version graph. Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Firefox bugs mass-closed.
On Thu, Oct 04, 2007 at 03:21:18AM +, Pierre THIERRY wrote: > Scribit Pierre Habouzit dies 03/10/2007 hora 21:49: > > *g* found exists and is versionned, since sth like a year now. if not > > two. > > But is the submitter of the "found" information made easily available? > At least it's not shown anywhere in the version graph. in the bug log of course it is. bts --mbox show is your friend. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpIZzDEPeEAW.pgp Description: PGP signature
Re: Firefox bugs mass-closed.
10am Friday sounds good to me, many thanks for sorting this Patrick Pete On 2 Oct 2007, at 20:09, Pierre Habouzit wrote: On Tue, Oct 02, 2007 at 01:25:21PM +, John Goerzen wrote: Of course, the question is how to determine what's an upstream bug. Perhaps we could still receive reports in our Debian BTS, but provide some automated tools to send them on to popular types of upstream BTSs, and then close the Debian report with a pointer to the upstream location? you mean using the forwarded state and bts-link ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp:// www.madism.org Dr Peter Clapham, Informatics System Group The Wellcome Trust Sanger Institute, Hinxton, Cambridge, CB10 1HH, UK -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Re: Firefox bugs mass-closed.
We encourage people to not file duplicate bug reports, and check the BTS first. So I check the BTS, the bug is there, I don't file a new one (I do send a "me too"). 6 weeks later, the bug is closed because the submitter's email is bouncing and he's on vacation anyway. It sounds like what is really required is the ability for a bug to have multiple "reporters" recorded. Then any queries about a bug can be sent to all the reporters not just the one who happened to submit the report first. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox bugs mass-closed.
On Sat, Oct 20, 2007 at 05:15:51PM +0100, peter green wrote: > >We encourage people to not file duplicate bug reports, and check the BTS > >first. So I check the BTS, the bug is there, I don't file a new one (I > >do send a "me too"). 6 weeks later, the bug is closed because the > >submitter's email is bouncing and he's on vacation anyway. > It sounds like what is really required is the ability for a bug to have > multiple "reporters" recorded. Then any queries about a bug can be sent to > all the reporters not just the one who happened to submit the report first. > Just curious, but what benefit would this provide? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Firefox bugs mass-closed.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 peter green wrote: > It sounds like what is really required is the ability for a bug to have > multiple "reporters" recorded. Then any queries about a bug can be sent to > all the reporters not just the one who happened to submit the report > first. Why multiple reporters? you can subscribe to a bug report by sending an email to [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHGogjYy49rUbZzloRAl36AJ4t0RYHjqQQQUJDFcfei6Ntk1IwygCfWiA7 S9lpyPOl+rptP2CtfN8cvo8= =TZiB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox bugs mass-closed.
On Sat, 20 Oct 2007, peter green wrote: >> We encourage people to not file duplicate bug reports, and check the BTS >> first. So I check the BTS, the bug is there, I don't file a new one (I >> do send a "me too"). 6 weeks later, the bug is closed because the >> submitter's email is bouncing and he's on vacation anyway. > It sounds like what is really required is the ability for a bug to have > multiple "reporters" recorded. Then any queries about a bug can be sent to > all the reporters not just the one who happened to submit the report first. If you want that, just subscribe to the bug. Submitters as it is now do not automatically receive all messages regarding a bug. Don Armstrong -- No matter how many instances of white swans we may have observed, this does not justify the conclusion that all swans are white. -- Sir Karl Popper _Logic of Scientific Discovery_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox bugs mass-closed.
I dutifully re-checked each bug. Today I got another pile in my mailbox to recheck. I did not check if they were the ones I had just rechecked. I instead just gave up. This is the Bank. You have 60 days to respond that you still want the money in your account. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox bugs mass-closed.
[EMAIL PROTECTED] wrote: > I dutifully re-checked each bug. 1. I did't see comments for each of your bugs saying "it's still relevant for version X of iceweasl". 2. The comments you did mail were doing to [EMAIL PROTECTED] Meaning neither the maintainer nor I were aware of your response. I had to manually look over all your bugs to find them... The ones you confirmed were reassigned to iceweasel with the relevant version info. A mail about #266753 was sent as you suggested > Today I got another pile in my mailbox to recheck. > I did not check if they were the ones I had just rechecked. > I instead just gave up. Here is the list of your bugs still waiting for confirmation: #394904 #399539 #372667 #374512 #402230 #353222 #354755 #357668 #368127 #370054 #372662 #377898 #392438 #398985 #399549 #400639 -- Lior Kaplan [EMAIL PROTECTED] GPG fingerprint: C644 D0B3 92F4 8FE4 4662 B541 1558 9445 99E8 1DA0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox bugs mass-closed.
Thanks anyway. You are welcome to do what you wish with my firefox bugs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
