Re: Some experience with the igc branch

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 26 Dec 2024 15:50:38 +0000
> Cc: pipcet@protonmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, 
> 	eller.helmut@gmail.com, acorallo@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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.
> 
> Thanks.  Should we perhaps make a list of these items somewhere, e.g. in
> README-IGC on the scratch/igc branch?

Feel free to do that, sure.

> > we have unresolved issues with patches to MPS for some platforms,
> > whereby we considered forking MPS or some other course of actions.
> 
> Forking MPS is obviously better to avoid, if at all possible.

But if we have patches that we must have there, and if the MPS folks
do not intend to accept them upstream, for some reason, then forking
is the only practical way for us.

> Do we have a complete list of these patches, or can we assemble one now?

They were mentioned in these discussions, so they are in the archives.
I don't have such a list handy, sorry (my builds of the igc branch
uses stock 1.118.0 release of MPS with a couple of patches specific to
32-bit MinGW).

> Are all of these open pull requests to Ravenbrook, so that we are in
> effect only waiting for them, or do we need to more work on our end?

I don't think we submitted the changes to Ravenbrook, with the single
exception of the one Gerd posted there.  But I'm not sure my memory is
accurate.

> > Also, there are several FIXMEs in igc.c itself.
> 
> Are all of these important enough to be considered as blockers for
> merging to master, or only some of them?

I don't know.  Maybe Gerd can answer that.

> If the latter, how about making a list of the ones that are considered
> blockers, or perhaps just marking them as such in the FIXME comment in
> the source code?

Let's first see which of those FIXMEs are important enough to worry
about them.

> > 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).
> 
> In the long run, it is highly desirable to have support for (reasonably
> modern) MS-Windows, of course.  There is no doubt about that.
> 
> But could you elaborate on why you think this is a blocker for merging
> this to master?

Because that's what I run here.  I cannot do my job if Emacs doesn't
compile and work well on MS-Windows.

> My understanding is that, from the point of view of
> GNU, we maintainers can choose to take features even if they only work
> on GNU/Linux.  They can then be made to work on other systems later.

It's semi-okay if some optional feature cannot be compiled here, but I
cannot imagine being responsible for the master branch if igc cannot
be compiled or doesn't work well on Windows, because this is a major
feature of Emacs, and any serious bugs in it must be reproducible on
my machine.

> > 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 agree that more stability and testing is always better.
> 
> However, if we have the fundamental issues worked out to such an extent
> that we can demonstrate that the MPS branch is viable, I personally
> don't consider "not enough testing" to be a blocker for merging the
> branch to master.  For example, we could put the MPS GC behind a feature
> flag, and mark it as experimental.

I don't see how it makes sense to merge a feature and mark it
experimental.  It isn't different from leaving it on a branch, IMO.

> I don't suggest that we should rush to merge or anything like that, but
> let's keep in mind the benefits of merging also: it could help lead to
> faster stabilization, as it will be easier to test than building a
> feature branch.  It will also be a clear indicator that we consider the
> basic approach to be viable enough.

If we want faster stabilization, we cannot mark it experimental.  We
need to ask people to use it.  And for that, it must be stable enough,
because people will not seriously use Emacs if it crashes many times a
day and they lose their edits.

> We will also get more testing of the combined result "for free"
> (i.e. using the old GC even in the presence of the changes needed for
> the new one).

That's much less important, IMO.