Re: Need some bug/version info

David> As far as I can see, the main symptom would be random core David> dumps. I don't think that people will assign the blame to David> AUCTeX for core dumps. If they only occur (in their experience) while using AUCTeX they will. That's been my experience, anyway. On c.e.x I occasionally have to explain to users that "no, a crash is _never_ the fault of the Lisp program, it's always the fault of XEmacs itself." And you point out that issue yourself later in your post. David> But you would be doing a disservice to your users by David> pretending this matter is even close to being dealt with David> responsibly if AUCTeX refuses to load. Nobody is pretending anything; I'm simply saying what I think AUCTeX should do if it wants to help protect AUCTeX+XEmacs users from a crash that AUCTeX is not responsible for, and protect AUCTeX from "guilt by association". David> So my take on this matter is that we will _not_ change our David> code in the above way _unless_ there is an _official_ call David> of the XEmacs development team to _all_ package developers David> to do this. I think that should normally be a sufficient condition for you to do it, but why are you making it necessary? AUCTeX is simply the highest-risk application (I am not seeing crash reports about 21.4.16, except from you), therefore AUCTeX _might_ want to go further than other applications in warning about that XEmacs version. David> Such a call would probably only make sense in connection David> with a _general_ warning about that XEmacs release (which David> is supposed to be in the stable series). Please be more careful in your phrasing. The series _is_ stable, and has been since well before it was officially promoted from "gamma". It may not be as stable as GNU Emacs release, but based on following emacs-devel for many months I assure you that over the period that you have been publically (eg on comp.emacs.xemacs) recommending use of GNU Emacs CVS with AUCTeX and preview-latex, XEmacs 21.4 has been far more stable than GNU Emacs CVS. We did what we could. It is appropriate for Vin to take responsibility as he did, but Ben (who made the port of his design as difficult as possible without resorting to assembler) and I (who did the port incorrectly) introduced the bug. However, the buggy code did pass over 300 regression tests (specifically for regexps; altogether XEmacs 21.4.16 passed nearly 12,000 tests, the entire suite repeated on a variety of platforms in various configurations before release), and was used for several weeks by several testers, including those who reported the regexp bug triggered by Gnus that made putting the code into production high priority. Ie, the code got into 21.4.16 because several beta testers used it intensively for a couple weeks, it fixed one Gnus problem (though it then introduced another), and no regressions were observed. Obviously, they are not heavy AUCTeX users, since AUCTeX (at least CVS version) is insta-crash with that release. But we stuck the fork in, and it was done. What would you have done, David? Yes, it does make sense to deprecate the release (== announce it contains a fatal bug that manifests in a very important application), but two months after release really it's too late to withdraw it in the sense of preventing distribution: it's not feasible to erase it from CVS. All we can do is encourage people, including distros, to upgrade promptly. David> But the proper place for such checks would really be in David> regression tests for XEmacs, not in the installation David> procedures of AUCTeX. No, it is not. Of course, those regression tests are _already_ in CVS and will be released with 21.4.17, but they can't possibly be in distributed code---we don't distribute code that fails _any_ regression tests. Unfortunately we don't have Guido's time machine. :-( I'm working on separating the regression tests from the release, as well, but this is a hard problem. David> People who are using 21.4.16 will be hosed also without David> using AUCTeX. Shy regexps are an integral part of XEmacs David> via regexp-opt. No, they are not being hosed without using AUCTeX. The release has been out for two months, and Gnus users are somewhat happy because one bug was fixed (although fixing it unmasked an infloop) while no crashes are being reported except from the AUCTeX developers. Basically, the only likely candidates for a crash are those apps that loop over a set of regexps, and in the loop try to access match data that for many of the regexps doesn't exist. (There are also broken apps that don't test for success of a match before accessing the match data, but I doubt AUCTeX does that.) I think font-lock satisfies the "loop over regexps" part of that description, but it doesn't crash or infloop in general. Gnus apparently both loops and accesses non-existent slots in the match-data, but rather than crash it infloops, which is usually much less serious. So AUCTeX is doing something unusual, and is at unusually high risk. David> It does not make sense to make AUCTeX the poster child for David> telling this to people. That is of course your decision, but my mileage varies. David> This XEmacs version must not get put on _any_ software David> distribution intended to be stable since XEmacs' operation David> as a whole is affected, That is neither your decision nor ours, but we are warning the distributors we are in contact with. David> and it is beyond the power of the AUCTeX developers to tell David> distributors "don't use 21.4.16", If "tell" means "command", it's beyond our power, too: XEmacs is free software, distributed "as is", NO WARRANTY, etc, etc. If "tell" means "inform", then it is within your power, too, and I would hope that you have close contact with downstream vendors who provide AUCTeX in .deb or RPM format, and warn them. After all, if the analysis above is correct, it's your users, more than anyone else, who will suffer if you don't. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.