Re: Need some bug/version info

"Stephen J. Turnbull" <[email protected]> writes:

>>>>>> "David" == David Kastrup <[email protected]> writes:
>
>     David> As far as I can see, the main symptom would be random
>     David> core dumps.  I don't think that people will assign the
>     David> blame to AUCTeX for core dumps.
>
> If they only occur (in their experience) while using AUCTeX they
> will.  That's been my experience, anyway.

The release notes will carry prominent warnings.  We'll see whether
this is enough.  It will probably also depend on how far-spread
XEmacs-21.4.16 will turn out to be in the long run.

> 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),

Vin reported otherwise.

> 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.

Emacs CVS is not in any "stable series".  People know what they are
dealing with there.  In particular, CVS Emacs is not the standard
editor for _any_ distribution.  In contrast, XEmacs-21.4.16 is the
standard XEmacs as distributed by Debian testing, Debian unstable and
Fedora Core development.  When I recommend using CVS Emacs, I also
tell people that it _tends_ to be more stable than most of the
released Emacsen, but they need to be prepared to draw a lemon, too.

> We did what we could.

I have no doubt about that, but we were not talking about what you
could have done, but what you should _now_ do.  And Vin has answered
this to my satisfaction already.

> 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),

I already posted a list of packages that use shy groups.  Would you be
willing to guarantee that the bug does not manifest in any of them?

> 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.

Erasing one's traces is not going anywhere.  Still, it might make
sense removing the tarball from the regular distribution site and
replace it with a warning, and perhaps a pointer where it can be
gotten if people really know what they are doing.  And that is because
when people for some reason decide to go back one version, they should
in this case most likely rather go back two versions.

> All we can do is encourage people, including distros, to upgrade
> promptly.

I had the impression that Vin was already planning to deal responsibly
with that, and part of that simply includes biting the bullet and
doing what is necessary instead of wasting time bickering about what
one should not be blamed for.

Read the GPL.  It contains a "no warranty" clause.  Leave the blame
assigning game to the non-free world.

> 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.

A warning from the XEmacs developers on the respective announcement
lists would carry more weight, and Vin has already promised that.  I
have no reason to doubt him.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum