From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: Merging release branch Date: Sat, 30 Oct 2021 22:32:02 +0200 Message-ID: <87wnlukyyi.fsf@gnu.org> References: <87bl37vg9l.fsf@gnus.org> <87y26bu0ih.fsf@gnus.org> <878ryaspqg.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2932"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.4; emacs 29.0.50 Cc: Glenn Morris , Lars Ingebrigtsen , Stefan Kangas , Stefan Monnier , emacs-devel@gnu.org To: Daniel =?utf-8?Q?Mart=C3=ADn?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 30 23:04:07 2021 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 1mgvWI-0000Tl-UG for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Oct 2021 23:04:07 +0200 Original-Received: from localhost ([::1]:42952 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mgvWH-0006ig-6U for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Oct 2021 17:04:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38152) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mgvVM-00061z-LT for emacs-devel@gnu.org; Sat, 30 Oct 2021 17:03:08 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34126) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mgvVK-0000YS-Vp; Sat, 30 Oct 2021 17:03:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-reply-to:Date:Subject:To:From: References; bh=6OOfn6TManL/ifEMa9gUO26o8VXEGJV5Prx0Fai4MsE=; b=O81U1CWP9o/pxY +Lu7005Eo3hOzmJQJQwnv+z9L9/ZTzi841pzJG37Twk2HTTTmNk0oLekhwm0u+zZ4Pq1gSzEe1GqK /R05gshSLMi7F6HZnQymAviDc5a5oFgXgqxanj1DQy5j5NJWgqcUGUmV5YQGJKzZvAowqObgT3tjJ ESipEW8cxDij943L6KMsxNGlQB6HLlfEv22FFUd/RG07B9LTRjBylFe769ZXS/8ZAKqEcspU3jtsD zz97nad2/Cx4zSLURbVVb1DQLq/jaTWoAxUen9eWv49PG3My7W/VSHG2XjvF/Rr6BAbZKQGFZjmYf fTrU57E+v0jBcT5pFe5A==; Original-Received: from auth2-smtp.messagingengine.com ([66.111.4.228]:57175) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mgvVK-00036s-9k; Sat, 30 Oct 2021 17:03:06 -0400 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id BE6CB27C0054; Sat, 30 Oct 2021 17:03:05 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sat, 30 Oct 2021 17:03:05 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdegjedgudehgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpehffgfhvffuffgjkfggtgfgsehtqhertddtreejnecuhfhrohhmpefvrghs shhilhhoucfjohhrnhcuoehtshguhhesghhnuhdrohhrgheqnecuggftrfgrthhtvghrnh epiedugffhhfejveevvdfhffegteelleejffefgefgueeggeelheefieeujefhheegnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhrnh domhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqkeeijeefkeejkeegqdeifeeh vdelkedqthhsughhpeepghhnuhdrohhrghesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 30 Oct 2021 17:03:03 -0400 (EDT) In-reply-to: X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:278292 Archived-At: Daniel Mart=C3=ADn writes: > TBH, I don't think there's a "silver bullet" workflow, it depends on > the project, the participants, etc. I presented some downsides of > mine as well, so you can decide if the trade-offs would make it less > time-consuming than the current one. I suspect some of those > trade-offs are "invisible" until the workflow is put into practice and > given some time. That's true. As an anecdote: we've tried a cherry-pick-based workflow at my dayjob for some period. Basically, (for each released and still supported version) we've had a "pending", and a "release" branch. Developers committed their fixes in the "pending" branch where the QA would test them. If the test was successful, the commit(s) where cherry-picked into the "release" branch. I can report that it didn't work out well. Things that happend quite often were: - Some ticket had N commits but only N-M (M > 0) commits were cherry-picked. And once you notice something's wrong, you have to go and diff diffs to find out which one is missing since the question has turned from "is commit 18a9ef4 reachable from this branch's HEAD" to "is there some commit with the same message and same diff"? - The compile/CI broke because the cherry-picked commit X required stuff of commit Y which has not yet been cherry-picked because Y's test took longer than X's (or X has been prioritized over Y). - Same as the last bullet point but worse: the compile still worked but the runtime behavior was wrong. So in general, my gut feeling is that merging is preferable over cherry-picking. Even more so if the time between initial commit and cherry-pick can become longer. A policy which makes sense would be (as Stefan M. suggested, I think): if you commit in emacs-, immediately do a merge into master afterwards (with -s ours if the fix is not appropriate for master). Bye, Tassilo