Re: Forwarding bugs upstream
Hi, Sune:
On Wednesday 12 January 2011 14:27:23 Sune Vuorela wrote:
> On 2011-01-11, brian m. carlson <sandals@crustytoothpaste.net> wrote:
> > I've noticed a trend lately that I am often asked to forward the bugs I
> > report to the Debian BTS upstream, either by the maintainers or
> > automatically by a bug script. I believe, and I continue to believe,
>
> I have considered to take this one step further. Close bugs reported in
> Debian BTS with a severity of important or less that is a bug that
> should primarily be fixed upstream.
Will this mean that the problem will somehow disappear from Debian? Because
if it's a problem detected within Debian it's my feeling that it will have to
be tracked within Debian till the problem is in Debian no more.
> Currently, the debian Qt/KDE team has around 800 open, non-forwarded
> bugs reported against their packages. I would guess that maybe 20 of
> them is packaging issues. But we can't find them.
Start one at a time.
I've been both sides of the wall (as and end user and as being in charge of
supporting some apps and environments) and here comes my opinion as a "mere
user with some hindsights". I'll try to make my points clear, so if someone
finds them a bit harsh, please understand that it was not my intention, that
my native language is not English and that my aim is mainly make myself as
clear as possible:
From the user point of view:
1) A known operational problem that is still there never should map to a
closed bug, no matter what. That means that "forwarded upstream", while it
might be a valid bug state can't be one meaning "closed". I'm having a
problem so I'm looking at open problems in the bug database. That means that
if there's a problem in, say, Lenny, even if it's demonstrably closed in
Squeeze it should appear opened when I look for bugs in Lenny.
2) The maintainer took over his shoulders some responsibilities when he became
maintainer. When I'm facing a problem with a package in the distribution,
it's you the one that will have to cope with it. You'll take my data and
you'll try to reproduce the bug. If you are able to reproduce the bug, then
it's your problem from now on. If you can't you'll ask me for more data and
will try to hint which data will be more valuable and will explain to me.
3) Corollary of two is that if you are able to reproduce the bug and you deem
it to be an upstream one, you should be the one rising it to upstream and
track it from them on, but since the problem is still there you shouldn't
close the bug (see 1) but mark/tag it as an upstream problem and that you
already are dealing with it with upstream at upstream's XXXX bug number.
4) It's not my problem that you lack the time, really. And no, that you are
not paid for it it's no excuse either.
Maybe it's that you lack the time for the *boring* side of the task or maybe
it's that you really don't have the time. In the first case resign as a
debian maintainer; in the second one orphan the package. Debian is proud to
host a bazillion packages but I really appreciate much more 1/10th of a
bazillion worth of properly maintained packages than a bazillion of half
assed ones. In the first case I know exactly what the situation is, in the
second I don't know if I'm lucky when I see foo already packaged for Debian
or if foo will be one of the less than production-ready ones. It severely
hinders the overall perception about the quality of the project.
5) I as a user should understand that you are not a magician; without enough
data you won't be able to deal with my bug and you will have to close it as
non-reproducible, if I don't feel that to be a good reason I always can go
anywhere else (say, the upstream developer) to see if I'm more lucky there.
6) There will be (rare) cases when the debian maintainer really won't be in a
position of being of help. Then I'll need to understand that, after all,
it's me the one having a problem, not him, so it's in my best interest to
take the time going upstream to see what can be done and make the debian
maintainer (and other who might happen to look at the bug records) know about
that.
7) Tracking bugs is always a burden so don't expect too much from somebody
doing it for free. Try to be helpful since it's in your best interest, say
thanks with open spirit and, please, take the time to introduce a workaround
or the solution you found in the bug system so others can benefit out of it
and the debian maintainer can dedicate his time to something more productive.
From the maintainer point of view:
1) An unreproducible bug is an unexistant bug. It's valid for unexistant bugs
not to show in an open bugs list so you are free to close them with a
non-reproducible message. If nine out of ten bug reports lack enough data,
ask for better data and advise that without new data you won't be able to
reproduce the bug so it will be closed in a decent amount of time (say, two
weeks? one month?) and then you'll be free to close nine out of ten bugs
right away, so more time to deal with the valid ones.
2) If you feel it's probably an upstream bug you can't reproduce because
there's not enough data not because the user lacks the will to produce it to
you but because you don't know the inners of the program good enough to ask
for meaninful info, it is still your burden to communicate to upstream and
act as a man-in-the-middle at least till you convince yourself it won't be
reproducible, in which case you'll tag as it and/or collect enough evidence
as to ask the end user to go upstream if he so likes under the condition that
he will inform you of the upstream's bug number so you can track it. If the
end user produces for you a bug number, then you'll tag yours as forwarded
upstream and you will take the time to track it. If the end-user doesn't
produce the bug number in proper time (again, two weeks? one month?) you'll
close yours as non-reproducible and done with it.
3) Always leave space for alternatives and exceptions. If you deal with a
knowledgeable user and you feel you'll get in the middle instead of being of
help, certainly you can point the user to the upstream developer asking for
the bug number to track it. Tag the bug with the upstream bug no. and if you
are able to reproduce it, give your help on the upstream's bug system to both
your user and the upstreamer.
4) Always be proud of your work but make sure you make what it takes to be
able to be proud of your work.
Cheers.
Reply to: