* David Kastrup (2007-01-27) writes: > Cc to auctex-devel. > > "Stephen J. Turnbull" <[EMAIL PROTECTED]> 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 _______________________________________________ auctex-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/auctex-devel
