On Thu, 16 Apr 1998, Joey Hess wrote:
> Christian Schwarz wrote:
> > Note, that the Linux kernel is developed by the same procedure: A lot of
> > programmers contribute source code, but everything is integrated by a
> > single person (Linus). The same holds for Emacs--and probably for most
> > other packages too.
> >
> > The reason why I object to the `multi-maintainer' idea is my experience
> > with software development: I haven't seen a _working_ example of a
> > software program yet, which had multiple _release integrators_ (that's
> > what I think the `Maintainer:'s job is) at the same time. If someone would
> > show me a good example for this, maybe I'd change my mind.
>
> Apache. It has a core group of maintainers, all equal.
Very intresting! I've just read the documentation that comes with the
apache package--but they don't say much how the do release integration,
it's just mentioned that the full core team has write permissions to the
CVS archive (and according to the changelog, they seem to use these
permissions!).
But let's get back to our discussion:
> My feeling on this is, yes, a single maintainer seems to work best, as in
> the linux kernel model. But why do we have to enforce this in policy?
> Developers should be free to set up any organization they want to maintain
> their packages, as long as it gets the job done.
It has to be mentioned in policy because it does affect the quality of our
distribution. There are a lot of topics which can be decided by the
individual maintainer--but there are also a few decisions which we can't
leave up for the maintainer. If everyone would know which decision would
be best for the distribution as a whole, we wouldn't need policy!
The loss of quality we'd get from relaxing policy in this respect, is
because of the `diluted responsibility' this would cause. From the
viewpoint of QA, two things are extremely important:
a) the `organization' (project) as a whole knows who is working on what
part, and
b) the individual developer (maintainer) knows for which parts he's
responsible.
If we'd lose either part, we'd end up with packages for which noone feels
responsible--but noone will notice that situation.
Let us consider our popular example (it's the only example we have): dpkg.
The Maintainer field reads
Maintainer: Klee Dienes and Ian Jackson
<[EMAIL PROTECTED]>
According to the packages changelog file, the following people worked on
the package in the last 6 months (the names don't really matter
here--what's important is that this set is distinct from Maintainer set):
Michael, Miquel, Juan
(and I've heard that Guy is also working on dpkg now.)
In summary, the Maintainer: field does not represent reality anymore. This
might not be a great problem in case of dpkg, because dpkg is so important
that a lot of people are carefully watching its status, but it might be a
big problem if several less `popular' packages would run into the same
situation.
And we have to be very careful with quality: Debian is growing at a high
speed. AFAIR, the numbers of developers and packages have both DOUBLED in
the last 12 months. With that, we'd have about 600 maintainers and 4000
packages in one year! I'm sure we can't preserve our (currently very high)
quality with such a big distribution!
BTW, I'm still wondering what advantages the people see in
multi-maintainer packages. Note again, that we are talking about
`maintenance' of a package, not software development or something like
that! Being a maintainer means:
1. being able to make decision about the package (provided that the
decisions comply with policy)
2. being listed as person of contact for the package (through the
Maintainer field)
3. having full power over bug reports on the package
Are there any packages where people would like to give the above
privileges into the hands of several developers?
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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
