Re: Need some bug/version info
Vin Shelton <acs(a)xemacs.org> writes:
I don't know if you know me - I am Vin Shelton, the Release
Engineer
for the stable branch of XEmacs. Therefore, the 21.4.16 and 21.4.17
releases are my responsibility.
You raise a number of points below. I agree with the gist of your
argument: XEmacs 21.4.16 should be withdrawn and 21.4.17 should be
released as soon as possible. XEmacs 21.4.17 will be released on
February 6.
If I judge the extent of XEmacs' use of shy regexps correctly, this
appears like the responsible thing to do, even though I am lacking the
data to compare the severity to the "normal" level of regressions to
be expected.
> As far as I can see, the main symptom would be random core
dumps.
> I don't think that people will assign the blame to AUCTeX for core
> dumps.
Most of the reports have actually been of infinite loops rather than
core dumps.
"most of the reports" seems to imply that the effects were not just
from AUCTeX users.
> People who are using 21.4.16 will be hosed also without using
> AUCTeX. Shy regexps are an integral part of XEmacs via regexp-opt.
Thanks for the data of which packages use regexp-opt in a separate
post.
In case it was not apparent from the search pattern, I was looking for
_either_ regexp-opt _or_ the characteristic \\(?: sequence starting a
shy group.
Although the number of packages may seem large, my empirical
evidence is it's extremely easy to work for days without stumbling
across any problems.
Since it is an initialization problem, the longer XEmacs runs, the
less likely you are to see any bad effects. The consequences will be
most dire for batch runs and "test cases" which immediately start the
work without loading other packages. Once the session is running, the
probability for triggering the problem becomes low _except_ for
asynchronous running stuff like process filters and background font
lock, as they get fresh match data structures to work with.
I'm sure that some of the packages are more likely to tickle
this
problem than others.
Definitely.
This is a defensible position, but I don't think I agree with
it.
As I implied above, different packages can be affected quite
differently by the bug. It's possible that some packages may need
to defend themselves against broken enviroments more carefully than
other packages need to. I don't have enough data to tell for sure,
but it sounds like AUCTeX is one package that might want to defend
itself against this particular breakage in XEmacs.
If I understood this correctly, the problem in AUCTeX occured in the
context of font lock patterns, and when preparing a minimal test case.
It does not appear to me that AUCTeX would be particularly worse
affected than most other packages.
I will make a post to the xemacs-announce mailing list and will
withdraw the 21.4.16 tarballs. Do you have any suggestions for how
else to communicate the bad news about XEmacs 21.4.16 and the good
news about XEmacs 21.4.17?
I have no clue about the timelines for distributors who package
XEmacs, so the only suggestion I could add would be that it might
conveivably be a good idea to split the bad news about XEmacs 21.4.16
and the good news about XEmacs 21.4.17 into two separate
announcements, so that people will be prepared to wait for 21.4.17.
Whether such a reaction would seem exaggerated (when compared with
your normal procedures), you are in a much better position to judge
than I am. But I can't think of anything more to ask than what you
already have offered.
I apologize for the quality of the 21.4.16 release. The fault is
entirely mine.
Oh, I am quite sure we all have had our own shares of "Oh God, did we
release _that_?" experiences.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum