Neil Williams <codeh...@debian.org> writes: > Whatever happens, there is no place for yet another duplicate of > packages which already have multiple duplicates in the archive.
I think it's hard to defend the contention that the quantity of packages has some strong relationship to whether or not those programs duplicate the functionality of other programs. Surely it also depends on the type of program, rather heavily. For example, I'm sure that we have more than 42 different programming languages in the archive, so obviously we don't need Java, right? You can do all the same things in C++. Or hey, let's pick one of either Perl or Python; they can both do the same things. I can definitely come up with more than 42 different ways to write an editor, all of which may appeal to different people, different tasks, or different work styles. But hey, I like Emacs, which clearly does everything that vi can do, so away with vim! And nvi just duplicates vim! We probably don't need 42 different ways to find duplicate files on local disk, since that's a relatively clear and well-defined task and there's only so many ways to go about it (and each implementation could probably gain the features of the others). But window managers are fundamental to one's style of interaction with the computer, and there are *huge* differences between them. A tiling window manager is not interchangeable with a desktop environment, which in turn is not interchangeable with a window manager designed to be operated without a mouse, or one that's optimized for a particular class of accessibility issues. And that's not even getting into the window managers that are used primarily because they embed a particular scripting language that people want to use to automate their windowing actions. By all means, let's get rid of packages that really do only offer subsets of functionality of other packages. But UI is part of functionality, and a different UI *is* a different feature. By all means, let's get rid of poorly-maintained packages. But if someone finds a package that does something in a way that nothing else does and that fits them, and they're able and willing to take care of it, having a place for those is one of Debian's strengths. We should be improving our tools and management techniques for handling large numbers of packages, including for retiring them when they're not being maintained, not trying to reduce the variety and depth of the distribution. And as sympathetic as I am to the concern about RC bugs in packages that are already in the archive, I suspect it's rather rare that fixing random RC bugs in other people's packages is the compelling, fun thing that gets someone involved in doing Debian development. I know it happens, but I bet more people join the project the way that I did: there's some specific piece of software that they want packaged for the distribution they already use, so they package it, and from that learn how to package, and from that branch out into helping with other parts of the distribution. Getting one's own package into the distribution is a really awesome feeling. I don't think it's good for the growth of the project, or for attracting new contributors, to put too many roadblocks in the way of someone feeling that. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3yvgai6....@windlord.stanford.edu
