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

Re: `Every package must have exactly one maintainer'



Christian Schwarz wrote:
> > My feeling on this is, yes, a single maintainer seems to work best, as in
> > the linux kernel model. But why do we have to enforce this in policy?
> > Developers should be free to set up any organization they want to maintain
> > their packages, as long as it gets the job done.
> 
> It has to be mentioned in policy because it does affect the quality of our
> distribution. There are a lot of topics which can be decided by the
> individual maintainer--but there are also a few decisions which we can't
> leave up for the maintainer. If everyone would know which decision would
> be best for the distribution as a whole, we wouldn't need policy!

Well, I think this assertian that having multiple maintainers like dpkg does
will always lower the quality of the package is open to debate. I don't
really feel like debating it though, this thread is long enough already. 
Instead, some off the wall examples of why I think putting this sort of thing
in policy is wrong:

Suppose that after many months of study, it was concluded that programmers
using emacs were much more effecient than programmers using vi, and that
emacs's features in fact helped them produce better code [1]. Should we then
add to the policy manual a prohibition of debian developers using vi to
maintain their packages? I think not. Even if this were true overall, people
differ, there should be room in the policy manual for these differences.
Even though overall emacs is (hypothetically) the better development
enviroment, there will be developers and situations where vi is in fact
better and forcing people to use emacs in these situations cripples them.

Or, another example. Suppose that we have 3 established ways of generating a
.deb file, debmake, debhelper, and by hand. Suppose that we eventually reach
a consensus that debhelper is the easiest and best way to go [1], we even back
this up by observing that packages using debhelper have far fewer packaging 
bugs over time than equivilant packages that use debmake or are done by
hand [1]. Well, I for one would fight tooth and nail to keep "all packages
must use debhelper" out of the policy manual, becuase I know there's an
exception to every rule, and Manoj and others can do wonderful things with
the old fashined unix tools.

What I'm trying to say is, policy should say *WHAT* a developer must do in a
package. it should not attempt to dictate *HOW* a developer accomplishes
this. If you're concerned about package quality of dpkg, try to come up with
policy that makes developers take responsibility for their packages, and get
bugs closed. Don't try to tell us how to do it (that has it's place, as
suggestions of good ways to do things, in companion documents like the
developers reference), just tell us what to do, and if it's really
necessary, impose some sort of penalties if we don't do it.

-- 
see shy jo

[1] Let's not start a religious war here, this is just an example, and I
probably disagree with it myself. ;-)


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


Reply to: