Re: Fwd: sign off on XEmacs 21.5
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
David Kastrup writes:
> Your policies don't get the work done. Your idea of "cooperation"
> is "you do all the work according to our cast into stone policies,
> even if
Sure, we've asked if you wanted to do all the work of producing an
XEmacs package to our specs. Any short-handed project leader does
that! I still don't think it is an outrageous suggestion---many
library maintainers have accepted that deal---but you refused, which
also seems reasonable to me.
We won't scrap the build structure for Emacs just because of
accommodating XEmacs.
That was a chance to start negotiating a more balanced cooperative
arrangement, but for whatever reason we didn't manage to.
Then you went off and created your own "package" distribution without
consulting us at all, which is none of my business. But nobody asked
you to do that, and whatever your motivation for doing it, it wasn't
cooperative.
I think you are missing a part of the history here. It was Nix, an
XEmacs developer, who created the infrastructure for making XEmacs
preview-latex packages. Now if he was not able to do this right
according to the wishes of the XEmacs team, would you expect an outsider
like me to fare better? preview-latex never became a candidate for
inclusion into Sumo for a variety of reasons. That we were not
packaging it right according to the XEmacs gospel was actually not the
killer: rather the build process wrapped system dependencies into the
package, so the finished package would be system-specific and
distribution from Sumo not doing people a favor.
Later preview-latex became an integrated part of AUCTeX, and we
basically extended the XEmacs-centric (but not XEmacs-blessed) package
build process used for preview-latex to encompass all of AUCTeX. After
several iterations, we managed to push out all system dependencies to
runtime. At this point of time, the XEmacs "package" for AUCTeX, built
for us by an XEmacs developer, was system independent and would have
been fit for general distribution rather than being compiled into
package-semblance for a specific system. I took care that the package
layout and metafiles were all according to what an XEmacs package needs.
So in short: the package creation process AUCTeX uses is based on the
work of an XEmacs developer and has been extended to be usable for
Emacs, to encompass all of AUCTeX, and not to incorporate system
dependencies.
Now if an XEmacs developer of the quality of Nix is not able to come up
with a packaging according to your guidelines, what does this tell you?
If it takes XEmacs developers years to come up with a packaging meeting
your guidelines, what does this tell you?
> If you are interested in cooperation, it should be a welcome
change
> when AUCTeX upstream ceases to do any XEmacs-related changes,
> coding, packages and policies.
I have no idea what definition of "cooperation" you could have in mind
here.
That we stop getting in your way of doing everything according to your
own ideas.
I would be more than happy to cooperate on the basis of starting
small, such as getting an 11.8x AUCTeX into our CVS and releasing it
(very small, since we're going to do that anyway), and making sure
that the XEmacs AUCTeX package sends bug reports to us first to reduce
the burden on upstream in the event of future lags, etc. Similarly,
on your part you do what you have to do. If you're going to drop
aspects of support for XEmacs, though, I'd appreciate being informed
exactly what that entails.
Basically I would stop asking our developers to do testing or catering
for XEmacs. It's pretty useless, anyway, since the tested configuration
will not get permitted into XEmacs distribution.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta