Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Michael Gilbert <mgilbert@debian.org> writes:
> Don't we expect the same adaptability of anyone trying to become a
> co-maintainer of any other package?
No, because in the typical comaintenance situation, the other maintainers
will teach the newcomer how to package according to the team standards,
rather than having them have to reverse-engineer the intention behind the
packaging setup. With an effectively orphaned package, that's unlikely;
usually the current maintainer doesn't have the time to do anything as
time-intensive as mentoring or training. It's way easier, in general, to
maintain the package yourself than to teach someone else how to do it, so
if they don't have time to maintain the package, they're almost certainly
not going to be able to teach someone else.
> Once someone has jumped all the hurdles to become a DD, at that point,
> aren't they expected to be of sufficient caliber and skill to be able to
> learn quickly and apply themselves to hard(er) problems?
That's not, for me, the point.
One of the problems people are concerned with when looking at the overall
quality of the Debian archive, and on our releasability, is that we tend
to keep adding new packages without taking good care of the ones already
in the archive. I think this is one of the main motivations for the
persistant discussions of finding a better way to deal with effectively
orphaned packages. Frequently, people will ask or hope for new
contributors to start by fixing a package already in the archive rather
than adding yet another new package to the archive, or at least do some
combination of both.
I think orphaned packages are one of our best opportunities to attract new
developers, rather than serving as an additional obligation for existing
developers. If the package is fully orphaned, then the new maintainer
doesn't have to try to fit in with an existing packaging style without
help and explanation, and can experiment (which is how people learn). A
lot of orphaned or poorly-maintained packages aren't horribly important,
so the new maintainer doesn't have to worry about breaking something
vital, but they still have existing work to start from and don't have the
intimidating problem of starting from scratch. And often they have a
personal incentive for fixing that package; perhaps it's a relatively
obscure piece of software they personally use, and they were drawn to
contribute to Debian because they wanted to make it better.
Adopting orphaned packages was one of the ways I personally got started in
Debian.
But to take full advantage of that opportunity, we need to do two things.
First, we need to officially orphan packages that are effectively orphaned
but don't officially have that status. New contributors are unlikely to
want to do that, since they don't want to insult the existing developer
and they don't have any social capital and will be worried about starting
a confrontation. I think that's where a new orphaning process could fit
in; existing Debian developers who have the social capital to be able to
tell another developer "no, really, you're not maintaining your package,
let someone else take a crack at it" can get the package into a state
where a newcomer feels safe in taking it over.
And, secondly, the package needs to be in a status where the new developer
can experiment and learn. While one *can* learn a lot by fitting within
the framework that's already in place, I think that's a learning path best
done as part of an active maintenance team so that one has mentors and
assistance. Orphaned packages can provide a great source of material for
one's personal experimentation as one learns how to package because one
can make as large or small of changes to the packaging as one wants to
attempt and then see how well the results work without breaking any team
rules or getting in anyone else's way, but also without having to
introduce yet another new package into the archive.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: