Re: Attempted summary and thoughts
Ben Finney <bignose+hates-spam@benfinney.id.au> writes:
> Russ Allbery <rra@debian.org> writes:
>> If that person has showed up and is being blocked from helping for some
>> reason, *then* we can talk.
> I think that's what the proposal is suggesting. Do you think the metric
> used is bad, or is there some other flaw?
Yes, I think the metric is bad. Having bugs tagged patch does not
indicate that people are willing to maintain the package and upload new
versions of it. It means that someone has submitted what they think is a
fix to a bug. That's all.
I've submitted many bugs tagged patch for packages where I'm in no
position to test or upload a new version. And I've seen many bugs arrive
with patch tags where the patch isn't suitable in its current form. The
maintainer should be triaging those bugs and removing the bad tags, but
that doesn't mean that you can use the existence of them as evidence that
someone else would step forward and maintain the package.
> I presume you're referring to the definition of the 'patch' tag:
> patch
> A patch or some other easy procedure for fixing the bug is
> included in the bug logs. If there's a patch, but it doesn't
> resolve the bug adequately or causes some other problems, this tag
> should not be used.
> <URL:http://www.debian.org/Bugs/Developer#tags>
> Are you implying that the bug reports tagged 'patch' that you're talking
> about -- lots of them -- "don't resolve the bug adequately or cause some
> other problem"?
Yes.
> If so, what action do you think should be taken in the case where those
> bug reports are not addressed by the package maintainer?
Someone should triage the bug and remove the tag if the patch isn't
adequate. An untriaged bug is an untriaged bug -- we don't really know
*what's* in it. Just because it has a patch tag doesn't mean it's
necessarily any higher-quality of a bug unless it's been triaged.
So I agree wholeheartedly with the idea that bug triage is important, but
it doesn't always happen and that's why we're having this conversation. I
agree that one can infer from the existence of untriaged bugs that not all
the package maintenance we want is happening. But the one and only one
solution to that is to get more people working on the package or make more
time for the existing maintainers to work on the package, and orphaning
the package does not magically accomplish this.
I'm willing to support being more aggressive than we currently are about
changing maintainers when someone else steps up and is willing to do the
work, but I'm not willing to support any proposal that automatically
orphans packages where there's no one waiting to work on it who is being
blocked by the current maintainer. I don't think that actually
accomplishes anything useful. We don't have to orphan the package to know
that it's in trouble -- there are many other metrics that can be used for
that.
It's also worth noting that many of our overloaded and not horribly active
maintainers are also high-quality domain experts in their packages. They
may not do very much work, and they may not be keeping up with maintenance
of the package, but the work that they *do* find time to do is often of
very high quality. Replacing that work with the efforts of someone with a
lot of enthusiasm but not very much knowledge is sometimes the right thing
to do and sometimes very much *isn't*.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: