On 4/24/07, Dan McGee wrote:

First, let's get a few numbers out there. Sizes of official repos: current: 563 extra: 2019 community: 1196

Number of "maintainers": Devs: 27 TUs: 25

The second set of numbers is harder to pin down. For devs, I took the number from the devs page; someone who has been here longer could better state the breakdown between architectures or between active and passive. For TU's, I grabbed it from the AUR front page, once again not knowing how many are active.

Given the above numbers, and this repeats what has been stated elsewhere by Alexander, devs have roughly 95 packages each ((563+2019)/27) to maintain if the load was distributed evently. Because we know it is not, Alexander came up with a figure of 16 active maintainers, giving each dev 156 packages. Thats a lot, and it leaves very little room or time for devs to do anything besides package maintenance.

Compare this to the TUs workload. Each TU should have roughly 48 packages to maintain, a much more reasonable number and either 1/2 or 1/3 of what a dev is expected to do. This also gives them some time to patrol the AUR and check packages that haven't made it into community.

Two proposals to let sit in the pot: 1. Downsize extra to a more reasonable size, and move some of the maintenance to TU's by shifting packages to community. This would likely require a few more TUs being "hired on". 2. Redefine what it means to be a dev. Have a three-tiered system of sorts, with increases in permissions to change things as you move up the ladder. This would basically stick another group between Devs and TUs that could help maintain the huge number of packages we have in extra. This would likely require a few more TUs being hired and some TUs shifted to higher levels of responsibility.

Yes, radical ideas, but don't shoot me for them. Comments appreciated.

Not really that radical, I think something similar has come up a few times. I like the multi-tiered approach. Perhaps this fits into what alex proposed: that is, TU -> "division member" -> "division lead".

Roman Kyrylych wrote:

I'd like to see some TUs promoted to dev level. Regardless, more TUs are good too.

My thoughts exactly. We have many capable people so nearby. I would love to see a list of nominations here. A handful of people would be enough but it would be very nice if somebody can filter it a bit so that we don't get that handful with people that would all only like to take over KDE or something. :) Cheers, -H

<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