9:27 p.m.
David Kastrup writes:
I think you are missing a part of the history here. It was Nix, an
XEmacs developer,
AFAIK, Nix is a GCC developer who preferred XEmacs for his editor. He
has a total of 6 or 7 credits in our ChangeLogs for core, and only 10
in packages, none in AUCTeX.[1] He definitely was never a reviewer,
and he doesn't have, and AFAIK never had, CVS or Hg commit privilege.
One real smart guy, but I can't claim him as one of ours. If you're
going to claim he's an XEmacs developer, please, please, deliver him
(and his skills) to us!
[R]ather 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.
I remember that.
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.
I am indeed missing that part of the history. Which, of course,
implies that nobody in XEmacs asked you to do that work or suggested
that you do it or cooperated in doing it. 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.
He also never mentioned the work he was doing on AUCTeX's build
process on XEmacs channels AFAIK, although I knew he was interested in
AUCTeX.
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?
That he's not an XEmacs developer, of course.
If it takes XEmacs developers years to come up with a packaging
meeting
your guidelines, what does this tell you?
That it took years to find people with the skills and interest to do
it.
AFAIK only a couple of man-weeks have actually gone into the most
recent work, which AIUI is pretty much independent of earlier
attempts. You'd have to ask Uwe and Mats.
This low effort is almost certainly due to the work Nix (and the
AUCTeX dev team) did on AUCTeX, as you described. It is unfortunately
not the fruit of cooperation with XEmacs, but of cooperation between
an AUCTeX-and-XEmacs user and the AUCTeX developers. But we had no
clue what you were doing. That was Uwe's task, to keep track, but he
probably wasn't aware of the significance of the changes Nix was
making. Closer cooperation between the core of XEmacs development and
that of AUCTeX would surely have sped up the process of getting to
where we are today.
That we stop getting in your way of doing everything according to
your
own ideas.
When did you get in our way? I certainly haven't noticed AUCTeX in my
way. Personally I have this problem that I respond to your posts in
unproductive ways, but that's not AUCTeX-specific.
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.
That's a strange thing to say. Presumably, the configuration on which
you run functional tests *is* the XEmacs package configuration. So it
*will* get into the distribution. Users (or you) are welcome to
report bugs if the configuration produced by Mats and Uwe is not as
expected. It will also get further testing (which may or may not be
redundant) in the process of being built (and tested, if tests are
provided) in-tree.
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.
Footnotes:
[1] This means that he contributed very little to XEmacs package
infrastructure maintenance. He may have had substantial contributions
to package functionality that would be logged in upstream (renamed)
ChangeLogs.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:55 p.m.
New subject: Fwd: sign off on XEmacs 21.5
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
David Kastrup writes:
> I think you are missing a part of the history here. It was Nix, an
> XEmacs developer,
AFAIK, Nix is a GCC developer who preferred XEmacs for his editor. He
has a total of 6 or 7 credits in our ChangeLogs for core, and only 10
in packages, none in AUCTeX.[1] He definitely was never a reviewer,
and he doesn't have, and AFAIK never had, CVS or Hg commit privilege.
Well, in the course of his preview-latex work, he was the one
responsible for the only case known to me in XEmacs history where an
XEmacs release was actually removed from the mirrors. So obviously he
was trusted enough to have a rather direct access to the XEmacs code
base. He also was the only person on the preview-latex team with enough
of a grip on XEmacs internals to have a remote chance to get it to work.
One real smart guy, but I can't claim him as one of ours. If
you're
going to claim he's an XEmacs developer, please, please, deliver him
(and his skills) to us!
I certainly have no claim on him. He more or less disappeared from the
radar after a severe bout of RSI and other health problems. I am
grateful for what he did in the course he worked on the XEmacs port of
preview-latex (which formed the base of our AUCTeX support).
> [R]ather 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.
I remember that.
> 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.
I am indeed missing that part of the history. Which, of course,
implies that nobody in XEmacs asked you to do that work or suggested
that you do it or cooperated in doing it.
We waited for years for anybody willing to take AUCTeX from its state of
11.14 in the XEmacs package repository onward. It was really, really
stone age. Nobody was willing to do that. So that XEmacs users were
not totally left in the lurch, we extended the previous
preview-latex-only procedure to deliver all of AUCTeX.
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. So it is naturally to
assume that he would be a developer.
> 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?
That he's not an XEmacs developer, of course.
But he is a smart guy. I have failed in a lot of XEmacs areas where he
prevailed. Including getting to a working package setup.
> If it takes XEmacs developers years to come up with a
packaging
> meeting your guidelines, what does this tell you?
That it took years to find people with the skills and interest to do
it.
Reality's a bitch. The guidelines just don't do the work all by
themselves.
This low effort is almost certainly due to the work Nix (and the
AUCTeX dev team) did on AUCTeX, as you described.
No. XEmacs was dragging its feet on AUCTeX long before preview-latex
got integrated. And long before we extended the framework to all of
AUCTeX in order to have _anything_ to offer to XEmacs users.
It is unfortunately not the fruit of cooperation with XEmacs, but of
cooperation between an AUCTeX-and-XEmacs user and the AUCTeX
developers. But we had no clue what you were doing. That was Uwe's
task, to keep track, but he probably wasn't aware of the significance
of the changes Nix was making.
Uwe came on the AUCTeX board long after Nix did his changes to
preview-latex. He packaged AUCTeX-11.5x after a reasonable and expected
amount of effort. Then preview-latex was pulled in, and it was quite a
different ballpark. And Uwe had no resources preallocated for that kind
of work, and he got little enough help from the XEmacs team. Perhaps he
did not ask the right persons or right questions. And I do seem to
remember that he tried finding people to help him and failed.
So the gist is that Uwe did the work that he set out to do and had been
planning to do. And we had nobody else willing to pick up or work on
the additional complications when we decided that preview-latex should
get integrated.
And so at some point of time we could either pick up the breakage
ourselves and do something for catering for XEmacs, or drop XEmacs
support altogether. 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.
Closer cooperation between the core of XEmacs development and that
of
AUCTeX would surely have sped up the process of getting to where we
are today.
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.
When did you get in our way? I certainly haven't noticed AUCTeX
in my
way. Personally I have this problem that I respond to your posts in
unproductive ways, but that's not AUCTeX-specific.
I doubt I would bother posting if it weren't for AUCTeX. Sure, I tend
to rant wherever I am subscribed, but without AUCTeX, I would not be
subscribed here.
> 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.
That's a strange thing to say. Presumably, the configuration on which
you run functional tests *is* the XEmacs package configuration.
No. It is what _our_ packaging system produces. And there are quite a
few Lisp files generated in the course of that production, including
autostart files and such stuff. That those don't make it into your CVS
tree is one of the problems for getting a working configuration.
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. Replicating this autolocation magic
without actually using the files we generate is a lot of work.
And this replication of work, which is able to tweak a basically
system-dependent framework so much around that it works on arbitrary
platforms, is not trivial.
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.
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.
--
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
1:02 a.m.
New subject: 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
7:31 a.m.
New subject: 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
5784
days inactive
5786
days old
3 comments
2 participants
participants (2)
-
David Kastrup -
Stephen J. Turnbull