Hi, On Fri, 2008-02-29 at 11:16 +0100, Thijs Kinkhorst wrote: > On Fri, February 29, 2008 03:02, William Pitcock wrote: > > Why does a package need to clarify what's different about it than others > > like it? Debian is about having the possibility of choosing between many > > options for the same thing e.g. openssh, dropbear for sshd, 12 different > > httpd options, etc. > > The word "different" is key here. Debian wants to offer different options > to its end users. But please, only options that are significantly > different to what we already have. > There are several costs associated with having yet another package doing > the same thing: > * For the project in general, it costs archive and Packages file space, > build time, QA efforts just to name a few; > * Especially true for network facing services: the security team needs to > support every package in stable; > * For the administrator: having a choice between a few webservers is good, > having to choose between a dozen that are hardly different just troubles > their view. You can have too much choice.
Clearly these packages are different enough to somebody if they are going to the effort of packaging them. Perhaps they have a superior configuration format or some other non-notable feature. But if you are worried about the QA and security team, then why not create an unsupported repo. It could even be a good solution towards recruiting new DDs. Lets call it, say, 'community', 'extras', or 'unsupported'. The main featureset I see here would be: * Anyone could register with it, and upload their packages. There would be buildd's and whatnot, so for all purposes, it would be similar to having packages in Debian proper. * If the package is good, it could be migrated into Debian proper where it would receive proper security team and QA attention. * It would allow people who are having problems finding mentors to upload on their behalf the ability to still contribute to Debian's package collection. Which in turn, would probably eventually lead them towards a mentor. * It would give end users the ability to learn more about DAK and all of the other stuff involved in Debian packaging in a hands-on environment. * It would allow a greater latitude of options while not adding additional workload on the QA and security teams. * Community QA'd, meaning a hands-on learning experience for those who might be interested in joining the QA team. * As it is not an official Debian repo, but instead a community repo, Debian ftp maintainers would choose for themselves whether or not to mirror it, like backports.org. If the project is successful, it could later be offered as an option at install time to get more packages. > > We can obviously live with the costs that a package incurs, but it makes > sense only if there is something that offsets the cost: a clear added > value of this package to the distribution. That is something that must be > able to be justified when any new package is added. "Just because" doesn't > cut it. > Sure in the Debian main repo, but if a community repo existed, it would not matter. > > Package descriptions should stick to positive aspects of the package, > > and not try to draw comparisons towards other packages. IMO. > > A package description is intended for the administrator to choose which of > a set of alternatives to install. A comparison to others, or being open > about possible limitations, are very helpful to make this decision. Use debtags for that. > > > It seems to me as if you are trying to get people to justify the > > packages they want to work on. > > Yes, and that's very desirable. Telling people to go away because you don't want to QA their package is not desirable at all. William
signature.asc
Description: This is a digitally signed message part
