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

[Alexander Baldeck]

<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