10:33 a.m.
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. 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.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:47 a.m.
New subject: Fwd: sign off on XEmacs 21.5
"Stephen J. Turnbull" <stephen(a)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
and elusive.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
8:24 p.m.
New subject: Fwd: sign off on XEmacs 21.5
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
David Kastrup writes:
[Context:]
>>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.
Stop trolling, David. Of course it's not acrimonious and frustrating
that you provided users with a solution.
Fine. So do tell what "acrimony" and "frustration" was caused by our
"package" surprisingly popping up years after somebody bothered updating
the XEmacs package in Sumo.
What you are saying is that several more unacrimonious and unfrustrating
years could have passed without XEmacs users having an option for using
an uptodate AUCTeX. Or using preview-latex at all. We supported XEmacs
on preview-latex since 2002. There still is no preview-latex available
as an official XEmacs package.
So if we had spared you the acrimony and frustration of an unofficial
XEmacs "package", XEmacs users would have been spared 6 years of being
able to install preview-latex.
It is my persuasion that the XEmacs project priorities are utterly
messed up if that's what you find desirable.
Even if the target were to shut down XEmacs development gracefully, this
approach fails on the "graceful" angle if nothing else. Which may
entirely be my fault since I am too stupid to understand what is going
on. I still don't get it.
And my self-confidence depends enough on my intelligence that I am not
pleasant company when I feel like a complete idiot missing the obvious.
--
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
5973
days inactive
5973
days old
2 comments
2 participants
participants (2)
-
David Kastrup -
Stephen J. Turnbull