Re: What to do about negligent maintainers?
On Thu, Jan 07, 2010 at 05:02:07PM -0800, Russ Allbery wrote:
> Charles Plessy <email@example.com> writes:
> > This package-centric point of view ensure that the RC bugs are fixed by
> > either correction or removal. The punitive approaches like orphaning the
> > package or expelling the maintainer are not fixing the bugs and
> > therefore increase the entropy with no benefit, in my opinion.
> > Given that for some (most?) of the packages maintained by Anìbal I have
> > not seen attempts to takeover, I think that it is difficult to decide
> > whether his maintainership is detrimental to the package, or in contrary
> > better than nothing.
> I mostly agree with this, but I think it discounts the fact that
> maintainers frequently only step forward once a package has been orphaned
> and shows up on wnpp-alert. It's much easier to find someone to adopt a
> package once it's been orphaned. Few people want to go to the extra
> effort of trying to convince an existing maintainer to give up a package
> and risking a confrontational conversation.
> So while it is quite possible in some cases that the existing maintainers,
> who aren't doing that great, are better than the package going
> unmaintained at all, orphaning the package *is* more effective on average
> than just limping along with the existing maintainer due to the tendency
> of orphaning to prompt new maintainers to step forward.
> (For example, I have no time or energy to evaluate how good of a job
> Anìbal is or is not doing with fping, but if it were orphaned, I would
> probably adopt it, just as I'm likely to adopt tripwire if it goes for too
> much longer with no one else stepping forward.)
From my reading of -devel, I have come accross this tension between a current
maintainer who does not give any information about what they are going to do
with their package in say 6 months, and this somewhat or very interested
maintainer who is monitoring this situtation with a certain package and/or
maintatiner --- seemingly waiting with baited breath for a mere whisper of a
sign of activity or a sign that they will orphan their package. Its like a
secret admirer waiting to go talk to a crush. The missing ingredient is the
intention of the package maintainer about what their intention is WRT their
package(s) and the time frame involved. If the perspectivly more interested
developer could know what to expect, they might be motivated to take action
sooner rather than wait for the last minute. Would it be useful to store a
simple sentence in the package database along with each package about the plan
for the package and the time frame.
Plan: to upgrade foobar to version 1.2.4
Timeframe: 1 to 3 week depending upon work
Looking for co-maintainers: yes
RC bugs: 3
| .''`. == Debian GNU/Linux == | http://kevix.myopenid.com |
| : :' : The Universal OS | mysite.verizon.net/kevin.mark/ |
| `. `' http://www.debian.org/ | http://counter.li.org [#238656]|
|___`-____Unless I ask to be CCd, assume I am subscribed _________|