Re: [gnu.misc.discuss,gnu.emacs.gnus] Free software: Packagers vs Developers
Per Abrahamsen <abraham@dina.kvl.dk> writes:
> "A. P. Harris" <apharris@queso.onshore.com> writes:
> > So you can perhaps see why some people on debian-devel get upset when
> > you single them out and don't accord them the privledges of any
> > interested hacker who is looking to improve the software.
> Au contraire, I have suggested that they join the ordinary development
> effort at the top.
See below.
> > Moreover, your blanket statement that Debian developers never coordinate,
> > never send stuff upstream, etc. is unfair.
>
> Nor have I made any such all-encompassing statements.
You have repeatedly voiced your opinion that middlemen are useless.
It's obvious that you have little to no respect of "distributions" in
general, and clearly Debian in particular.
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.
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.
However, I'm going to put on my diplomacy hat, take a deep breath, and
try to summarize where communication seems to be breaking down.
> I have pointed out that there is some inherent problems in the process
> of making distributions, and came up with suggestions for how to
> lessen these problems.
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.
Let me frankly state why I think this is so. Based on my personal
experience, 80 to 90% of my work is concerning materials which
properly belong under the 'debian/' subdirectory. This includes but
is not restricted to automated building and installation with proper
settings (i.e., to 'configure') for installation of applications and
data according to Debian specifications for such things; maintainer
scripts to handle, for instance, calling 'ldconfig' after shared
libraries are installed, documentation registration, installation of
info files, etc.
A Debian box is a machine that provides a lot of consistency and
infrastructure (doc-base, install-info, package dependancies and
installation ordering, sgml catalog installation) that a general free
software maintainer simply cannot rely on for a robust software
distribution. Such materials is both irrelevant and inappropriate
insofar as how upstream software should operate. For instance, you
need to be able to support the installation of applications in
/usr/bin or /usr/local/bin or /opt/gnu/bin or whatever (sysadmin
decides).
Sure, technically, we could get this moved upstream into top level
makefiles (if any) as a special target, but how is that different
except in minutae to debian/rules (a makefile also) ? Moreover, I'm
sure a poll of most free software maintainers is that they would
prefer to see Debian-specific installation infrastructure segmented
into the debian/ directory -- leave it to the Debian developers to be
the experts on how the system should install on a Debian system.
Moving on to the bug fixing issue, I think that there are some perhaps
overzealous maintainers who hack on upstream code with pretty much
utter abandon, while not really interacting very deeply with the
upstream maintainers. However, I would argue that this case is
actually quite rare, and only getting rarer. I agree that Debian
could do more to actively discourage this practice, and I intend to
see that such changes are put in place.
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:
* most of the changes we make, *by* *far*, are under the debian
subdir, and are pretty much segmented
* licensing doesn't require it
* 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)
* some upstream maintainers are utterly unresponsive or too busy to
properly respond to change requests (even "ack"ing them)
* some upstream maintainers (I find it hard not to categorize you
here) behave unreasonably
* some changes really are Debian-specific. Obviously, communciation
with upstream maintainer should occur and a better solution should
be found
* 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.
We accept your objections on the following grounds:
* upstream developers deserve a voice -- they still have their
name(s) on the software. Changes shouldn't be made to their code
without good reason. This benefits the users and the upstream
developers both.
* upstream developers ought to be part of the process of fixing bugs
(although a great many care not to be bothered)
* obviously Debian is doing more than just making patches available
for users to use -- we are also shipping precompiled binaries. In
this way, it may not be immediately obvious to users that an
application may behave differently under Debian than when the fetch
the code from upstream.
* upstream maintainers should be privy to any application behavior
changes, patches etc., esp. since it is their code after all, they
may object on some grounds that the maintainer didn't think of,
users will still report bugs to them, etc.
I can conceive of cases where the Debian version of a package is very
very forked from the original, and the upstream maintainer feels at
complete loggerheads with the Debian maintainer. It seems to me that
there *should* be a recourse for upstream maintainers in these
(thankfully rare) situations.
However, hamstringing Debian maintainers as you suggest is not the
right solution. We believe we can solve these issues by simply making
some more clear guidelines on how maintainers should interact with
upstream source and upstream developers, and by providing information
for upstream maintainer, for instance, why Debian does some of the
things it does, how to inspect Debian diffs, escalation procedures,
etc.
Other suggestions are solicited, but let me rule out the "no fork"
stipulation completely.
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. It is pretty much a foregone conclusion that a Debian
maintainer for a package actually uses that package. Perhaps your
clearest statement was:
> When you create a package, you are packagers. When you create your
> own competing support infrastructure, you are middlemen.
I assume you mean the bug tracking system? By no means to we pretend
to compete with the support offered (or not) by upstream maintainers.
The purpose of the bug tracking system (BTS) is indeed to track bugs
in a bit of software. However, it was never our intention to
"compete" with the mailing lists and support structure (and even bug
systems, for those who have it) of upstream free software. OTOH, very
often, problems reported in the Debian BTS are quite often (I would
venture 50% of the time) specific to Debian (generally pertaining to
dependancy problems, problems with the installation scripts, porting
problems, etc).
And in the cases where bugs are indeed upstream bugs, the "theory" is
that these bugs would be forwarded on to upstream maintainers and
marked as such in the system. I agree that sometimes this breaks down
-- I do believe we can improve there. However, your implied
assessment that we ought to scrap the BTS is both unacceptable to us,
to Debian users, and I'm sure even most upstream maintainers would
find it to be ill-conceived to do that (why would an upstream
maintainer want to worry about interpackage dependancies being
fulfilled, for instance).
> Unfortunately, since the Debian packagers are self-selected (or at
> least selected from outside), there are no a priori reason for a
> developer to assume they are [knowledable or trustable].
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. No one is
asking for 'a priori'. Likewise, there's no a priori reason why they
can't be trusted, or treated at face value, or given the respect you'd
give any user who cares enough to try to fix your software?
> A report like: "Someone else who used a code not entirely different
> from yours had a problem, and this solved it." is a _lot_ less useful
> than "I tried to do this with your code, and got that result, while
> expecting this result."
Some developers have very stringent requirements on patches. You
require confirmation from the "original user", and then discussion of
expected behavior and received behavior. The CVS maintainers, I think,
required test cases for their test suites which fail without the patch
and succeed with it. I think that strictly applying criteria for "bug
report" validity, however, would only inhibit the user's or
developer's desire to contribute.
Your request is reasonable for your own stuff of course; I think it's
perfectly fine for you to request bug reports in a certain form. Have
you followed up with the report with the person who reported the
report to you (even if she is a Debian maintainer), and simply asked
for expected behavior and received behavior? Assuming you recieve a
patch or a bug report from a Debian maintainer that fulfills your
requirements, would you give it any notice and *not* delete it?
Not treating a Debian maintainer with the same respect you would give
Joe User is both conterfactual (maintainers are users, and generally
highly technical ones) and irrational. Mutual dialog about bugs and
patches is to be expected with any user. I haven't seen any really
rational reason given why you refuse to enter into this dialog.
> 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.
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: