Re: What to do about negligent maintainers?

[Don Armstrong]

On Sat, 09 Jan 2010, Charles Plessy wrote:
> But anyway, the ‘first adopter served’ tradition is a source of
> problems.

Package maintainers can choose who they wish to let adopt their
packages. If the package is orphaned or the maintainer is MIA, the
person who discovers that the package is MIA or orphaned is often the
person who actually ends up maintaining it (or at least is probably
qualified to maintain it if they actually have the time.)

Only in those cases where the current package maintainer and a
prospective package maintainer are unable to agree does the CTTE need
to be brought in to decide. [The CTTE will take at minimum two weeks
to come to a decision itself.]


Don Armstrong

-- 
Sentenced to two years hard labor (for sodomy), Oscar Wilde stood
handcuffed in driving rain waiting for transport to prison.  "If this
is the way Queen Victoria treats her prisoners," he remarked, "she
doesn't deserve to have any."

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What to do about negligent maintainers?

[Mark Brown]

On Sat, Jan 09, 2010 at 12:26:18AM +, Marco d'Itri wrote:
> broo...@sirena.org.uk wrote:

> >The trouble with an approach like that is that it doesn't provide a
> >clear route to dealing with situations where the maintainer is
> >occasionally active but not managing to keep up with things well enough
> >to do a good job.

> So help him: start by sending patches to the BTS.
> If he is not replying to your enquires it is reasonable to believe that
> currently he is not working on the package either.

That works in cases where the maintainer is just having trouble keeping
up, but there are other cases where the package is frequently buggy
after maintainer uploads, or where responsiveness is very much
intermittent.  Often this seems to be another symptom of overwork but it
needs to be dealt with a little differently.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What to do about negligent maintainers?

[Charles Plessy]

Le Sat, Jan 09, 2010 at 01:04:25AM +0100, Tollef Fog Heen a écrit :
> 
> There was at least one person who helped out quite a bit with
> nfs-common, but got tired of co-maintaining as it was a continous uphill
> struggle where the maintainer quite often broke stuff and didn't
> coordinate.  Maybe he could have hijacked it and gotten away with it,
> but he didn't do that.  So while this approach might work in some cases,
> it's not a sure recipe for success.

I think that packages split in two cases, whether they provide a core
functionality or not.

For non-core packages, I think that the current adoption procedure is the way
to go (Def. Ref §5.9.5). Of course, the best outcome of the discussion could be
that the package gets team-maintained in a VCS where the previous maintainer
has access if he has a long-standing interest in the package (sometimes it is
also fun to do new things instead). In the case the package is a burden to
Debian because of its bugs but nobody else than the maintainer wants it to stay
in Debian, then its removal can be questionned in a wishlist bug, which can be
easily transferred as a request for removal to ftp.debian.org (with a summary)
if the reporter is confident enough. There were discussions on this topic
on the debian-qa list last December on how to make this workflow more efficient.

For more important packages, I think that the way their maintainer is decided
is sometimes completely suboptimal. I have seen a couple of times some core
maintainers orphaning a large number of such packages, which are then assigned
on a ‘first served’ basis within a hour! This is what it looks it happened for
nfs-common. I am not a fan of procedures, but for packages like nfs-common,
spending only one hour in ten years to select who will work on it is not wise.

If the TC does not mind this extra work load, I would find reasonnable that for
a given list of packages, the maintainer is decided by the TC. Normally, it
would simply mean to tacitly accept the consensus reached on
debian-de...@lists.debian.org, and in a few cases, it would need to take a
decision that make one person or a group of person unhappy. How to decide the
list of packages whose maintainer is chosen by the TC could be done on the
basis of the package priority. But anyway, the ‘first adopter served’ tradition
is a source of problems.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What to do about negligent maintainers?

[Marco d'Itri]

broo...@sirena.org.uk wrote:

>The trouble with an approach like that is that it doesn't provide a
>clear route to dealing with situations where the maintainer is
>occasionally active but not managing to keep up with things well enough
>to do a good job.
So help him: start by sending patches to the BTS.
If he is not replying to your enquires it is reasonable to believe that
currently he is not working on the package either.

-- 
ciao,
Marco


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What to do about negligent maintainers?

[Tollef Fog Heen]

]] Charles Plessy 

| 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.

I think it's about having some reasonable level of maintenance, and it's
about holding DDs to the same (or a similar) standard as we hold other
maintainers.  Orphaning packages is a way of getting somebody to pick
them up and give them the necessary attention, it's not a way of
punishing the maintainer.  As for kicking people out, I don't think that
has been suggested by anyone and as we have seen in other cases, it's
not something to be done lightly.

| 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.

There was at least one person who helped out quite a bit with
nfs-common, but got tired of co-maintaining as it was a continous uphill
struggle where the maintainer quite often broke stuff and didn't
coordinate.  Maybe he could have hijacked it and gotten away with it,
but he didn't do that.  So while this approach might work in some cases,
it's not a sure recipe for success.

I'd rather not have this discussion be about a specific maintainer.  I
think this is a systemic problem where we are bad at discovering when
maintainers don't really maintain their packages that well any longer,
be it because they have lost interest, are overworked or something
else.  What can we do to prevent this and when it happens, fix it?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What to do about negligent maintainers?

[Mark Brown]

On Thu, Jan 07, 2010 at 09:59:24PM +0100, Leo costela Antunes wrote:

> What about adding some informal rule like this to dev-ref (or wherever):
> after n unacknowledged NMUs the package may be taken over without it
> being considered a "hostile takeover", more like "updating to reflect
> the de-facto maintainer".

The trouble with an approach like that is that it doesn't provide a
clear route to dealing with situations where the maintainer is
occasionally active but not managing to keep up with things well enough
to do a good job.  It's also trying to come up with a quantative rule to
deal with what is essentially a social problem which is generally
problematic.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What to do about negligent maintainers?

[Marco d'Itri]

tfh...@err.no wrote:

>I am not sure what we should do with problems like this. Not doing
If you care about the package or even just need it to be fixed, do
what I did with linux-atm:
* ask the maintainer if he needs help
* ask again
* warn that you will NMU
* NMU to DELAYED fixing the most urgent and/or simpler bugs
* keep doing uploads to fix other bugs
* eventually hijack the package, if you want

(Somewhat related: I am still looking for help with ppp, I have an
updated package ready but the BTS page scares me...)

-- 
ciao,
Marco


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What to do about negligent maintainers?

[Kevin Mark]

On Thu, Jan 07, 2010 at 05:02:07PM -0800, Russ Allbery wrote:
> Charles Plessy  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.

example:

Package: foobar
Maintainer: j...@foobar.net
co-maintainers: j...@bill.org
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

-k

-- 
|  .''`.  == 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 _|


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What to do about negligent maintainers?

[Russ Allbery]

Charles Plessy  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.)

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What to do about negligent maintainers?

[Charles Plessy]

Le Thu, Jan 07, 2010 at 08:44:49PM +0100, Tollef Fog Heen a écrit :
> 
> Hi all,
> 
> it seems we have some maintainers not maintaining their packages
> properly, letting both RC and non-RC bugs pile up.  The last example
> which has been discussed extensively on #debian-devel is anibal.  His
> list of packages maintained include core packages like: nfs-common,
> portmap and libpng as well as less core, but widely used packages like
> fping, libx86 and gparted.

Hi Tollef,

I think that the proper way is to either propose to transfer the responsability
of neglected packages to one or – preferrentially – more new maintainers who
volunteer to take the responsibility for the package in the long term, or to
file a request for removal when possible. If the current maintainer does not
agree, then the TC can take the final decision.

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.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What to do about negligent maintainers?

[Leo "costela" Antunes]

Tollef Fog Heen wrote:
> I am not sure what we should do with problems like this. Not doing
> anything sends a signal that DDs are held to a different standard than
> DMs and NMs.  I don't think that is a signal we should send.

Agreed. At least in terms of packaging expectations, DDs' should be
equal to DMs'.

> Ideally, we should be able to ask the maintainer to scale back and they
> do so.  However, what should we do if they either don't respond or
> disagree?  The TC can already rule over maintainership so perhaps that
> is enough and we don't need any more procedures or rules to handle those
> cases?

What about adding some informal rule like this to dev-ref (or wherever):
after n unacknowledged NMUs the package may be taken over without it
being considered a "hostile takeover", more like "updating to reflect
the de-facto maintainer".
The new maintainer would in turn be free to RFA the package, request
removal, team-maintain it or whatever.

This would have the benefit of requiring some work from complainers and
making it look less like idle finger-pointing, possibly reducing the
social friction that happens anytime someone complains about someone
else's work, regardless of the complaint's merits.

Asking for TC intervention is also an option, but it's IMHO a bit
extreme. Though I still find it better than the other proposed
alternatives (DAM intervention, GR, whatever).


Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org