[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dogme05: Team Maintenance

On Tue, Aug 16, 2005 at 02:46:35PM +0200, Petter Reinholdtsen wrote:
> [Alexander Schmehl]
> > Do you realy think you can enforce teamwork?  I don't think so.
> > Either some people will work together as a team or individuals will
> > do it their own way.  And I don't think it will be a good idea, to
> > force those individuals to work in a team.
> I agree.  There will always be people unwilling or incapable of
> working in teams, and some of them will be debian developers.  I
> wounder how many of these decided to join in on this thread.
> But I believe it is a good idea to remove the most important packages
> in debian from the single set of hands maintaining them at the moment,
> if the current maintainer is unwilling to maintain these in a team.

I disagree. If the maintainer is doing a good job on his (or her) own,
then there is no need at all to take away their packages.

> We should strive to increase what I normally call the bus-factor; how
> many people need to be run over by a bus before the project stops.
> And for several of the packages in debian, the count is 1 or less.

That's not true. For several of the packages in Debian, it is true that
there will be a problem if their maintainer will be run over by a bus.

However, that in no way means the project "stops". As the past has
taught us, should something like that happen, there will be people
willing to take over. It might take a bit longer for the new maintainer
to be up to speed as compared to when one member of a team gets run over
by a bus, but that doesn't mean "the project stops".

We should strive to increase the quality in Debian. If some people can
produce higher-quality packages by working in a team, then more power to
them. If other people can produce higher-quality packages by /not/
working in a team, then there is no reason to force them to work in a

Don't forget that every bit of teamwork results in some overhead; you
have to communicate to your team members what you're doing, and all of
your team members have to understand it (which may involve tedious
explanations and/or some learning time for your team members). Depending
on the complexity of a package and the amount of work required to
maintain it, this overhead may just not be worth it.

The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond

Attachment: signature.asc
Description: Digital signature

Reply to: