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.bugs Subject: bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed. Date: Tue, 11 Jan 2022 14:27:14 +0200 Message-ID: <83bl0i8nkt.fsf@gnu.org> References: <83v8yr8o0t.fsf@gnu.org> <83ilur8j0f.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37771"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 53164@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 11 13:28:15 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1n7GG7-0009gd-8Q for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 11 Jan 2022 13:28:15 +0100 Original-Received: from localhost ([::1]:42876 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n7GG6-0003xC-2Z for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 11 Jan 2022 07:28:14 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:42374) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7GFu-0003vk-BM for bug-gnu-emacs@gnu.org; Tue, 11 Jan 2022 07:28:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33203) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n7GFt-0007i3-V6 for bug-gnu-emacs@gnu.org; Tue, 11 Jan 2022 07:28:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n7GFt-0008L2-SY for bug-gnu-emacs@gnu.org; Tue, 11 Jan 2022 07:28:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Jan 2022 12:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53164 X-GNU-PR-Package: emacs Original-Received: via spool by 53164-submit@debbugs.gnu.org id=B53164.164190404932009 (code B ref 53164); Tue, 11 Jan 2022 12:28:01 +0000 Original-Received: (at 53164) by debbugs.gnu.org; 11 Jan 2022 12:27:29 +0000 Original-Received: from localhost ([127.0.0.1]:54339 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n7GFM-0008KC-Na for submit@debbugs.gnu.org; Tue, 11 Jan 2022 07:27:29 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:41442) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n7GFL-0008Js-2l for 53164@debbugs.gnu.org; Tue, 11 Jan 2022 07:27:28 -0500 Original-Received: from [2001:470:142:3::e] (port=44440 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7GFF-0007an-OY; Tue, 11 Jan 2022 07:27:21 -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=7FmkLuR5zNOc3EAb9iLCU3PAF+2ZYt0pa+BhRCPB+do=; b=OXzoU6DeBRIG e6IKeT8Kz9mBh26by/4/D9yapHvPrsMdtEFHUBs0rAGS+B/sXgfG+a1LgTctFPXsc9h4ULXRTwqVE TMPE7bdF2gk2IjMej7Y2ZoXzlqrZABwNhWb5cj5A30rWatwJLNOHoCSmBKX6U9QKGOJA5WgVGGVaS ednSa2tGGmYAw2h+YxSqtw/rBfz/70Eh9Fz5RkGw/fgAMemmRV/5yfnJ0SN4Zlf5rTJHLQApxzLFa N5bzCXkeIQ02IWh1hVBlhOydUg2Cm6grYvS0Kf1gT4Ev02nKHOf9G/5NLFJmYlyigeZ4bVQ/Cwy95 ABJsdlecenUzTxGoOmMdNw==; Original-Received: from [87.69.77.57] (port=3234 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7GFF-0002dz-PJ; Tue, 11 Jan 2022 07:27:22 -0500 In-Reply-To: (message from Alan Mackenzie on Mon, 10 Jan 2022 20:21:40 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:223933 Archived-At: > Date: Mon, 10 Jan 2022 20:21:40 +0000 > Cc: 53164@debbugs.gnu.org, acm@muc.de > From: Alan Mackenzie > > > After reading this, I still don't understand how come you bump into > > this problem, whereas I don't, and neither does anyone else who builds > > the release branch with native-compilation. Is this something > > specific to that branch you are working on? > > Indeed, yes. It is the symbols with position which escaped from a > compiler macro. > > > If so, why is it urgent to have the fix on the release branch? The > > branch on which you ware working will land on master. > > There was no urgency. I though the convention was for documentation > fixes and simple safe code fixes to go onto the release branch. The fix > to this bug, a single line, is well understood and certainly comes into > the category of simple and safe. The fix is well understood, but its possible effects aren't. We have been using the current code for more than a year with no problems whatsoever. > > There's always one more bug. When we are so far into the pretest > > process, problems that take unusual steps to reproduce are not > > important enough to delay the release. > > OK. But can I ask you to consider announcing on emacs-devel when the > criteria for making bug fixes on the release branch change? Apologies if > you have done, and I missed it. This is in CONTRIBUTE: If you are fixing a bug that exists in the current release, you should generally commit it to the release branch; it will be merged to the master branch later by the gitmerge function. However, when the release branch is for Emacs version NN.2 and later, or when it is for Emacs version NN.1 that is in the very last stages of its pretest, that branch is considered to be in a feature freeze: only bug fixes that are "safe" or are fixing major problems should go to the release branch, the rest should be committed to the master branch. This is so to avoid destabilizing the next Emacs release. If you are unsure whether your bug fix is "safe" enough for the release branch, ask on the emacs-devel mailing list. > There're three ways we could go. Commit it in emacs-28, master, or > scratch/correct-warning-pos. I'm willing to commit it again in any of > these places. Please install this on master (or leave it on your branch), and we will revisit this when time comes for Emacs 28.2. Thanks.