Re: Fwd: sign off on XEmacs 21.5
David Kastrup writes:
> Why you thought Nix was "an XEmacs developer" I
don't know. I suggest
> you ask him, or yourself. I certainly never told you he was.
Well, he is the only one I know who was able to botch up an XEmacs
release so seriously it had to be withdrawn.
"Had to be withdrawn", no. There was a crash introduced on a platform
I was unable to test, it was detected within hours of the upload, so I
figured it made sense to do another release immediately, and in the
meantime disable downloads of the broken version. Other XEmacs
developers objected strenuously after I reacted, but it was a fait
accompli, and I decided not to reverse course again.
But [Nix] is a smart guy. I have failed in a lot of XEmacs areas
where he prevailed. Including getting to a working package setup.
So, he's smart. But he didn't "fail" to come up with packaging that
followed guidelines, he didn't even *try*, apparently.
Once again, we can see a complete failure of communication. I was not
aware at all that such efforts were being made, until you presented us
with your "package", years after Nix did his work.
This led directly to a lot of acrimony and frustration that was
certainly avoidable.
Extending the package infrastructure also was supposed to make work
easier for Uwe or anybody else willing to pick up, by delivering a
ready-made and tested configuration suitable for the package system.
Well, I'm pretty sure it did make work a lot easier for Uwe and Mats.
There was no cooperation, close or otherwise. It was enough of a
chore
to convince AUCTeX developers not to abandon XEmacs support altogether
given the manner they and bug reports and patches and requests were
handled on the XEmacs developer lists.
Well, I can certainly understand the AUCTeX developers' feelings. On
the other hand, sometimes it's worth making the extra effort to
establish a cooperative relationship.
> Presumably, the configuration on which you run functional tests
> *is* the XEmacs package configuration.
No. It is what _our_ packaging system produces.
[...]
The AUCTeX configure/install procedure is intricate and
autogenerates
files that find paths and other stuff relative to their installed
location. So any procedure that moves things around after the
autoconfigure, _breaks_ stuff.
I can just imagine what Tom Lord would have to say about that! ;-)
So no, what we can test is not the same as what will be placed in
the
XEmacs package repository. The whole startup and directory location and
system-independent preconfiguration (which is, in the AUCTeX build
system, a particularly clever setup for the system-dependent
configuration generator) is _not_ what we can produce and test.
I don't understand what you're trying to say. You say above that you
have a ready-made tested configuration, but now you assert that you
can't produce and test one?
> As far as I can tell, we *are* on the verge of an XEmacs
packaged
> version of AUCTeX that satisfies our criteria, as well as being vastly
> improved in terms of timeliness from AUCTeX's point of view. So from
> my point of view while a lot of the things you say were arguable 6
> months ago, they really are quite inapplicable to the current
> situation.
We'll see.
Sure. It's all vaporware to me too, except that I trust Mats and Uwe
personally to have something to show.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta