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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
