Michael Gilbert <mgilb...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pq46neie....@windlord.stanford.edu