2007/4/24, Dan McGee <dpmcgee@gmail.com>:
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.
Some devs listed on that page officially resigned some time ago. Same for TUs (see recent thread in tur-users ML about TU activity).
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.
IIRC sergej maintains >500 packages both in community and unsupported I have ~75 in community and ~15 in unsupported. Also note that some of TUs are devs too and they usually have small collection of maintained packages in AUR. What I'm saying here is that both devs and TUs don't have even roughly equal number of packages each :(
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.
I'd like to see some TUs promoted to dev level. Regardless, more TUs are good too. -- Roman Kyrylych (Роман Кирилич)