Re: Attempted summary and thoughts
On Tue, Mar 27, 2007 at 06:43:03PM -0700, Russ Allbery wrote:
> Don Armstrong <email@example.com> writes:
> > On Wed, 28 Mar 2007, Charles Plessy wrote:
> >> The maintainer is not MIA, but does not actively develop anymore.
> > Packages like this should have a message to the current maintainer with
> > a proposal to co-maintain or orphan+adopt followed by an ITH (intent to
> > hijack) if there is no response within a reasonable period of time.
> > If no one is interested in stepping forward to do this and deal with the
> > package, then the status quo is the best that can be done. While it is
> > suboptimal, it's the best we can do until someone wants to take over.
> So, here's a possibly weird proposal.
> What if we had some mechanism whereby people could indicate interest in
> maintaining a package should anything happen to the current maintainer?
> Have it be as non-confrontational as possible by having it not indicate
> any feeling about whether the package is currently maintained well, just a
> willingness to help should the current maintainer be unable to continue
> for some reason.
I don't think this will work. Why not? Because I don't think we'll ever
get anywhere near adequate 'subscriptions' of showed interest. But well,
that's my projection, we won't know for sure without actually trying. It
is a huge task to undertake though, and requires a lot of time from
anyone potentially interested to what packages one is interested in,
while in 99% of the cases, nothing will get done with that information
-- and then it'll also run stale.
I also think you'll see that for example the cool sounding package names
like standard and higher priority ones, will get quite some interest
from relatively new or prospective developers, while in practice, if
such a package would get orphaned, someone who would be a pretty good
adopter would not have listed himself at that moment. To just take a
totally random example, if such a system would have existed, would Kurt
Roeckx have listed himself as 'interested in libtool' before it got
orphaned? It took a while, but he did in the end adopt it.
To address the original question, I don't believe any potential adoption
will be 'urgent' from one day to the other. For urgent fixes, one can
NMU, who's the maintainer is something that IMHO requires a bit more
care. I can't come up with a single example when it'd really be
essential that a package gets adopted within 2 weeks. So, I think the
best way forward (and the way it happens a lot), is that if someone or
some team of people feel they'd be better at maintainer a certain
package than it currently is, one can politely mail the maintainer about
cooperation or possibly even adoption. I think in the majority of cases
you'll find that this works just fine.
Where it doesn't, in the case of unresponsive or totally overworked
maintainers, the mia team can be of assistance. Such stuff cannot really
be dealt with properly in an automated fasion anyway. I think it'd make
most sense to enlarge the MIA team a bit and possible rename it.
"Matchmaking In Action" (matching between packages and maintainers)? In
any case, take the task of the team a bit broader than it currently is
(it already does its share of beyond-true-mianess action), but for that
to work out, its task would need to be a bit better defined. Perhaps the
team could also do with some medium amount of official power in terms of
giving over maintainance, although the status quo works reasonably well
so far -- and there's the tech-ctte who could rule in cases where it
doesn't work out. In practice, when the MIA team decided to orphan
certain packages, that decision gets respected, with only one exception
I can recollect. But again, in the majority of cases, some solution can
be found in constructive talks, and that's preferable anyway.
The cases where there's really some good candidate to take over and the
maintainer is not willing to let go of maintainership are pretty rare
as far as I can see. I think it's a better expenditure of overall time
to only really 'mediate' where that's really required.
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)