Re: [gnu.misc.discuss,gnu.emacs.gnus] Free software: Packagers vs Developers
Greetings all, and especially Per,
As a Debian user who's been following this entire thread on
debian-devel, I just have to point something out here.
On 07/02/99 at 18:18:28, Per Abrahamsen wrote concerning "Re: [gnu.misc.discuss,gnu.emacs.gnus] Free software: Packagers vs Developers":
> > > I use "mangling" because the actual practice is harmful, in that it
> > > hinders the development of the project. There are plenty of ways to
> > > modify the code without harming the project, some of which in fact
> > > contributes.
> >
> > For example?
>
> Use the code in another project (neutral).
>
> Improve the code and merge it back to the original, _instead_ of
> distributing your modified version (a contribution).
This is precisely what Debian package maintainers are supposed to do, if
possible. In fact, I would guess that this is what most of them do
already. Of course, nobody, not a user like myself nor a Debian
maintainer, or even Red Hat can _force_ a developer like you, Per, to
incorporate those improvements. Case in point: you receive an
improvement (bug fix/enhancement) in the form of a well-reasoned email
with a patch attached, and you redirect it to /dev/null. But that
possibility is not a problem; it's a good freedom, and it makes sense.
Sometimes it may cause a "legitimate" fork, but that's OK.
The problem is when we have conflicting interpretations of the dividing
line between:
1 - alterations necessary to make the package live nicely with the rest
of the distribution, and
2 - alterations that constitute "mangling," that is, actual bug fixes or
enhancements in the upstream code base.
In the first case, it's obviously OK -- even encouraged -- for the
distribution to do what's necessary to make the package work with the
other packages in the distribution. BUT, the package maintainer has the
responsibility of handling any problems that may arise due to his own
alterations. It only makes sense that the software developer shouldn't
have to worry about those things.
For the second case to be acceptable, there must be cooperation
between the packager and the developer. If he is able, the packager
should become the developer's assistant in tracking down the source of
problems or in specifying the enhancements desired. The most productive
and convenient way for this to happen is for the package maintainer to
digest and clarify the bug report or enhancement request and forward it
to the developer. This MAY include a patch, and it should always
include a way for the developer to contact the originator of the
request.
Here's my take on what's been said:
It seems like you (Per) have a conception of the distinction between
these two scenarios that is significantly different from the conception
most other developers and package maintainers have. You seem to have
the impression that changes on the order of category 2 are being made on
a regular basis, and these improvements are _not_ being merged "back to
the original" (your words above).
If that is the case, you should probably say so, particularly discussing
the issue in private with the package maintainer(s) in question. If
that's not possible, then at least let debian-devel know what specific
instances of transgression you have witnessed, and why these things are
so bad.
Looking forward to more discussion,
Jesse
Reply to: