Hi, Sune: On Wednesday 12 January 2011 14:27:23 Sune Vuorela wrote: > On 2011-01-11, brian m. carlson <sand...@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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101122252.51506.jesus.nava...@undominio.net