We have about 250 maintainers and more than 1200 source packages. Both
numbers are increasing at a very high speed, i.e., the project is growing
very fast. Everyone who has some knowledge about how large `organizations'
work will agree that a continuous growth of any organization is very
dangerous for it.
One necessary (but not sufficient) condition to make that growth possible
is that the structure of the organization is scalable.
Currently, the structure of our organization looks like this: We have 250
maintainers who all maintain some packages and we have a few single people
who are doing the `coordination.' This works very well as long as any
changes can be implemented by a single maintainer. If more than one
maintainer is required, things get much more complicated and very
time-consuming.
Just take the `Debian Kbd Configuration Project' as one good example. The
goal of the project is to have all packages interpret keyboard events in
the same `consistent' way. But this affects a lot of packages (which are
maintained by different people) and changing only a single package at a
time will break a lot of other packages. The project didn't had any
results yet.
So, the current situation doesn't look too good. With every new
announcement of new maintainers from the new-maintainer folks and with
every new package added to the archive the problem is getting bigger.
Note, that the problem is definitely not the individual maintainer or any
package (newbies are always welcomed, the maintainers do an excellent job
so far, and sometimes new packages are very important). The problem is the
lack of management.
If we continue to have new maintainers joining the project at the same
rate as now and if we continue to add new packages that fast without
improving our organizational structure, we'll end up with an unmanageable
organization where any important and necessary changes will be impossible.
This will have an high impact on the (currently high) quality of our
distribution.
So in the current situation, it's extremely important that we always know
a) which package is maintained by which developer, b) how to contact this
maintainer, and c) the maintain has to know that he/she is responsible for
`maintaining' the package. If this is provided, we can start to discuss
how to set up the next `layer' of management.
Now, by allowing one package having several maintainers the requirements
listed above get more difficult to meet. For these reasons, any new
`Maintainer:' field policy has to meet the following requirements:
1. The `Maintainer:' field must list the actual name of the maintainer.
This makes it easy for us to know who takes care of what packages and the
maintainers will know which packages they are expected to maintain. This
information is very important and must not be `hidden' in some other
place.
2. The `Maintainer:' field must always contain a working email address.
Any mail sent to that address must be delivered to the maintainer.
3. If more than one developer is working on a package for some time (BTW,
I doubt that we ever had this stituation in the past), then one of these
developers has to `coordinate' all changes done to that package. This
person has to be clearly marked as `coordinator' at some place, for
example in the `Maintainer:' field. The email address could then refer to
some mail alias, all mail sent to which will be forwarded to the different
maintainers.
Thanks,
Chris
-- Christian Schwarz
[EMAIL PROTECTED], [EMAIL PROTECTED]
[EMAIL PROTECTED], [EMAIL PROTECTED]
PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA
CS Software goes online! Visit our new home page at
http://www.schwarz-online.com
