Re: "Blacklists" in BTS (stopping the trolls and bug machines)
On Mon, May 27, 2013 at 09:04:53AM +0200, Ondřej Surý wrote:
> On Sat, May 25, 2013 at 8:02 PM, Russ Allbery <rra@debian.org> wrote:
> > He still files all upstream bugs with Debian, but I can't throw stones
> > there;
I do not think this is wrong. In fact, one of the reasons I like Debian, is
that I can report bugs in a uniform way and the maintainer will (well, should
at least) take care of handling communication with upstream where appropriate.
If it would be inappropriate to file upstream bugs with Debian, reportbug
should be changed to complain if you try to add the upstream tag. It doesn't,
and in my opinion it shouldn't. Forwarding stuff upstream is actually part of
your task as a package maintainer.
> > I tend to do the same thing myself, since Debian has such a nice and
> > consistent bug reporting interface and upstream's usually... isn't. :)
That too. :-) And in many cases they require you to subscribe to a mailinglist
while you only want to see replies to your own report, not follow the
development of the program. This requirement is acceptable for the maintainer
of the Debian package, but not for someone who thinks "this can be better,
perhaps they didn't think about it".
> > He files lots and lots of minor/wishlist bugs, but that isn't abuse. He's
> > one of the few people who regularly files bugs when he finds unclear or
> > confusing documentation, and while that results in a lot of small bugs
> > (and a lot of bugs that are really upstream bugs), I think that's also a
> > valuable *type* of bug that frequently doesn't get enough attention.
I agree. On a completely different level, those bugs are also often quite easy
to fix (taking mostly time, not much skill), and therefore can be used to
attract new developers to a project.
> The "I see a warning from ucf, let's fill a bug on php5-common" finally
> overflew my cup of patience.
Especially with simple wishlist bugs, the submitter doesn't want to dig deep
into the package to see what the problem really is. In a case like this, the
maintainer should reassign the bug to the package that causes it, just like
they should forward it upstream if appropriate. This is a similar action,
which as I wrote I consider part of the task of a package maintainer.
> This might be similar to what I have seen in Launchpad – there's a bugsquad
> team that can handle all bugreports in just any package[1][2].
We have a pretty good NMU system, which lets any DD handle bugs in any package.
There's nothing wrong with preparing an NMU for a wishlist bug. So we already
have that team. Perhaps the QA team is even closer to what you mean, but they
always say that any DD is in the QA team, so there isn't really a difference.
;-) But as you write, most people will not fix (or ask for more info on)
wishlist bugs in other people's packages.
On Mon, May 27, 2013 at 11:46:05AM +0200, Ondřej Surý wrote:
> > If you think you are distracted by some bug reports, end users
> > are also distracted by debug messages (which are not clearly
> > debug messages) in the terminal.
And speaking for me personally, even if they are clearly debug messages, I
still consider it a bug that they were enabled for a release. I don't think
I've ever reported such a thing, but I might do that. It's one of those things
which is trivial to fix when you're preparing a release anyway, and makes the
package a tiny bit better if done right.
> BTW there's around 2000 open bugs marked as moreinfo, the oldest is dated
> Sun, 29 Mar 1998 21:03:03 UTC.
For moreinfo bugs, you are not considered a bad maintainer if you send a "I
will close this if you don't reply"-response after some time and then do that
after some more waiting. (Where "some time" and "some more" << 15 years.)
Thanks,
Bas
Reply to: