On Sun, Nov 25, 2007 at 12:20:39PM +0100, Torsten Werner wrote: > I am worried how such problems are discussed in our project. Instead > of teaching our fellows how to contribute better to Debian we denounce > them in our mailing lists. > > There was a bug report submitted an November 23rd. I do not find any > instructions in the BTS how to fix that particular problem. I'd like > to know:
While I partly agree with you, I think there was a certain amount of unfriendliness on both sides. One of the unfortunate problems here seems to be that the maintainer added a documentation file that explicitly asked for bugs not to be filed (on something that is elsewhere defined as an RC bug). That seems to limit the polite avenues of recourse somewhat. I know sometimes things come up that after extensive discussion are determined to be correct, but nevertheless people keep filing bugs about them because they didn't see the original discussion, or just because the issue is plain controversial and the maintainer has made a choice. In that case it can certainly be reasonable to ask users not to file bugs about something. However, in general, writing "do not file bugs on this" in README.Debian is pretty much saying straight out that you know better than your fellow developers. If you turn out to be wrong, don't be surprised when the reaction to that is rather acerbic ... Nobody expects perfection, or at any rate nobody should. Certainly the number of bugs on my own packages doesn't suggest perfection! The thing that really gets people's backs up is when you claim perfection when it isn't true. I think the lesson for Kartik to take away from this should be that bugs aren't necessarily showstoppers, but if you know about a bug, or even if you aren't sure, it is much better to admit that it may be a problem - you might even want to file the bug yourself - so that it can be fixed in future, rather than trying to paper over it. If an automated tool reports something as a bug, then that doesn't necessarily mean that you have to drop everything and fix it right away, but do think twice before ignoring it. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
