Re: `Every package must have exactly one maintainer'
Manoj Srivastava wrote:
> >>"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.
>
[snip]
>
> 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).
As a participating member of one of the packages, I would contend this. In
fact that is the same as saying that there is no way for the linux kernel to
be bug free because there are so many people responsible that they will never
do anything if a bug is found.
> 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.
My feeling is that the complexity is so great that the multi maintainership
developed in order to move forward. No single individual has shown to have time
to maintain such a package for long enough. People got involved, at least
in the boot-floppies where I have first hand experience, in order to have
things implemented that weren't there and would never be there because it was
too much for the maintainer. The fact is that things that don't get solved
are many times unsolved because there is not enough time. Reducing the number
of people involved is IMHO the wrong way to address the problem.
[snip]
> Also, with only one maintainer, I think there is more
> likelihood of there being NMUs, since it is easier to establish that
> the real maintainer is gone/busy.
Sorry but that is not true. In our case, uploads are done by whoever happens
to be able to do it. We mail each other and decide when changes warrant
releases. If there is really something that you want to solve, you can just
join us. People have done so successfully.
> I am not wildly gaainst the idea of multiple maintainers. I do
> think we need to discuss the cons too.
I don't mind the idea of having some name in the "Maintainer" field but my
experience is that people use the name to email directly rather than emailing
the name_of_package@packages.debian.org for some reason. (Probably because
there is something in our psychology that favours the "name" above the
package. In our case, though, this forces people to forward the message to the
rest of the group. Sometimes you forget, not everybody gets all info and it
ends up being *far* more difficult to solve the problems because nobody has
all the information. Getting rid of one single name in that field would
probably force people to use the packages.debian.org address which is better.
Luis.
--
Luis Francisco Gonzalez <luisgh@cogs.susx.ac.uk>
PGP Fingerprint = F8 B1 13 DE 22 22 94 A1 14 BE 95 8E 49 39 78 76
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: