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.