Re: Need some bug/version info

Vin Shelton <[email protected]> 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