Re: Some experience with the igc branch

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>   ofv@wanadoo.es,  emacs-devel@gnu.org,  eller.helmut@gmail.com,
>   acorallo@gnu.org
> Date: Thu, 26 Dec 2024 06:22:17 +0100
> 
> I'm coming to all this from a completely different angle. My
> understanding is (1) the signal handling/MPS thing, is the only thing
> preventing landing in master

That's not so.  It is not the only thing we need to figure out and
solve before we can consider landing this on master.  At the very
least, we have unresolved issues with patches to MPS for some
platforms, whereby we considered forking MPS or some other course of
actions.  Also, there are several FIXMEs in igc.c itself.  For the
MS-Windows build, we have the issue of registering some threads with
MPS (see our discussion Re: "MPS: w32 threads" back in May).  So we
still have a way to go.

> My approach is "focus!" :-). Get a signal handling/MPS thing into igc
> that is good enough to be accepted, land in master, and only then
> proceed with anything else that has come up.

The "focus!" approach is correct, IMO, but landing the feature on
master is only possible if we believe the branch is stable enough,
because there are enough people who use master for production to
consider its being reasonably stable a necessary requirement.  I
believe we still have unresolved reports about freezes on GNU/Linux,
so we are not there yet.  I also don't have a clear idea of which
Emacs configurations (in terms of toolkits, PGTK yes/no,
native-compilation yes/no, etc.) were or are being tested on
GNU/Linux -- this is also relevant to assessing the stability.