From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Some experience with the igc branch Date: Thu, 26 Dec 2024 18:13:52 +0200 Message-ID: <86o70yxvzz.fsf@gnu.org> References: <87o713wwsi.fsf@telefonica.net> <86o7112rnq.fsf@gnu.org> <867c7p2nz4.fsf@gnu.org> <87y104aih6.fsf@protonmail.com> <87ikr89gyp.fsf@protonmail.com> <87jzbn8zmu.fsf@protonmail.com> <86msgizynv.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13136"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, pipcet@protonmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 26 17:14:37 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tQqVR-0003H6-EB for ged-emacs-devel@m.gmane-mx.org; Thu, 26 Dec 2024 17:14:37 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQqV0-0006qH-On; Thu, 26 Dec 2024 11:14:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tQqUz-0006pv-96 for emacs-devel@gnu.org; Thu, 26 Dec 2024 11:14:09 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tQqUy-0004ez-BC; Thu, 26 Dec 2024 11:14:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=rgNsWa7tJtrGMGyF7UARi8P1WxVcq1whEuq0LYwvFAA=; b=bopKkm/pVGua TGs2AsL9qwlMz1SkMwqMui9s1Ayf5K2hBndxip71jyILmWrYd8LoI7lVFYNzxxLRgHjmkLmC5HPYF WdLVCqZ8kbjShUVrhwC6d1EjzRIKpoWfqF9/+B0vpRaSby9N2AD2N8hh8mB/jNGpW0qNE0vGMwrXl 94DlUdoEAff1LVl8FyK+DmpIJu5GNelNwxkYRkk5NbmVLprvEVX+rqZ9/1Ox4/WUKr/CfCbQkk22v xd4GvjJOOhjJEqOwudgZpQ3DECVEMsFV1Jk1KEHF1eRkGRBvIZRbxsH7PArobbWR6/CMk2H3lRdyO XXZ9UnuD0NsdMNk09KWdYg==; In-Reply-To: (message from Stefan Kangas on Thu, 26 Dec 2024 15:50:38 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:327161 Archived-At: > From: Stefan Kangas > 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 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.