Re: `Every package must have exactly one maintainer'
Hi,
>>"James" == James Troup <J.J.Troup@scm.brad.ac.uk> writes:
James> Christian Schwarz <schwarz@monet.m.isar.de> writes:
>> Note, that we are talking about `package maintenance', not other
>> developer's duties. Facts are different if we talk about
>> `webmasters,' `listmasters', etc.--this is not what this discussion
>> is about.
James> What's the difference between maintaining a package and
James> processing new maintainer requests when it comes to the
James> 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.
James> It comes down to this: there are currently two packages in the
James> distribution which are maintainer by multiple maintainers: dpkg
James> and boot-floppies. There will soon be a third
James> (debian-keyring). You were and are wrong about boot-floppies
James> (IMO), and *no one* has even begun to prove that dpkg's is in
James> the state it's in because it has multiple maintainers. Yes,
James> dpkg's maintenance \begin{litotes}isn't great\end{litotes} but
James> you are scape-goating multiple maintainers by blaming it on
James> that. Please show me some evidence that had dpkg continued to
James> be maintained by Ian alone, it would be in better shape now
James> than it currently is.
Please show me on working multi-maintainer package. Not a
shared task like new maintainer handling or the admin duties, just
one package.
Having the only multi-maintiner package being in an untenable
state is a black mark. Though there is no proof that they are in
state because of having multiple maintainers, multiple maintainer
packages do have a bad track record.
Maintianing a keyring or inducting new maintainers is not the
same as maintaing a package or writing software.
>> > > 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'.
James> And if he's busy? Sorry, but your arguments are circular and
James> bogus.
Really? Backups are bogus cause the backup tapes can be
corrupt too? Do you really work in the information systems field?
James> If there is a single person responsible for coordinating
James> changes he becomes the critical link in the chain, if he
James> becomes busy, nothing happens. If you define a backup, it only
James> takes the primary and the backup to become busy before again
James> output stops. What next? Make a Backup-Backup-Maintainer:?
James> With multiple maintainers there is no critical link in the
James> chain, anyone person can step forward to take up the slack.
James> Output stops only when all maintainers are busy, this is no
James> loss over single maintainership or single person responsible
James> for coordinating changes.
You are overlooking basic human psychology: when a crowd is
responsible for something, nobody is responsible for it.
>> (What does the `baz bat...' mean?? This doesn't look like you are
>> taking the discussion seriously.)
James> Please don't try to be so condescending, it doesn't work.
Pot. Kettle. Black.
James> It could have been fixed by either Miquel or Juan, and they
James> didn't (one assumes because they didn't know/forgot about the
James> bug), maybe that indicates it's not quite the disaster for
James> humanity you paint it to be.
I find it extremely irritating, and would have raised more of
a fuss if I did not have a personal copy.
manoj
--
From sensuality arises sorrow, from sensuality arises fear, but he
who is freed from sensuality has no sorrow and certainly no fear. 215
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: