Re: Some experience with the igc branch

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

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

Hm. If my assumption (1) is not true, I think it's best for me to just
wait and do my other stuff meanwhile.