Re: A suggestion for the woody freeze
On 01/17/2002 10:25:13 AM Adrian Bunk wrote:
>> On Thu, 17 Jan 2002, Vince Mulhollon wrote:
>>
>> > Is it really "free software" if one developer arbitrarily prevents
another
>> > developer from applying a simple patch? I think not.
>>
>> What has this to do with the term "free software"? Consider that e.g. a
>> 100% correct one-line patch to the Linux kernel will never be applied if
>> Linus refuses to apply it.
In my opinion, Debian has a "higher barrier to entry", in comparison to
kernel development, which makes it "less free"
Consider that if you want to create your own separate kernel tree, all you
need is a working ftp site to stick your patched kernel upon. See recent
discussion on kernel traffic, in fact there were complaints too many
splinter trees are being created.
In comparison, I suppose the raging debate of KDE in /opt could be ended if
Eray made a set of packages called kdebase3-eray, koffice-eray, etc, all
the same as the "default" packages but placed in /opt. But is that a wise
solution to make splinter packages? Is it better to torture the ftpadmins
and the mirrors by creating numerous almost identical packages, or is it
better for the developers to terrorize each other via NMUs? I think the
answer is that NMU battles "scale" better, as ftpadmins and mirrors are a
limited resource, but other than bandwidth for duploads there is no scaling
limit for NMU battles. So, we're all overall better off fighting about
individual packages, rather than forming dozens of splinter packages.
Because we can't form splinter packages due to resource limitations, we
pretty much have to cooperate and use a mutually (un)acceptable package,
like it or not. This results in less freedom to do things the way you
individually want. That's pretty much what becoming a society means, in
general.
In summary, for scaling reasons we have a high barrier to entry and
"ownership" of packages, which makes other users less free to do their own
thing. I'm just pointing out that I think Debian is, in a practical sense,
not as "free" as kernel development. And maybe relaxed NMU requirements,
in a very small way, might help that problem.
Reply to: