[arch-dev-public] Sizes of repos and maintainers

[Aaron Griffin]

On 4/24/07, Dan McGee <dpmcgee at gmail.com> 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".