Re: Fwd: sign off on XEmacs 21.5
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
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,
Uh no. Not a crash. The process system got broken in a manner with
quite worse (though different) consequences than before (he was trying
to fix a bug, after all). On all platforms AFAIR. But the details are
not really important.
> 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.
Maybe. The point was that the documentation was quite too spotty for me
to come up with something, so I was more than glad that someone did.
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.
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. The policies and the
package system are supposed to serve the users and developers, not the
other way round.
> 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.
There was a lot of extra effort, but at some point of time it is the
better choice to start pulling the cart oneself rather than continuing
to beat the paraplegic horse. Perhaps that would be easier if it really
was dead and did not snarl back.
> > 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?
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.
> > 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.
I consider "vaporware" an impolite characterization since it is a term
usually implying strategy and better knowledge.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta