On Thu, Aug 21, 2003 at 03:05:00PM +0200, Thomas Hood wrote:
> But sometimes there are fundamental disagreements about how something > should be packaged and then it must be possible for two competing > packages to exist in Debian Says who? Debian is not just a collection of packages, it's a tightly integrated operating system. This is a distribution. What we deem good development practices for/of free software doesn't have to apply here. As a distribution, we have different goals, we have to make desicions that fit into that picture. Along the years we have created a system that ensures that when you install something, it will get integrated into the system. For that we have had long and painful discussions regarding "best practices" and long and painful discussions to make stuff work together. We have (implicitly) agreed on the fact that the package maintainer is a person who knows what he's talking about when it comes to his packages. If the package maintainer deems it appropiate to upload a snapshot version of a package we have usually played along. If the maintainer thinks the lastest and greatest is not really such a good idea, we have played along: see the XFree86 packages. Every now and then packages of the most recent version of XFree86 pop up, but people usually give up when they gasp the swamp they are getting themselves into. For the small stuff, like gqview -- which I've not seen even once -- that proposition might work, but it's setting a bad precedent. If there's a newer bigger better faster upstream version and the maintainer won't upload it and won't say why, by all means, flame him in public if that's what it takes to get an answer from him. If it's obvious that the maintainer isn't paying attention to the package or just doesn't care, make a hostile takeover (and be ready to get flamed). But don't fork it. Forking it means: * There are two versions of the same thing in the distribution + Duplication at the BTS level + Duplication in the archive + Confusion for the users * No visible gain, except for those who have to have the CVS version from 2 seconds ago * More work for the future + What about upgrades? + What if the forked version isn't necessary anymore? + What about users of stable, who are stuck with a random CVS snapshot for good 24 months. > otherwise you are giving maintainers the same rights as software > proprietors: _they_ control the code; _you_ can't change it (while > remaining within the Debian framework) even if you are willing to do > the work. You don't really beleive that, do you? I know the control freak mantra has become trendy as of late, but that's stretching it a bit too far, isn't it? I hold that if you do a good work with a alternative yet not in the archive version, you can come up here and say "I'll take over this without the maintainer's blessing" and you won't face oppossition. My first package was uploaded like that: "hi, I've been maintaining such and such for private use for a while, the maintainer doesn't show any signs of life, I'm going to take over it". Yes, gqview's case is a tad different, but try to see the big picture. > I say you should _not_ give maintainers that kind of power -- the > power to stop others from doing a better job. We don't. > That kind of power will inevitably be abused, and has already been > abused. Every maintainer should face the threat of competition from > someone else who thinks he or she can do a better job. That is an > essential freedom in open source development. Yes, in software development, but not in a distribution that tries to pass around as well integrated and stable. > There are already many programs in Debian that are packaged in > different flavors. I don't count that many: galeon, xnap, mozilla, irssi, gcc, gforge, everybuddy, busybox, lxr... > These variants serve the needs of different sorts of users. From the above list, I can tell you that GCC's case is a good one: developers benefit from it, people using certain architectures benefit from it, GCC itself benefits from it to some degree. Mozilla is a good case too: their release policy is rather conservative (from my POV) and users in general might benefit from snapshot versions. Everybuddy? No idea. The CVS version in unstable is, oh... the same one in stable. Someone got bored it seems. See what I mean? Busybox, I can figure the installer people need (to test) this. > From reading this thread it is my impression that gqview falls into > this group: the gqview maintainer has a conservative packaging policy > while his critics want to run the latest version. Unless one side > gives in, this seems like adequate grounds for a fork. wget. tar. configure. make. The system won't explode, beleive me. Marcelo