Re: `Every package must have exactly one maintainer'
Re>k> <[🔎] 87af9qhiia.fsf@tiamat.datasync.com>
Mail-Copies-To: never
From: James Troup <jjtroup@comp.brad.ac.uk>
Date: 12 Apr 1998 22:17:30 +0100
In-Reply-To: Manoj Srivastava's message of "12 Apr 1998 15:50:21 -0500"
Message-ID: <dmmsonikadx.fsf@dcsun4.comp.brad.ac.uk>
Lines: 117
X-Mailer: Gnus v5.6.2/Emacs 19.34
Manoj Srivastava <srivasta@datasync.com> writes [supercite undone]:
> Hi,
> > Christian Schwarz <schwarz@monet.m.isar.de> writes:
>
> >> 4. A unique point of communication. In case of questions WRT a
> >> packages' `interface', it's much easier for other maintainers to
> >> get an `authoritative' answer if you have one person to contact.
>
> > You continually bring up this hideously bogus argument.
>
> I would find it easier to believe this argument is specious if
> there were at least one positive example.
This is about a point of communication, and I've provided at least 3
examples where communication is improved because there is not one
primary maintainer who is the point of communication.
> > What's the difference between maintaining a package and
> > processing new maintainer requests when it comes to the
^^^^^^^^^^^^^^^^^^^^
> > benefits and problems of multiple maintainers?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> I find there is a modicum of design and innovation required for my
> packages. I do not believe in the cookie cutter approach to software
> packaging. Therein lies the difference.
How is that relevant to the benefits and problems of multiple
maintainers?
> > It comes down to this: there are currently two packages in the
> > distribution which are maintainer by multiple maintainers: dpkg
> > and boot-floppies. There will soon be a third (debian-keyring).
> > You were and are wrong about boot-floppies (IMO), and *no one* has
> > even begun to prove that dpkg's is in the state it's in because it
> > has multiple maintainers. Yes, dpkg's maintenance
> > \begin{litotes}isn't great\end{litotes} but you are scape-goating
> > multiple maintainers by blaming it on that. Please show me some
> > evidence that had dpkg continued to be maintained by Ian alone, it
> > would be in better shape now than it currently is.
>
> Please show me on working multi-maintainer package.
boot-floppies. And I think debian-keyring will be to.
> Having the only multi-maintiner package being in an untenable
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[Some facts would be nice.]
> state is a black mark.
Only if the multi-maintainerness of it has anything to do with it's
state. Otherwise you're scape-goating multi-maintainership.
Also are we ready to ban multi-maintainerness on the state of one
package? Ignoring where it works, ignoring the complexities and
nature of the package involved?
> Though there is no proof that they are in state because of having
> multiple maintainers, multiple maintainer packages do have a bad
^
[Or maybe some consistency]
> track record.
But by your own admission there is no proof of a link.
> Maintianing a keyring or inducting new maintainers is not the same
> as maintaing a package or writing software.
I didn't for a minute claim it was.
> >> > > 2. Having only one person listed in the "Maintainer:" field
> >> does not mean that only one person works on a package! It only
> >> means, that there is a unique person who coordinates all changes.
> >> >
> >> > So if that person gets busy no changes can be coordinated... baz
> >> bat bamus batis bant.
> >>
> >> In which case we could define a `Backup-Maintainer'.
>
> > And if he's busy? Sorry, but your arguments are circular and
> > bogus.
>
> Really? Backups are bogus cause the backup tapes can be corrupt too?
No, that's an inappropriate analogy.
> Do you really work in the information systems field?
Ad hominem's from the man who scorns them so much. Interesting.
> > If there is a single person responsible for coordinating
> > changes he becomes the critical link in the chain, if he
> > becomes busy, nothing happens. If you define a backup, it only
> > takes the primary and the backup to become busy before again
> > output stops. What next? Make a Backup-Backup-Maintainer:?
>
> > With multiple maintainers there is no critical link in the
> > chain, anyone person can step forward to take up the slack.
> > Output stops only when all maintainers are busy, this is no
> > loss over single maintainership or single person responsible
> > for coordinating changes.
>
> You are overlooking basic human psychology: when a crowd is
> responsible for something, nobody is responsible for it.
Not in my experience. I've seen shared responsibility and I've seen
it work, with pgp-update, new-maintainer and boot-floppies. And
that's just what I've been personally involved in (albeit to a very
marginal degree in some of them).
--
James
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: