Re: [gnu.misc.discuss,gnu.emacs.gnus] Free software: Packagers vs Developers
Rob Browning <rlb@cs.utexas.edu> writes:
(Sorry to follow myself up...)
> What if a user wants to be able to have several major flavors of
> emacsen installed (emacs19, emacs20, and various xemacs) and wants
> them to cooperate, automatically working right with any other system
> packages that support them and automatically generating the right
> byte-compiled files for each all of the installed flavors at package
> install time? You might not like this, I believe many users and
> administrators do.
I want to make clear that I'm not claiming to have the *best* solution
(I already know a number of things that need to be fixed). I'm also
not claiming that it wouldn't be better if the emacs and xemacs people
worked this out among themselves so that there was a really nice
upstream solution, but I *am* claiming that we have built something
that works pretty well, that our solution probably took a lot less
time to get together than it would have if I'd had to get both the
emacs and xemacs people to agree with each other on it, and that as it
was I spent more time on the solution than I actually had to spend.
Would I like to see this problem taken out of my hands and handled
upstream? Absolutely. Do have have the time to get closely involved
in *both* upstream development groups and work out a (potentially
*very* complicated) platform-independent solution? No. But my
patches (and new scripts) are freely available in the emacsen-common
and emacs20 packages and they're GPLed. The emacs and xemacs people
are welcome to them. If I get time later, and if the respective
parties are actually interested in a common solution (i.e. if it's not
something that's just debian specific) then I might work on something
better.
With respect to the packaging alpha-code issue. I haven't seen the
article that people are referring to by Adam?, but my personal
guidelines are as follows (note that these are all explicitly IMO, and
I'm not saying I always live up to them, but this is how I think about
the issue):
1) Don't package something that the upstream author doesn't want
packaged if there's any way to avoid it.
If you think you absolutely must, then this probably means that
you need to find a group of people to fork the code and start a
new project. I imagine situations like this to be extremely
rare.
2) Don't put a package into the distribution without the upstream
author's OK if there's any way to avoid it.
Often, I've found that for alpha/beta things, the author doesn't
mind if you put the package in a non-standard location (actually
some of them host the packages in their devel directory), but
they just don't want the alpha/beta versions going into the
distribution proper. For example, this is the case with
RScheme. Donovan wanted to put the current beta up on his devel
site, but didn't want me to put it in our unstable tree.
3) By default, forward all patches upstream. *At the very least*,
always notify the upstream authors of the location of the Debian
patch file.
4) Ask yourself, when making any Debian specific change to the
upstream source, "Is this a modification that could be better
handled upstream with a more general solution, without a massive
amount more work?". If so, then generate and submit the more
general solution upstream for potential acceptance.
5) Ask yourself, before changing *any* of a program's normal
upstream behaviors, "Do I *really* need to do this? Is this an
appropriate change for someone acting as a packager?" If so, for
example if you're just changing the program to read info files
from /usr/share/info because Debian mandates that they be kept
there, then go ahead[1]. If not, then *don't make the change*.
Suggest the change upstream, and go through the normal upstream
development channels to get the problem worked out.
[1] Though even in this case, you should still mention it
upstream since they'd be likely to want to support the
specification of the default info path as part of the build
process...
I've run in to this one numerous times with the emacs20 and
emacsen package, and I've certainly made my share of errors. For
example, at a few users' requests, I changed the default emacs
behavor in Debian to bind [delete] to 'delete-char. Sounded
reasonable, right? *Wrong*. After a while, someone contacted
me, after they had to waste a substantial amount of their time
figuring out what was wrong, to tell me that my little
modification screwed them up when using emacs via X from other
platforms. I should not have made that change, and I backed it
out immediately once I had a chance to think about it.
6) Often, instead of changing the program's default behavior in a
non-standard way, you're better off just providing a note in
/usr/doc/<package>/README.Debian that mentions things the user
might want to do to make the program work "better" for them on
their Debian system. Regardless, you need to list all your
Debian specific modifications in README.Debian and/or
/usr/doc/<package>/copyright.
If at all possible, the relationship you want with the upstream
authors is one of mutual respect.
This whole issue is not a black or white. Upstream authors *are*
justified in being angry when a maintainer causes more work for them
by unduly mangling their programs according to the maintainer's own
"vision", or when a maintainer makes changes that really are just the
maintainer pursuing his idea of how the program should work. That's
the upstream developer's purview most of the time, and it may well be
that the maintainer doesn't understand all the issues. Unless the
maintainer is on their developers' lists and is intimately familiar
with the code, making gratuitous changes without asking about the
issues is just rude.
However, upstream groups should recognize that package maintainers are
doing an important job for users (of all the available software), and
that the problems that the distribution is trying to solve are complex
and may have nothing (or very little) to do with the regular function
of the program. Further, from the upstream developer's perspective,
package maintainers can, in the best situations, be a reasonably
powerful tool for dealing with trivial user problems (that aren't
related to the upsream source), for tracking down and fixing bugs, and
for getting their program into the hands of a much larger user base
than they'd otherwise see. If the upstream developers' goal is
world-domination fast, then this is likely to be helpful.
--
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930
Reply to: