On Tue, Jan 11, 2011 at 09:15:41PM -0600, John Goerzen wrote: > I think it is perfectly fine for a user to submit a bug report to > the Debian BTS first. They may not always be equipped to know what > is a Debian and what is an upstream bug. And I also think it ought > to be perfectly valid for the Debian developer to close the bug > saying it's an upstream issue, together with a pointer to the > upstream BTS and promise to get involved should there be any > question about the Debian packaging, environment, etc.
I think this can actually increase the maintainer's burden, since it can increase the number of duplicate bug reports, since there isn't already a bug listed as reported. I generally assume that if a bug is open but not marked forwarded that it isn't forwarded, and I'm not intrinsically opposed to this. Forwarded bugs are better, but if it doesn't happen immediately, that's okay. > Now, here's how it proceeds if I have to forward a bug upstream for > Bacula, which uses Mantis. Creating a Mantis account takes 30 > seconds, but Mantis won't email reports to people without accounts, > and the only way to add stuff to it is on the web. As I've said, I generally don't mind being added to the CC list, and I think that BTS systems should allow non-subscribers (and subscribers) to add information via email. I realize that upstreams tend to use BTSes that don't do that and therefore make their end users go through a lot of unnecessary pain. Also, if the BTS won't CC me when someone responds to the bug (even with an account), there is zero chance of me reporting the bug upstream, since I have better things to do with my life than constantly checking a slew of BTSes. > I'm adding zero value here. Zero. It is a huge and frustrating > waste of my time. It is also frustrating for upstream, who would > rather just talk with the user directly and involve me if they think > there's a Debian-specific question. I don't understand why some > users want it to go this way, but many clearly do despite the fact > that they get worse service. I think it depends on the situation. I've looked at the open and forwarded bugs reported under this email address and of the 60, there are at least 47 that I could immediately determine (just by being reminded of the Subject line) that included a testcase or a patch or were trivially easy to reproduce (or understand wrt the desired feature for wishlist requests). Those are pretty much forward-and-forget. There are cases where the maintainer cannot appreciably reproduce the problem (such as with the kernel or X) and then I have to make a decision whether I want to put up with the bug or forward it upstream myself. In these cases, it's usually the former, since I am just not going to recompile my kernel (which is the Debian one) the ten times required to bisect the problem. If there's a new version in experimental, I will often try that to see if it solves the problem, though, and report back. I try to forward bugs upstream when I have the time, especially when I have a patch, since it may need tweaking with upstream. But I always try to put a patch in the Debian BTS, since it is much more likely to be rapidly fixed in that case. (#605941 is a great example of this.) So I think what my position is is this: if the bug is simple, clear, and easily understandable, then I don't think it's unreasonable for the maintainer to forward the bug upstream. Examples that I think fit into this category: * (normal) This program produces out-of-range results when I use the attached file as input and option -p. * (wishlist) This program should support W3C specification ABC (as well as the currently-supported DEF) with regard to XYZ functionality. If it's going to be difficult and require the user and upstream to work together to solve the problem, then it's okay to say something like, "I can't reproduce this problem and upstream is not going to be able to fix it without your help, so would you mind forwarding the bug upstream?" Giving a reason actually makes me much more likely to comply and less likely to be irritated. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
