* 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]
