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

Re: `Every package must have exactly one maintainer'



On Mon, Apr 13, 1998 at 11:47:53AM -0500, Manoj Srivastava wrote:
> Hi,
> >>"Scott" == Scott Ellis <storm@gate.net> writes:
> 
> Scott> deity/apt
> 
> Scott> We seem to have managed well enough with the multiple
> Scott> maintainer model, although I must admit that I've been the only
> Scott> person doing releases, there isn't a particular reason why
> Scott> someone else on the team couldn't.
> 
> 	This is a good case. There has been a very clear demarcation
>  of responsibility in Deity; You do all releases, and everything
>  related to Packaging is your domain and responsibility. Jason does
>  the coding (oh, I know, the rest of us contribute, but Jason has been
>  the person who integrates stuff in, like Linus and the kernel).
>  There are other roles in Deity that are also well defined; and that
>  is the reason the team has not fallen apart at the seams.
> 
> 
> 	For deity, one knows who is in charge.
> 
> 	The same is true of the Linux Kernel development -- there is
>  one guy in charge. The same is true for the Gnus development
>  team. And the LaTeX2HTML development team. And the Angband
>  Development team. Even the Xemacs development (back when I was part
>  of it) had one or two people with well marked demarcation of
>  authority in charge.
> 
> 	The XFree86 and CVS development teams maybe exception, but I
>  suspect that like Deity, there is a strict division of responsibility
>  in those teams as well.
> 
> 	I think the buck needs to stop some where in a project. 

As a member of the boot-floppies team, I would like to contribute my two
cents to this thread. 

The main reason I've seen against multi-mantainer packages is that of
"diluted responsibility", but now manoj talks about projects where
"there is a strict division of responsibility" (although an outsider may
have to dig a few documents to know who is responsible of what) and things 
work fine. So, "diluted responsibility" is not unavoidable in a 
multi-maintainer project. 

OTOH, maintainer teams are desirable in complex packages where the
maintainer has to do more than keeping track of upstream releases.
It's not easy for a single person to develop and mantain dpkg or
boot-floppies on his spare time, and, at least for boot-floppies, the
multi-maintainer approach has proven to be of great help (if you are
concerned about the number of open bug reports, you should see the number
of recently closed ones... and the complexity of the remaining ones).

As Manoj clarified with examples (Linux, Deity, ...), "multi-maintainer" 
is not the root of the problem (poorly maintained packages), so please, 
don't shoot the wrong beast.

	Thanks,
--
Enrique Zanardi						   ezanardi@ull.es
Dpto. Fisica Fundamental y Experimental			Univ. de La Laguna


--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: