Re: [comp.emacs.xemacs] AUCTeX 11.84 released
* David Kastrup (2007-01-27) writes:
Cc to auctex-devel.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> Olivier Galibert writes:
>
> > As for the AUCTeX problem, legalities aside, it looks like we're
> > distributing it against the wishes of (one of|the) main maintainer.
> > Shouldn't we just stop?
>
> Hey, that applies to distributing XEmacs itself. Shouldn't we just
> stop? I don't think so.
Since the version distributed with the XEmacs package collection is
unsupported upstream, one could conclude that the XEmacs project is
taking care of support for that version. In that case you should at
least add a disclaimer of the different support address and change the
bug reporting address.
> AUCTeX is free software. Uwe Brauer, who maintains the XEmacs
package
> of AUCTeX, values an XEmacs package enough to do the work and put up
> with both me and David Kastrup (who has publically insulted Uwe on a
> number of occasions).
You better back this up with an actual message id.
I don't remember an insult either.
I think we should just declare XEmacs a non-goal for AUCTeX and
either
removing all XEmacs support or declare it open for bit rot. It is
worse than just a thankless job tieing up a considerable amount of
resources. It is not just that we don't get any thanks for the work
we invest, but also all kinds of abuse.
My experience with the XEmacs lists obviously differs from yours. I
haven't got an answer to some of the bug reports and inquiries I've
sent, but when I got an answer, discussion was mostly helpful and
constructive. Of course, there were also cases which could not be
dealt with due to lack of resources.
Apart from that I don't really understand why the XEmacs project is
distributing an outdated version of AUCTeX (or any other package for
that matter). It sheds a bad light on their package system and
renders it useless to some extent. In addition it leads to the
constant stream of unpleasent discussions we've seen around the AUCTeX
package. And it exhibits ignorance towards upstream developers who
have to deal with reports of bugs which have long been fixed in more
recent upstream versions. So the XEmacs project could _at least_
change the support addresses. If they feel they cannot provide
sufficient support for a package they distribute as an outdated
version, they should consider refraining from distributing it.
The situation would be a bit better if the XEmacs package system
allowed for the inclusion of additional locations for package download
similar to something like apt. Then the argument regarding the
quality of externally built packages would be moot because users would
know that the package is not provided by the XEmacs project. But
implementing such a feature is likely not economically sensible
because I doubt there are many XEmacs packages built outside of the
XEmacs project.
Regarding the removal of XEmacs support I think we should do this only
if we consider the interest of XEmacs _users_ not significant enough
to justify the work invested in compatibility with XEmacs. I don't
consider the ignorance of the XEmacs project towards AUCTeX enough of
a reason to justify a removal of XEmacs compatibility.
As a side note: Once I'll have checked in my changes to font locking
we'll even get multi-line font locking in XEmacs which will get rid of
some inabilities of XEmacs currently documented as bugs in our
manual. So at least in this respect we are heading in the opposite
direction of your proposal.
--
Ralf
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta