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 [EMAIL PROTECTED]<URL:http://www.onShore.com/>
