One of the problems that QA often face is making sure that there are maintainers for packages; this is easier said than done, because just having someone to bump the packages or look at the bugs most of the times is not enough; you need somebody who run the code, and makes sure it behaves as intended.
Indeed, especially given the bad track that testsuites have the (unfortunately common) “it compiles, ship it!” paradigm is a very bad one to follow for what concerns quality. Even if the testsuite might take care of ensuring the basic functionality of the software is good, it doesn’t help to know whether the integration of the code is correct.
This gets even hairier when the packages interact with many other components, such as network systems, hardware, or third-party software (which is the case both for code generation and most libraries). The testing we apply in ebuilds cover just a fraction of all those cases, and you can see how bad that can be with libpng or berkdb both of which lately have caused quite a stir, one for all users, and the other just for the tinderbox, luckily. And neither actually relied on having and using special hardware!
Now, in this case, often enough, you end up having the packages being maintained directly by one person, that either has the hardware, or knows how to handle the package, by making use of the library, generator, service, or whatever the heck the package needs to have. This is good from one side because bothering a team with a package that requires specific hardware is not going to be any helpful, but on the other hand introduces a single point of failure: if the maintainer is not available, you get stuck with a package that cannot be tested, and thus properly maintained. And sometimes, that’s not strictly necessary.
Unfortunately, we get somewhat “possesive” and territorial on our packages, many many times, and the result is that most packages have at most one maintainer, or one maintainer and a proxy. I have, as of late, instead decided to make it more viable to have multiple maintainers, two, or even three or four, for the same package. This is not really helped by bugzilla only allowing a single assignee, but it can still work out, somehow.
Two examples here are two packages I co-maintain with Luca because of LScube – dev-util/ragel and net-misc/lksctp-tools – the former (which is actually quite used in Ruby-based packages, now that we rebuild them properly) is a state machine generator, and its testsuite is unusable because it needs software we don’t have in Portage (and that is unlikely we’ll ever have, given that it’s not proper FLOSS); the latter is the userland package for the SCTP protocol implementation in the Linux kernel, which we support as part of feng and libnemesi (and, hopefully, FFmpeg very soon).
We use our own code to make sure that these two work as intended, it might not be covering all of the possible problems, but it sure as the dependency hell that we can do a more thorough work than just randomly bumping the packages. It doesn’t make sense for either of us to be territorial about the packages, given that we work together on the same code, we can do almost the identical tests on it, so the solution for both is sharing the maintainership.
Another package I am listed as co-maintainer in is hplip: I have the hardware, so I can check whether it works, on the other hand, I don’t use all of it (I only use the scanner function of the all-in-one: the printer sucks for the most part, and I haven’t really needed to print something in full colour in a long time now — if I do need something printed in colour, I just call my print shop up). So I’m listed there among the maintainers, but I only do limited work, on the other hand, I’m “on hold” if something comes up and nobody else can take care of it.
Don’t be scared to share a package! Think of it like car-pooling or sleeping with a friend in the same bed if you’re on vacation. It’s fun, and the more the merrier.
I can relate to what you say about developers having their own pet projects. I know for sure that it applies to the original developers of any given package, and it makes sense that it applies also to the developers who make a package work with a distribution.What makes this problem worse for Gentoo is that there seems to be no infrastructure for multiple developers to share the burden for maintaining a package (or, better still, a pool of packages). Sure, there are herds which handle some things; they communicate, so far as I can tell, with messaging services like IRC. I don’t know about you, but I find IRC to be intensely dissatisfying–especially when it comes to retaining information.What is needed, at the minimum, is a wiki where developers can update their shared knowledge about the packages they maintain. This would not only help the developers be able better to understand what the other developers did, but it also would make it easier for other developers to join in! The documentation could also contain information from the testers. Features like a Git repository and a bug tracker would be nice, but the setting up the shared knowledgebase would be the indispensible first step.It may be that I am discussing something like Alioth. I don’t know much of the workings of Debian except that they pull boneheaded stunts like zeroing out the block of newly allocated memory that OpenSSH used as part of its random seed. (I’m not going to throw stones too hard–after all, anyone can pull a boneheaded stunt.) They describe Alioth as a “Sourceforge for Debian”. If that’s the case, I think the vital missing feature is a much stronger emphasis on developer documentation than is typical on Sourceforge. (Also, any downloads it offers should be only for documentation and files related to development and testing.) This setup would work best if it encourages multiple developers to take an interest in multiple projects.All in all, I think this would help us ease into shared maintenance of packages.