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: Emacs 29.3 released Date: Tue, 26 Mar 2024 14:46:25 +0200 Message-ID: <865xx9jh3y.fsf@gnu.org> References: <86edbzyavw.fsf@gnu.org> <87r0fzsbxz.fsf@gmx.de> <86wmprjumv.fsf@gnu.org> <875xxbtmpp.fsf@gmx.de> <86r0fzjs9x.fsf@gnu.org> <87il199y5d.fsf@gmx.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9999"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 26 13:47:28 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 1rp6DA-0002N7-GA for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Mar 2024 13:47:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rp6CF-0000dg-6w; Tue, 26 Mar 2024 08:46:31 -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 1rp6CE-0000dT-42 for emacs-devel@gnu.org; Tue, 26 Mar 2024 08:46:30 -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 1rp6CD-000332-LV; Tue, 26 Mar 2024 08:46:29 -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=iKQqO4KHCbspqXNywBTuYj+HWp4ujy9Aaf5VaU15IqM=; b=T5e7pESQjUD6 FepBkKHUEW+OdusLdViIplz5Ggc1IlaWybncpefiZ9sTOp1jxKmpebuvO1PMoAcI3h2F7qB6VuJ3J XXKwETbxzXXE3mKISkNRUNZq31RxnDSImR/EL8h56A3g3WXQNpxMGnwbtXr9KDTagPsmNcP4zeGwe mwTPoEaxnlRYmk7q/j8OqggTzfrz+hbtKetIBs8dip+1iAQl5XhCS2OsEPYj6k7xin7GNcLjQgPVh vdsn8Gb54LsVscylszw+jgJTw+FcRYzdHZL3xW9Ool9SZ494R9OfFLLCgrq5cQAAlgvDq8Qoci9sS Gdxd6ySyTkq5ZNcjE7rV+A==; In-Reply-To: <87il199y5d.fsf@gmx.de> (message from Michael Albinus on Tue, 26 Mar 2024 09:48:30 +0100) 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:317298 Archived-At: > From: Michael Albinus > Cc: emacs-devel@gnu.org > Date: Tue, 26 Mar 2024 09:48:30 +0100 > > Eli Zaretskii writes: > > >> > How did that happen? Which change to emacs-29 branch caused that, and > >> > why was that change installed on the release branch? > >> > >> commit 115908469d30f8c40689673312f72b44c1631c6b > > > > Thanks, but why was the release branch synchronized with a pre-release > > of Tramp? > > Tramp 2.6 collects bug fixes. During pretest of Emacs 29.2, only serious > bugs, which are a regression, were merged to the emacs-29 branch. After > the Emacs 29.2 release, the current state of the tramp-2-6-stable branch > (from the Tramp git repo) was merged to the emacs-29 branch, in order to > have the other bug fixes there as well. > > This is the usual procedure Tramp applies for years. I see. FWIW, I wasn't aware of this. My mental model of the release branch is that it is ready for an immediate release at all times. Would it be possible to modify the Tramp revision on the release branch so that it would not have the "-pre" suffix, and otherwise leave intact the procedure by which you collect and merge fixes to the release branch? That would mean that if such an emergency release does happen, you then advance the Tramp version to the next one (say, from 2.6.3 to 2.6.4), and keep updating the release branch with any further fixes. If that is possible for you, I think it will be the easiest solution for the future, if we ever need to make such emergency releases again (something that I think is quite probable, given that it happened both for Emacs 28 and Emacs 29). Alternatively, we could record in make-tarball.txt the fact that such releases must be coordinated with you. From where I stand, this is less desirable (as it adds a non-trivial prerequisite for such releases, which could mean a delay if you are unavailable for some reason), but still possible. Thanks.