

Re: Forwarding bugs upstream

Hi, Sune:

On Wednesday 12 January 2011 14:27:23 Sune Vuorela wrote:
> 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.

> 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 

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.


Reply to: