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: Merging release branch Date: Sat, 30 Oct 2021 15:11:06 +0300 Message-ID: <835ytepvad.fsf@gnu.org> References: <87bl37vg9l.fsf@gnus.org> <87y26bu0ih.fsf@gnus.org> <83pmrnppqy.fsf@gnu.org> <874k8yspb4.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5622"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rgm@gnu.org, stefan@marxist.se, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 30 14:11:57 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 1mgnDJ-0001Ev-NR for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Oct 2021 14:11:57 +0200 Original-Received: from localhost ([::1]:47998 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mgnDH-0007ZJ-QS for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Oct 2021 08:11:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37272) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mgnCj-0006uE-76 for emacs-devel@gnu.org; Sat, 30 Oct 2021 08:11:21 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51440) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mgnCg-0001d7-Pr; Sat, 30 Oct 2021 08:11:19 -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=nVa/GKYWOJCTbY1Mg4wiKPOVVqzdlI+CUpisQ0kCfuM=; b=Kdd988XXNoIH Vh07at7BEmzv/r/GdrdMccwC8yskQFsyDCivZYOaJZ13WSVtc9DRETU4OdyEqt1RWnD1SVCcLL4LI J+oK9CrRrZ8m3mfiicx78lQq5g+yBi1rQkK9+I71I5OTlm03vikMOUPiX7yVl6oD9ftCY88GEmqTf 5crXCT2Gu8W+cvGkrdth02ekiG/xjMed3l1CsV39p7KN6CFCd78qfKCFKnSotBDcvjlgezguI8DEU 9KixkhMOhyGrh0y8UpvqLOjnq7Y4welJ1KBuPZG0/r7q2PSDPAjZ3knRiOz6BSiNkHMGnNR8C2WMa iqvL80edMy6OwjjFmyPt1A==; Original-Received: from [87.69.77.57] (port=2925 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 1mgnCg-000460-3g; Sat, 30 Oct 2021 08:11:18 -0400 In-Reply-To: <874k8yspb4.fsf@gnus.org> (message from Lars Ingebrigtsen on Sat, 30 Oct 2021 13:51:59 +0200) 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:278269 Archived-At: > From: Lars Ingebrigtsen > Cc: monnier@iro.umontreal.ca, rgm@gnu.org, stefan@marxist.se, > emacs-devel@gnu.org > Date: Sat, 30 Oct 2021 13:51:59 +0200 > > Eli Zaretskii writes: > > > Who'd do the cherry-picking in this scenario? And why do you assume > > people won't forget doing that, like they forget to merge and/or mark > > the changes "not to be merged to master"? > > The people who commit things to master would also be tasked with > deciding whether to cherry-pick things for the release branch. That assumes they will want to, and will do a good job. > > I fear that what you propose will completely demote the release branch > > to the status of second-rate citizen, because it then becomes a > > burden. That'd be a regression. > > Speaking for myself, a cherry-picking work flow would be less work, not > more work in general, because I normally use an Emacs from the master > branch. Then it's good for you, but not for me: when a release is in progress, I work mainly on the release branch. And of course, cherry-picking doesn't remove merge conflicts, they will still need to be resolved. We've been using the current workflow for years without any major problems. Changing that now radically doesn't make sense to me. It will most probably need several procedures to be modified that were stable for several releases, and I don't see the gains which would justify that. We have enough real work on our hands. So please let's not do that.