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: MPS: Win64 testers? Date: Wed, 31 Jul 2024 17:02:18 +0300 Message-ID: <86ikwly80l.fsf@gnu.org> References: <867cd61412.fsf@gnu.org> <86y15lzjg6.fsf@gnu.org> <86ttg9zgpb.fsf@gnu.org> <86h6c8zbh8.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1255"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, rms@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jul 31 16:03:44 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 1sZ9vc-000091-2v for ged-emacs-devel@m.gmane-mx.org; Wed, 31 Jul 2024 16:03:44 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sZ9ud-00080J-S7; Wed, 31 Jul 2024 10:02:43 -0400 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 1sZ9ud-0007wj-0R for emacs-devel@gnu.org; Wed, 31 Jul 2024 10:02:43 -0400 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 1sZ9uc-0003D4-AT; Wed, 31 Jul 2024 10:02:42 -0400 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=NSUC0NXtwBwObH9uj0IKJ5Ob68w5QoO6QejbISTI+KQ=; b=PG3ho3iag4IU i5P/h55oS4MzaOI2e31GRt6ux5Kt6OVZ3RP1NxjKZKfVxO8i31F9XlKwm9w0nNgUNvP0l6CO7vHmV tyVJfk7dR+kiZbu73e9rjzeWq0tKXciYPdKrvZRhHBDPoPL3wV1KgUr74BV3KKnMpMMWdI+zt8o87 hBmqMXbW2Kc3DcD9867HpgmcJdnlGZAnEbOplfTf0UtrUrGDTdIVA4dhJ2sEvPqcTROUl6ljC+sm8 Eu9FVJ1ZPAFWJWpkFyxiLndqed5AVYrEQ6CTb73JYLwtN/xDlTz9Fn0s9ezEO8tmVNXQTwZBnXsvs Yuagup3gUg1c0+hpuGbWVw==; In-Reply-To: (message from Pip Cet on Wed, 31 Jul 2024 06:18:16 +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:322228 Archived-At: > Date: Wed, 31 Jul 2024 06:18:16 +0000 > From: Pip Cet > Cc: emacs-devel@gnu.org, rms@gnu.org > > > Thanks, but this is just a first small step in the right direction. > > We need this verified with Emacs, not a small separate test program, > > and we need then some serious testing of whatever solution we decide > > to implement. > > I think the bar is slightly lower than that: the code in Emacs is clearly buggy, because it relies on strange and peculiar implementation details that go far beyond anything guaranteed by the API (and that may break at any point on new systems). Replacing it is necessary. I disagree. > > All of that requires a volunteer who will take upon > > him/herself to implement and test the possible solutions on the actual > > platform, and then maintaining that and the rest of UCRT-specific > > stuff for some reasonably observable future. > > This isn't UCRT-specific, and, as far as I'm concerned, "the actual platform" is Wine, not Microsoft Windows. If a UCRT build works on wine, it's quite likely to work on Microsoft Windows machines, too. Not relevant to the requirement of having a dedicated support person. > > IOW, this needs a > > dedicated support person. > > That's desirable, yes, but hardly necessary. I disagree, and that's not for you to decide, with all due respect. > There's a difference between fixing obvious bugs that will prevent builds from ever working and deciding a platform is "officially" supported. This bug is far from "obvious", and finding a fix for it that will do what the original code does requires non-trivial testing. Until that is done, I don't trust the proposed solution (and it was not a complete proposal anyway). > FWIW, I've tested my UCRT build on Microsoft's proprietary Windows, briefly, and it starts up and appears to work. However, I cannot do so on a regular basis. I know. Neither can I. Which is why the basic requirement to have a dedicated support person on board still stands. > > The community of Emacs developers cannot allocate resources that don't > > exist. And even when they do exist, the ability of the community to > > redirect those resources is limited by the opinions and limitations of > > the people whose resources need to be redirected. > > One thing we can certainly stop doing is to discourage people from even looking at stuff. Closing actual bugs as "wontfix" without a sensible explanation, for example, seems counterproductive to me. Which bugs where "closed as wontfix without a sensible explanation"? > > I'm using MinGW and don't intend to install MinGW64 any time soon. > > Maybe it's time to make that port unofficial, or at least to stop directing people to it rather than the MinGW64 port. We have been advertising MinGW64 (with MSVCRT) for a long time, see nt/INSTALL.W64. But since it doesn't support Windows versions older than Vista (or maybe even that is not supported anymore), we also advertise MinGW, which does.