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

Re: What to do with unresponsive maintainers?

Jeroen van Wolffelaar <jeroen@wolffelaar.nl> writes:

> On Mon, May 03, 2004 at 05:34:04PM +0200, Goswin von Brederlow wrote:
>> Jeroen van Wolffelaar <jeroen@wolffelaar.nl> writes:
>> > A high bug count an-sich is no shame. It is only an indication that the
>> > package apparently is useful, and people take the time to give feedback
>> > to make it even more useful.
>> On the other hand a bug count on your package will be seen as badly
>> maintained during the NM process. So I can see why someone wants to
>> close all bugs he can do nothing about or not even reproduce.
> For the record: I have seen no single indication that this is true. If
> you really think that your statement is true, please show some
> references to that effect. Simply posing something without arguments

My xlife package having bugs and having been NMUed (on my request) was
used against me. So I have first hand knowledge of it.

> won't convince me. Also, you mix two issues: this wasn't about bugs that
> are really unreproducable and might be the user's fault and also have an
> unresponsive submitter, but about all other bugs. And whether you leave
> the latter as 'unreproducable' in the bts, or close them, I still don't
> think that matters much.

Bugs that can be reproduced should certainly never be closed without a
good reason. The new maintainer should tag them acklowledged (and
untag bugs he can't acklowledge) and maybe add updated dependency
infos used to reproduce it.

> I really cannot imagine that anyone involved in NM will simply add up
> the bug counts, divide them by number of packages, and see that as an
> indication of well-maintainance.  Rather, for example most AM's that I
> know find the package-checking thing one of the more tedious AM things
> to do, and that's not because just counting bugs is how it's done.
> --Jeroen

Of cause its not so simple as counting bugs.


Reply to: