Re: Emacs 31 release-blocking bugs

Eli Zaretskii [29/Jul  4:33pm +03] wrote:
> Btw, we can manage this by using the "blocking" feature of Debbugs,
> see the "RELEASE-BLOCKING BUGS" section in admin/release-process.

Yes, good idea.  I'll wait for Michael to create the tracking bug then
do that, with those that are remaining at this point.

>> - #81038 31.0.50; In org-mode, unfill-paragraph doesn't work at the very
>>    end of a paragraph
>
> Is this due to some change in Emacs 31?  If so, which change?

unfill-paragraph is new in Emacs 31.

>> - #81077 31.0.60; Sometimes only upper parts of text are unexpectedly
>>    displayed
>
> What are we supposed to do about this?  AFAIU, we don't really
> understand why the problem happens, and why it happens to so few
> users.

We know what change introduced the problem and we have proposed fixes on
the table, so the situation doesn't seem to me as bad as you describe?

>> - #81105 32.0.50; installed ELPA package info missing on some distros
>>    after commit 7c22a7d
>
> IMO, this is not serious enough, as an easy workaround exists, and a
> comprehensive solution is not easy.

That's fine with me.

>> - #81151 32.0.50; Make c-ts-mode-indent-style work with setopt-local
>
> I don't think this is a regression in Emacs 31.

I can't reproduce it with Emacs 30.

>> - #81213 31.0.90; Package list is colorized after upgrading packages
>
> A simple fix for this one is to remove the code which highlights
> packages in color.

That's fine with me.  Philip has said he'll take a look soon.

>> - #81424 32.0.50; Build time dependency on TeX
>
> This problem doesn't exist on the emacs-31 branch, only on master.

Ack.

>> - #81460 31.0.90; tsx-ts-mode matches html tag's opening < with > in
>>    arrow function =>
>
> Is this really new in Emacs 31?

I can't test it because I don't have any tree sitter stuff installed.
Could you?

>> - #81490 32.0.50; wrong-type-argument internal to package-install
>
> This is said to be a problem only on the master branch.

Ack.

>> - #81503 32.0.50; crash/assert in garbage_collect
>
> I very much doubt we can do anything with this report, since the
> problem happened in a very special and complicated scenario (client
> frames, suspend/resume events, a problem with the minibuffer resolved
> by some manual action).

Fine with me to drop it.

-- 
Sean Whitton