Re: Release plans

["Stephen J. Turnbull" <stephen@xemacs.org>]

Alan Mackenzie writes:

 > That's a category error.

I see no morphisms.  How can there be a category?

 > I wasn't talking about a scientific process for which evidence can
 > be weighed up.

Shouldn't you be?  Surely you know it is possible to quantify risk,
and analyze it scientifically?  Why do you ask that we on your
nightmares, or Richard's, to guide policy?

 > I am rather asserting the credible existence of a mechanism by
 > which Emacs could become essentially un-free.

Well, let me propose that it's irrelevant, because I assert the
credible existence of a mechanism involving loadable binaries by which
XEmacs will become so superior to Emacs that only people still using
Emacs are those willing to work two or more hours with Emacs when they
could get the job done with XEmacs.  No users, no unfreeness problem. ;-)

Are you beginning to see how untenable your position is?  In fact the
only thing it has going for it is

 > Richard is a master of nasty deviousness, so the fact that he sees a
 > problem is reason in itself to take it seriously.  ;-)

but that's genuinely ad hominem.

 > The essential point is that if an un-free Emacs became established
 > through the mechanism of loading binary libraries, we could not easily
 > reverse it.

Huh?  All you have to do is write the patch and announce a release.
Richard has done that before (the security patch a couple years ago).

A couple of corrections:

 > I think you said recently that there's an obscure patch around
 > which

The patch is to Emacs, and it's obscure only because it has been
refused inclusion in Emacs with extreme firmness, so that its
proponents gave up about five years ago.  In XEmacs 21.4 and later,
it's as simple as ./configure --with-modules.  In recent SXEmacs, I'm
not sure that --with-modules is still supported, but that's OK because
matters are even worse: .configure --with-ffi gives you a foreign
function interface which allows you to access data and functions in
any .so without any C-level hacking.

 > That's very different from something being a core feature,
 > encouraged by the prime maintainers.

Well, in XEmacs, the module loader *is* a core feature encouraged by
the maintainers.  It's not configured by default because demand is so
far low.  In SXEmacs, FFI is configured by many users because packages
are downloaded not by EFS as in XEmacs, but via a FFI interface to
libcurl implemented entire in Lisp.