Re: Need some bug/version info

>>>>> "David" == David Kastrup <[email protected]> writes:

    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.