Sven Mueller <sven@incase.de> writes: > I know this is an old thread, but as far as I can tell, it's still an > issue. (At least I've been waiting for FD approval for over two months now.) Well, it seems like I'm the only FD member reading AM reports at the moment. As my free time is limited, I try to do stuff that urgently needs to be done first. FD approval is *not* urgent, as all people I approve are then moved to the DAM queue ... where they wait again. There's no difference if you wait in my or in Joerg's queue. As soon as the DAM queue is shorter (<10 people), I'll check the reports that are still waiting for approval. >> A possible solution I see is, instead of assigning one AM per applicant, >> all AM's are made a part of a committee to handle applicants. > > I don't think this would work. However, it would be nice if AMs could > choose to pass on handling of an applicant to some other possible AM. They can do that, but the overhead of such a switch is relatively big (as the new AM needs to see what the old AM did), so this is not an often used option. > IMHO, this could be improved if the DAM (or even FD) wouldn't need to > review the complete application, but could simply check how many AMs > reviewed an application and signed it. Right, because AMs have tons of free time and just WAIT for us to throw more work at them. Sorry, I understand your irritation because it looks like your process isn't moving forward, but OTOH, you have to understand that there's no simple solution for the existing problems. Debian generally suffers under the fact that people have no fixed amount of free time and unexpected events often suck up every free minute. This means that work shouldn't be distributed in big chunks, but in smaller units. On the other hand, things like new maintainer applications should be handled in a way that ensures that one (or more) person has a complete picture of someone's work, as the implications of a membership (access to project machines, full upload rights to unstable, voting rights) lead to severe security implications. Marc -- BOFH #182: endothermal recalibration
Attachment:
pgpqiuUZLtrnq.pgp
Description: PGP signature