[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

  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

     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

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: