<ATTENTION> Very long read! </ATTENTION> For the purpose of completeness I would like to also post my initial suggested I posted on arch-dev here as well. This is by no means complete, it's a very rough draft with sharp edges here and there. It should take us another while on arch-dev to come up with a document that is ready for implementation. So again, discussion is already happening on arch-dev and will go on there for some more time. Here goes: ==================================================================== Ok, I basicly combine a few old ideas with a bit of spice of my own. (ATTENTION: long!) Here goes: == Package Maintainance issues == === Problem === Too few developers do most of the work and are overloaded. === Solution === Draw in new maintainers. === How? === We talked about division a while back. I would love to pick that idea up again but in a different aspect. My idea is to split the repos into chunks that either: * are an entity like GNOME, KDE, Java-runtime etc. of * are in the same subsection on CVS like extra/multimedia or current/base For each of these chunks there should be one person responsible. Meaning that this developer takes responsibility for all packages not only for maintaining them but also finding help in form of maintainers. They're more like the leader or a package maintainer division then they are package maintainers themselves. They also should watch the bugtracker and direct tasks directly. Plus, let me explain what I had in mind regarding restructoring our work process. For example, we have the following CVS layout: current/base/db current/daemons/apache current/devel/php current/lib/libldap current/network/openldap-clients extra/gnome That means, we have one division that watches over current, plus one subdivision for each base, daemons, devel, lib & network that keep them consistent. Then we have the actual package maintainers for apache, php a.s.o. The order of priority of divisions would look like: Current -> base -> daemons -> devel -> lib -> network -> Extra -> gnome Notice as how extra becomes a subdivision of Current and gnome has the lowest priority. What do I mean? Obviously the Current & Extra divisions watch over the whole repo and its integrity. base, daemons a.s.o normally take orders from Current or Extra but have a veto. What's a veto? Example: Current decides to update base/db and directs work to the base division plus letting all others know it's been scheduled to be modified. base/db maintainer pushes a package to testing and base division goes checking their stuff. When they are OK, release to staging and the rest of the world may rebuild. If for example daemons/apache maintainer screams, as part of a division he has a veto to prevent the base/db maintainer from pushing his package down into Current. ==== Long story short ==== The Current and Extra divisions would be the quality control instrument for Arch. It'll schedule or hold back changes as they are suggested. Which choice it makes in a particular case depends on kind of a voting mechanism. This creates some extra work but should level up quality by a significant account. ===== So what's that all to do with lack of manpower? It sounds worse than before! ===== Well, easy. We split up the recruiting task to the people in particular divisions. That way we don't have to look for a super genius work horse but rather a highly skilled autist knowing that particular piece of software, who in fact is way easier to find I think. While we don't have those people, everything will stay as it is with a little more control over what happens. Right now nobody has a detailed overview of the whole thing, which will hopefully change with this way. == Inactivity issues == === Problem === We have a couple of developers that done have time to spend on Arch leaving their packages outdated or buggy for a long time until somebody else upgrades/fixes them. === Solution === Generate a list of owned outdated/buggy packages to the arch-dev-public ML in a semi-weekly interval. === Why? === People that care for these packages, may take over a temporary maintainership *IF* they properly fix them back together. If yet another week passes by with no word from the maintainer to the temporary one, the package is disowned and the temporary maintainers becomes a regular maintainer. If nobody cares at all for that month, packages should be collected again, orphaned & another mail should go to the arch-dev-public. Then either the package division find somebody new or the package wanders off to community if not absolutely necessary for current/extra. In the regular case the division should pick it up if nobody can be found only when something else depends on that specific package. I hope I was able to make sense. If you have any questions, of course I will be happy to answer them. ;) Cheers, -k