From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: Some experience with the igc branch Date: Thu, 26 Dec 2024 15:50:38 +0000 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5717"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@protonmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org To: Eli Zaretskii , =?UTF-8?Q?Gerd_M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 26 16:51:16 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 1tQq8q-0001KG-CB for ged-emacs-devel@m.gmane-mx.org; Thu, 26 Dec 2024 16:51:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQq8L-00026R-AC; Thu, 26 Dec 2024 10:50:45 -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 1tQq8J-00026D-Rp for emacs-devel@gnu.org; Thu, 26 Dec 2024 10:50:43 -0500 Original-Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tQq8I-0001vM-3v; Thu, 26 Dec 2024 10:50:43 -0500 Original-Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-5d7e3f1fdafso12968773a12.0; Thu, 26 Dec 2024 07:50:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735228239; x=1735833039; darn=gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=d9LUsfK194DTu97L4y4tENU2eHBxfL7/wlNJt7BHdWo=; b=XP5bqJ/cRV2GNwTejDRoXJ7xJ76lW9nr3sJtC8dqTjNaqyPl8gX04tFn4JmVaJREIO Z+EaZFKeuNF+SFfRd6euuD+tA+DM528NJdsPo/UK7W6t70rHL0djsrbSM6H2In6vki/6 AXJnFQQO1EcOqyvWrqQvr/8Mfi8plAO2RywNtpX9/yrzlMDYcyQhTBbGd6RgqwY3grRf HbI8QnPycFavZDKUz+53EMmLgDU8mCZtViBLwh+SUfZLGFolHqF7QA/1dSsqmHaI1y8z Q8vCFxFeVac3Eni6lBkuZFIve8yZVbSfB1u2jXURYWtxr6/sPDLvbLdLuIsR5j02e9i/ xkGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735228239; x=1735833039; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=d9LUsfK194DTu97L4y4tENU2eHBxfL7/wlNJt7BHdWo=; b=hR1pWno9r+x2UF9elzm/vJcn8sTu6/g8fuC9ZN7tdkqbSVwKBK2s0anjaoqK2N2EIw WrRQkNud6OlTgCaMH+ivLgYuRPZNzY4j2emeH0v1HSWTXlhsh5zGsKLJxUlhVSSFDdXY ZGF1b+n1uHM5RBRi2Zo/WBMVGrnPW/J6Top7R80ZhlwctrjPLa+IHQsIPYVeCHM7a//o gdugY7PPIWY7fbIk7D41yk3gjWPhUYqpGunMlEXcztfPnGD7PYfs3d//JxCk8E9tEvO7 oKyK3wJ3RpVRJs4YHlQqEi2pOdaTm4rzVqcE20CSd3L9Iz4/MGrjlgtaKmdkOCX7IU0X pNMg== X-Forwarded-Encrypted: i=1; AJvYcCUdCYGdBdvm23C0/oUjhfd5wBbwhs0fuZNMNdC8uCM+F1IX/2RzdDE+COUIRS44qwFfG7zgndfWCQ==@gnu.org, AJvYcCVvRNO2atBAvvHCI6Q37pS6WZTVXIY70SlB4+HpSrXzPrX2J0EEBmfbM2P6UXyscl0/i5y3LPz+RipcuPI=@gnu.org X-Gm-Message-State: AOJu0YyInlWR+5aIcRGtnygdbw/SHHuAgjB5kMl7H1Hl+1PEAA21CK9t 8y9I/dFqCDj2EfVwngKH9xQiVcalO0H15m9u1IgyiWWVAwGI9XzC1FA9oYNQyKaN6udHYG3pv3u 0yzWCIOCE3mgI/a8uE3x2JIKWn/hOaeqX X-Gm-Gg: ASbGncuE7rXiRba5VuT4xba8r9KF7BuBjyo4ODzR4LcItwxSEcmhPzT0zNk7tuU+5fG XouEoF+vmQwD7CglnzueghKrwZoe6WCdQOpEGZ/w= X-Google-Smtp-Source: AGHT+IHwOe/I+frbuXQTP2a37wAV819GPLcL4aoRINa+AKCk5upWT/lWvUCxsmYfoW2bFFzqTQCzxLSVwWQbLi506+U= X-Received: by 2002:a05:6402:35c5:b0:5d3:ba42:e9d6 with SMTP id 4fb4d7f45d1cf-5d81dde87bbmr15390256a12.17.1735228239113; Thu, 26 Dec 2024 07:50:39 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 26 Dec 2024 15:50:38 +0000 In-Reply-To: <86msgizynv.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::534; envelope-from=stefankangas@gmail.com; helo=mail-ed1-x534.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:327156 Archived-At: 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? > 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).