Re: Forwarding bugs upstream
"Jesús M. Navarro" <jesus.navarro@undominio.net> writes:
> Why the package(s) got 400 bugs to start with? If the problem is there,
> then it's there. If somebody opened the bug then there was a bug at
> least on his opinion which nobody challenged. If there was a bug, then
> it need to be supposed that it will be there till there exists clear
> indication on the contrary. Anything else is awful practice.
I would argue that by the time the package reaches several thousand open
bugs, all of which are some random mix of upstream, fixed, unreproducible,
packaging, and incomplete reports, the BTS has become essentially unusable
for everyone. The maintainers rarely have time to go back and look at
those thousands of bugs in any meaningful way, and users are not going to
be able to reasonably search through that many bugs to see if any of them
are the problem that they're running into. At that point, the BTS is
about as useful as a mailing list archive and the only chance that
anything in there is going to be helpful is if Google happens to index it.
In my personal experience, generally at that point the mailing list
archive of wherever the bugs were originally sent is actually *more*
useful since it's better-indexed.
I think we have a significant failure mode here with packages that get
large numbers of bugs. The BTS becomes pretty much unusable without very
active triaging for those packages. And this is not a Debian-specific
problem; for example, it's essentially impossible to extract any useful
information from the Ubuntu nvidia-graphics-drivers bug page, and it only
has 350 bugs. (Launchpad is, in my experience, worse than the Debian BTS
at handling large bug volumes and becomes unusable faster.)
There are a lot of things that have been said on this thread that I
completely agree with for the average Debian package that gets a handful
of bugs a month and doesn't have more than 50-100 bugs open at a time. I
think most of the people commenting here have dealt primarily with those
sorts of packages, and that's the experience in which the comments are
grounded.
Packages with thousands of bugs are another world, and while I agree with
the drawbacks of aggressive bug triaging, I think aggressive bug triaging
is still a better approach than letting the BTS page become a junk pile of
abandoned reports no one is ever going to look at again.
Obviously, the ideal is to have teams that scale with the incoming bug
count for the package, who will stay on top of all those bugs and
categorize them appropriately and ping unreproducible bugs, forward
upstream bugs, and do all the great things that make the world a better
place. But in the world in which we live, that manpower simply doesn't
exist. If wishes were horses, beggars would ride. We have to apply
strategies that are realistic given the manpower that we actually have,
not the manpower that we wish we had.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: