Re: Some experience with the igc branch

[Stefan Kangas <stefankangas@gmail.com>]

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?

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

Do we have a complete list of these patches, or can we assemble one now?
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?

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

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?

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

Maybe I'm missing something.

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

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