[AUCTeX-devel] Re: [comp.emacs.xemacs] AUCTeX 11.84 released

[Stephen J. Turnbull]

Ralf Angeli writes:

 > 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.

I've already announced my intention to do that.  I gather you're not
aware of that?

However, the issue of the addresses was discussed with Uwe Brauer when
he volunteered, who indicated at the time that we should point our
auctex-* aliases at AUCTeX.  That may have been an uninformed
decision, but at the time we believe that it would be possible to have
an up-to-date package without too much trouble.

However, if this is so annoying to you, there must be lots of them.
I'm curious, why aren't those users coming to XEmacs?  Don't you tell
them what the right place to report bugs is?  Or what?

 > 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).

What don't you understand?  That users like the convenience of the
packages for updates when available, and of the SUMOs for initial
installation?  Well, let me tell you: users like the convenience of
the packages for updates when available, and of the SUMOs for initial
installation.  Or don't you understand that our resources for updates
are finite and mostly user-contributed, thus there are lags?  Well,
let me tell you: our resources for updates are finite and mostly
user-contributed, thus there are lags.

I'm really tired of repeating those facts.  Yes, I know that this
thread just started on AUCTeX.  But surely you can see the 13
References that preceded your post as well as I can?

Nor is it like Debian stable or even Fedora core manages to keep all
of its packages up to the minute.  Or GNU Emacs, for that matter,
except when it can absorb an upstream package so that the Emacs
version *is* the current version by definition.  *All* distros make
this compromise.

As for AUCTeX in particular, you quoted the reason already:

 >>> AUCTeX is free software.  Uwe Brauer, who maintains the XEmacs
 >>> package of AUCTeX, values an XEmacs package enough to do the work

In addition, I'm happy enough with the AUCTeX we've got for my own
use.

 > It sheds a bad light on their package system

If so, why aren't we hearing that from our users?  What we hear from
the users is that they like packages, and the ones who want an
up-to-date AUCTeX get it from AUCTeX.  Win-win, as far as I can see.

The fact is that the only people who complain about the XEmacs package
system in general are upstream package developers.  Of course users
whose favorite package is out-of-date report it as a bug, but they
rarely get very upset when offered the choice of maintaining the
XEmacs package or maintaining their own installation of upstream by
hand.  There are some clumsy aspects, those are bugs too---but that
doesn't stop most users from using the package system.

 > In addition it leads to the constant stream of unpleasent
 > discussions we've seen around the AUCTeX package.

It doesn't.  The unpleasantness is entirely due to personality
conflicts.  The ESS package has very similar technical issues, and the
current maintainer there decided to withdraw the package.  Of course
things were a little tense because of the goal conflict, but basically
the relationship has been amicable and the discussions productive.
And there are others in that project who disagree with the current
maintainer; I'm sure something will be worked out when resources
become available.

That happened a while ago, but a related thread happened this week,
too.

AUCTeX doesn't have that option because AUCTeX refuses to help with
the XEmacs package (as we define it; I know you have something that
unpacks into the same places, but it doesn't serve *our* goals), and
AFAIK the XEmacs maintainer wishes to keep trying to update the AUCTeX
package.  Someday we'll succeed.

 > So the XEmacs project could _at least_ change the support
 > addresses.

Please.  AFAI knew, Uwe was considered part of the AUCTeX project.  He
didn't ask for a change, so the aliases didn't change.  *You* didn't
explicitly ask for a change, either.  Not that I know of.  Don't say
it should be obvious; it wasn't, especially not in the midst of the
firestorm that David enters the XEmacs lists with almost every time.

So, I've changed the aliases.  Fixing addresses in the package itself
will have to wait a day or so.

 > If they feel they cannot provide sufficient support for a package
 > they distribute as an outdated version, they should consider
 > refraining from distributing it.

*We get no bug reports from users.*  It's as simple as that.  If and
when we start getting bug reports, there will be something to consider.

 > 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.

We've had that forever.  It's clumsy, you can only have one site
active at a time AFAICT, and the interface for users to add sites is
undocumented (AFAIK).  I've already proposed fixing that, too, in this
thread.  It's technically not that hard, I think.  A major overhaul of
the package UI almost happened 3 years ago, but Steve Youngs wanted to
do it his way, then it never got done.

 > implementing such a feature is likely not economically sensible
 > because I doubt there are many XEmacs packages built outside of the
 > XEmacs project.

I'm sure several would be, actually.  VM already is.  x-symbol would
be (unless upstream has abandoned it).  If the facility were
available, I suspect several projects would want to do it; it's not
like the typical DESTDIR install would be very hard.

One problem is that that kind of sensible, everybody-wins suggestion
has rarely been made.