Re: What doing with an uncooperative maintainer ?
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
Reply to: