Fwd: sign off on XEmacs 21.5
dak at gnu.org
Wed Jul 16 05:47:15 EDT 2008
"Stephen J. Turnbull" <stephen at xemacs.org> writes:
> David Kastrup writes:
> > > This led directly to a lot of acrimony and frustration that was
> > > certainly avoidable.
> > Oh come on. Our "package" filled a void that had been open for
> > years. The alternative would have been to let XEmacs users be
> > locked out for another few years from getting updates of the
> > package. If it is acrimonous and frustrating that somebody pitches
> > in to make things work for the user, you have to adjust your
> > priorities.
> Stop trolling, David. Of course it's not acrimonious and frustrating
> that you provided users with a solution. Nobody ever suggested that
> you should stop distributing it; nobody ever tried to tell AUCTeX how
> to manage its internal affairs.
> > I assert that we can't produce and test the configuration that will
> > at some point of time finally be distributed by XEmacs. The
> > startup files are different. The file organization is different.
> > The preconfiguration is different. The manner in which the
> > respective files are found are different. The manner in which
> > version information is injected into code and documentation is
> > different.
> > A test for our "package" is not representative for how your package
> > works.
> This is a very bizarre claim. You say that you have a "package" that
> is in every way the same as what we would distribute.
No. I say that we have a "package" that is in every way _a_ package
like the others you are distributing. And the AUCTeX package that you
presumably _will_ be distributing will also be in that class. But
that's it. A significant number of files will be different. Because
your package is based on historic package system Makefiles and Metadata
that never were part of AUCTeX. All the files _we_ generate for
creating an XEmacs package, you either write from hand or generate
completely differently. The package structure _we_ set up, you set up
differently. Different startup files, different directory search
strategies and so on.
_If_ you are lucky, the results will be comparable, but not reached by
the same means.
> Well, in that case we should be able to aim for the same thing and it
> will work the same, and can be tested the same way.
No, that is not what is happening. Because the XEmacs starting point is
not what we create for an XEmacs package, but rather the tarball
considered as dead meat (rather something which can be made to produce
metadata and startup files in a well-defined manner) fit for cutting up
and putting into the XEmacs repository.
So while our "package" and your package use mostly the same raw
ingredients, the results and behavior are no longer comparable or
representative for each other.
The advantage, of course, is that we can just throw out all support of
building an XEmacs package from AUCTeX without any impact on your
package building. In short, whatever we would have had to offer in the
manner of cooperation has not been put to use.
So we can retire it. Which is not the worst thing, actually. It will
actually be a relief to have justification beyond any reasonable doubt
for stopping investing time and effort in supporting an enterprise that
just can't be stopped from committing suicide.
It is my personal opinion that XEmacs is not a project in a state that
lets it afford downturning contributions and work in the way it does.
Yes, XEmacs contributors don't have to fill out a copyright assignment
to be in the game. The bureaucratic hurdles are much more diversified
More information about the XEmacs-Beta