[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#247312: konqueror: opening of bookmarks is much slower when clicking directly on Bookmarks menu



On Sat, Jan 08, 2005 at 01:39:46AM +0100, Frans Pop wrote:

> I've read most of the bug history. And I must say to the submitter: if you 
> think 7 months is bad, you're in for bigger disappointments. There are 
> bugs in the BTS that are over 3 years old (some even on issues not as 
> trivial as this one...).

I'm not talking about any kind of bug report. I'm talking about
a submitted bug that has failed to be just tagged upstream and
forwarded for almost 8 months now.

> Although in principle bug triage _is_ the job of the package 
> maintainer(s), it is also their good right to prioritize their work, 
> *especially* as we are all volunteers.

I guess no one expects the Debian KDE team to _solve_ the bug, and
neither do I.
"All" a Debian KDE maintainer should have done is to take a couple of
minutes to actually tag the bug and forward it to upstream.
By not doing so, the bug has lurked around without any processing from
upstream (or anyone else) for months and months. This situation is
just too silly, whether the team is busy or not.

> IMO the responsibility of a maintainer for bug triage is bigger if 
> upstream is less accessible to users. For KDE this is clearly _not_ the 
> case. Upstream has a great BTS themselves, open to all and easy to find. 
> They even have a nice voting system that allows users to collectively 
> determine the priority of an issue.

You can always tell the submitter should have reported it to upstream
directly: so just prevent reportbug from sending upstream bugs to
Debian, because otherwise the submitter is absolutely not supposed to
know that the maintainers are completely buried in work.

> I myself have over the past 5 years or so made the transition from "file 
> everything in the Debian BTS as that's my distribution" to "hey, where 
> does this problem come from and let's file upstream if more appropriate". 
> In the second case I may also submit a bug in Debian's BTS if I feel the 
> maintainers or other users should be aware of the problem.
> Of course packaging related issues should always go to Debian's BTS, but 
> especially for wishlist and minor issues that are clearly upstream, 
> submitting directly to KDE's BTS is often the better solution as their 
> manpower (and ability to judge the severity and relevance of an issue) is 
> way greater than Debian's KDE team.

Some ask why the submitter has not submitted the bug directly to
upstream when noticing months after that nothing had happened. Once
more, I regret: if the submitter gets no feedback, he'll consider
that the upstream team had hard times chasing the bug (some bugs are
tricky), certainly not that the Debian guys has left his report in the
bottom of the barrel for months. Do you actually understand that?

> A last suggestion to the submitter: you could have tried asking here how 
> best to proceed.

Once more, the submitter is absolutely not supposed to know that he should
ask how to proceed instead of just reporting the bug itself, like reportbug
(and http://www.debian.org/Bugs/Reporting) kindly advise him to.

And are you really aware of what the BTS would be if every submitter
should ask how to proceed first? Come on, you must be joking, especially
since the Debian KDE maintainers don't even seem to have time to complete
elementary tasks (like just _processing_ this bug).
How can you ever think that they would have the time to reply to
submitters' questions asking how to proceed? (I like recursive jokes,
but there's a limit)
The submitter just does what Debian asks/allows him to do, and he has
no way to know in advance if his bug will stay unprocessed (I didn't
say solved) for ages or quickly forwarded and eventually solved. He's
not supposed to know the guys who will deal with his request, whether
they are overly busy or not, or (and that still what I'm thinking about
this particular case... hope I have demonstrated it more convincingly)
whether they have erratic scheduling practices or not, I'm sorry I
have to say that.

Oh, I forgot: it is _not_ the submitter's job to monitor every bug
he filled, just because the submitter can absolutely not imagine
that his report might well _not be processed at all_ for months,
years, decad^Wok, trollinit aborted.
He'll rather think "naively" that maintainers will do what's best
during the week (yes, 2 minutes time, remember) and hope upstream
will provide a fix some day (a delay is much more expectable here, as
it is where the bottleneck may clearly reside, even if... not always,
apparently! :-( ).
"When Debian KDE processing times might well take way longer than upstream
fixing ones". Nice title, but sad tale.
Sorry if I'm becoming more and more sarcastic, but I feel that some
are more concerned with finding any excuse for justifying the
unjustifiable, rather than actually trying to analyze the reasons and
change things so that this will not happen again.

Seems like we all like discussions, but I hope you realize that 
all the cumulated time spent in this discussion by Debian KDE
maintainers already represents at the very least 20 times more
time than one tag/forward operation would require (ok, now I guess
some guy will probably say that the bug submitter is the one to
blame, wrong shot).

So let's hope this time hasn't been completely wasted. I already gave
one element in that sense, but do as you wish:

Please process _every_ new bugs (but old ones may also require that as a
start) within a week:
- if the immediate action required for it clearly take less than a
  couple of minutes (like tag+forward), please just _do_ it right
  away!
- if you feel this bug won't be able to be fixed by your team within
  more than 2 months (arbitrary value), please let at least the
  submitter know
The rest, you'll deal with it the best you can, as everyone.

 Herve



Reply to: