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

Re: [gnu.misc.discuss,gnu.emacs.gnus] Free software: Packagers vs Developers



I've been thinking about this issue lately.  On one hand, I think the
XEmacs maintainers are a being a bit extreme.  On the other hand, they
have a good point.

Let me start by saying I have seen a very disturbing trend in Debian
to bad-mouth upstream maintainers.  Even very senior people in Debian
have done this.  This is disturbing -- upstream maintainers are the
well-spring of Debian.  They are the reason why free software exists.
Sure, sometimes they disappear, sometimes they aren't very friendly.
However, we live on their largess.

XEmacs is a big and complex package.  The XEmacs maintainers want to
ensure that users have a good experience with the software they've
worked so hard on.  Users should be able to port their emacs user
environment between different hosts easily.  I'm sure they don't want
to see bug reports based on problems created by other.

On the other hand, Debian versions of packages are inherently forks.
We do need to be able to modify software (that's why it's free!) to
ensure that the overall "debian experience" is a good one.  Not to
mention to comply with policy.

However, Debian developers need to look at the Debian fork as a
necessary evil which should be minimized if at all possible.  This is
just a few bits of common sense, stuff which I am thinking about:

  * join the mailing list for the software you are packaging.  Be an
    active participant.

  * try to keep diff size not in the debian subdir very small (not to
    say you should revert to applying patches as part of the build
    process).  Send patches upstream when they are not Debian
    specific.  And keep sending them!

  * if you get a bug report, make a quick judgement whether it's a
    Debian bug or an upstream bug.  If it's an upstream bug, then
    *before* you start whacking on code, notify the upstream
    maintainer of the bug (and whether you intend to patch for it).
    This involves the upstream maintainer in the process of fixing
    problems, ensures they get timely information while the bug is
    fresh in everyone's mind, and lets the maintainer participate in
    design decisions about how things should be fixed.

  * if you have a major integration feature that you're thinking about
    implementing in your package, let the upstream maintainer know
    what you are doing.  They might have ideas on how to generalize
    the solution so *all* users benefit.

  * do not change dot-config file formats or filename except under
    *extreme* conditions of duress (i.e., security issues?). Definately
    notify upstream maintainers before doing this.  Remember that some
    people share their home dirs and dot-configs between many operating
    systems and machines.

  * exercise the principle of least suprise

  * remember that upstream maintainers know their software better, and
    in more varied circumstances, than you do

For instance, I think the recent "ultra forkage" proposed Karl
M. Hegbloom is ill-conceived in the extreme.  It must be one of the
worst ideas I have heard in a very long time.

--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>


Reply to: