Re: [gnu.misc.discuss,gnu.emacs.gnus] Free software: Packagers vs Developers
Adam Di Carlo <adam@onshore.com> writes:
> You have repeatedly voiced your opinion that middlemen are useless.
No, I have said that they are harmful. I haven't discussed their
usefulness.
> It's obvious that you have little to no respect of "distributions" in
> general, and clearly Debian in particular.
Distributions are necessary, but they create some new problems which
should be addressed. The problems seem to occur most often with
Debian.
> Your suggestions are flawed, that is, based on a flawed conception of
> what Debian is, and flawed in that we feel they are overly
> restrictive.
I haven't voiced an opinion on what Debian is.
> Your implication throughout is that Debian consists of a group of
> non-contributing symbiots who don't understand the models of free
> software development, and leech off of it rather than add to it.
I think that you can percieve this "implication" is symptom of the
Debian Attitude Problem, which perhaps makes it more difficult for
Debian maintainers to address process problems.
> Aside from any level of personal affront, this displays to me either
> that you are simply ignorant of what our conception of an integrated
> distribution is, or you simply reject this conception out of hand.
Obviously, any critique of the Debian process must be due to
ignorance.
> OTOH, your stipulations are draconian: "don't change upstream code at
> all unless you change the name of the software and fork". We reject
> this stipulation:
I never wrote that.
> * licensing doesn't require it
It is legal so it ethical.
> * some packages are no longer actively maintained upstream, but we
> still ship them as a service to our users (jade, sgmltools v1 are
> two off the top of my head, that I deal with a lot)
Good reason to make maintainance it a separate (top level) project.
Like Alan Cox did with the Linux 2.0 kernel.
> * some upstream maintainers are utterly unresponsive or too busy to
> properly respond to change requests (even "ack"ing them)
Then either don't make the changes, or make the changes yourself. If
you make the changes yourself, you have forked the project. Decent
behaviour would be to give the forked project a new name.
> * some upstream maintainers (I find it hard not to categorize you
> here) behave unreasonably
Upstream maintainers who do not bend over when the Debian packager say
"bend over" are behaving unreasonable.
> * some changes really are Debian-specific. Obviously, communciation
> with upstream maintainer should occur and a better solution should
> be found
I guess you talk about "interoprability changes", right? One of those
kind of changes I explicitly listed as acceptable.
> * we believe that we add value for users when we fix bugs; we believe
> we add value to upstream developers when we send them patches.
> This for us is close to the essence of why free software/open
> source is better.
You are doing it the wrong level. Join the development effort at the
top, and then let the bugs and enhancements be distributed out from
there. Instead of doing it in the middle, and hope it will go both up
and down from there.
> Other suggestions are solicited, but let me rule out the "no fork"
> stipulation completely.
Actually, I say "when you fork, don't make it a hidden, Debian only,
fork.
> You repeatedly state that Debian maintainers are not even users, but
> rather "middlemen". This is obscure -- I don't understand even what
> you mean there.
You do jump to a large set of conclusions based on something you claim
you don't understand. The Debian maintainers are "middlemen" in that
the users don't interact directly with developers, but instead with
the some men in the middle.
> It is pretty much a foregone conclusion that a Debian
> maintainer for a package actually uses that package.
Sure, you can have that role too when dealing with the developers.
Depend on whether you act on your own behalf, or behalf of your own
users.
> I don't understand why you can't (a) read the description of what the
> patch does and why, and judge it on those ground, and (b) read the
> code in the patch and judge the code on those grounds.
The history is lost. When people contribute directly in the
development effort, they are there on behalf of themselves, we can
discuss the problem, the design choices, and the implementation. When
a middleman interferes, this become either guesswork or much slower.
> > The inherent conflict between the easy Linux (or even Debian)
> > specific solution, and the hard multiplatform solution.
>
> This is both unfair and ill-informed. Debian includes many
> architecture and more than just Linux (hurd-i386 is expected to ship
> in 2000). I have seen very few Debian patches to upstream source that
> harmed portability or generality.
I was refering to someone else in this thread, who used the extra work
for ensuring the solution was multiplatform as one argument for why he
didn't made a "proper fork", but instead maintained a "hidden Debian
fork".
Reply to: