Re: `Every package must have exactly one maintainer'
Hi,
>>"JJ" == JJ TROUP <J.J.Troup@scm.brad.ac.uk> writes:
JJ> This is about a point of communication, and I've provided at least
JJ> 3 examples where communication is improved because there is not
JJ> one primary maintainer who is the point of communication.
I think there are certain tasks that do indeed benefit from
multiple people (new maintainers, admin for master, debian keyring,
et al). These usually involve separate tasks, undertaken by who ever
is free, and works quite well.
A package is a different ball game. I do think a board or
committee fairs rather badly in these things; they are done
better by a committed single person.
I am not yet convinced either way on this subject; I do think
that you are under-estimating crowd psychology: there was a test
conducted with te response of people as individuals and as part of a
group: Both the test cases involved test subjects waiting in an
office, alone, or with other people.
They heard sounds of a fall behind an office doorm and
evidently a cry of pain.
Most people waiting alone rushed forward with offers of help,
(81% _did_ something). When a part of a group, people waited and
looked around, for someone to do something. Only 26% of the people
actually did anything.
I do not know how appropriate this is to multi-peson
maintainership. I do think that ot would have an effect (dilution of
responsibility may mean less accountability, and less action being
taken).
JJ> Only if the multi-maintainerness of it has anything to do with
JJ> it's state. Otherwise you're scape-goating multi-maintainership.
We do not know one way or the other for sure. I do have my
doubts, and these trial cases are something I would not dismiss are
irtreevant.
JJ> Also are we ready to ban multi-maintainerness on the state of one
JJ> package? Ignoring where it works, ignoring the complexities and
JJ> nature of the package involved?
Nope. But we do have to consider the increased strains of
sharing responsibility at the same time as we look at the benefits.
JJ> But by your own admission there is no proof of a link.
Yes, but there are pointer. Where ther is smoke, there may
well be a fire.
JJ> Ad hominem's from the man who scorns them so much. Interesting.
I agree. That was a cheap shot, and I apologize. However, the
point is, that each level of backup reduces the possibility of down
time, and, ultimately, reaches a point where the costs over run the
diminishing returns.
I think a busy backup maintainer problem shall also occur as a
busy co-maintianer problem, and as far as redundancy is concerned,
multiple real maintainers is as good/bad a solution as multiple
backup maintainers.
Also, with only one maintainer, I think there is more
likelyhood of there being NMUs, since it is easier to establish that
the real maintainer is gone/busy.
I am not wildly gaainst the idea of multiple maintainers. I do
think we need to discuss the cons too.
manoj
--
Suppose for a moment that the automobile industry had developed at
the same rate as computers and over the same period: how much cheaper
and more efficient would the current models be? If you have not
already heard the analogy, the answer is shattering. Today you would
be able to buy a Rolls-Royce for $2.75, it would do three million
miles to the gallon, and it would deliver enough power to drive the
Queen Elizabeth II. And if you were interested in miniaturization,
you could place half a dozen of them on a pinhead. Christopher Evans
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: