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: Fri, 29 Oct 2021 22:58:29 +0300 Message-ID: <83pmrnppqy.fsf@gnu.org> References: <87bl37vg9l.fsf@gnus.org> <87y26bu0ih.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29705"; 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 Fri Oct 29 22:24:36 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 1mgYQW-0007WG-0b for ged-emacs-devel@m.gmane-mx.org; Fri, 29 Oct 2021 22:24:36 +0200 Original-Received: from localhost ([::1]:53882 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mgYQV-0006fE-1r for ged-emacs-devel@m.gmane-mx.org; Fri, 29 Oct 2021 16:24:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36228) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mgY1a-0007RA-UA for emacs-devel@gnu.org; Fri, 29 Oct 2021 15:58:50 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52170) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mgY1Z-0001nm-8j; Fri, 29 Oct 2021 15:58:49 -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=Hmsxoi4LKCjiAz/uTArjZ4oaOBf6YbgRO1f8EFF9etU=; b=CrMd+XP/A8rj 9II/MPMozVUbwrI6NXW/wULiimwfd9rThzeGDwR2IwSa7dXzO+uZ3r30pF6GeQ7HDof5oe6DuX2gX 0Nc8BRwBM29xwd/xoPmggOPfuDsBWMg/cydvkKbM/aROQpM35Ry6s+L79+tbTfTvaGVm8H3wa+dFN uhKBFQZFgu3mpTRCrIS1C+AHIudSiBNZecnUY+aLF7bgQSFIYQgE1Fpiy2XWhFnjsyRDhTjYUj1Xv fGf20pAKSJpJB043/0W59s3jIZoG2+cXE6a5iq12QieqQRfZLQ6d1a6fcaqX2mklaZHs+byboNEpJ ZKWfMxnMNbPRGG+iUbcQlw==; Original-Received: from [87.69.77.57] (port=2711 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 1mgY1U-0004DF-NR; Fri, 29 Oct 2021 15:58:45 -0400 In-Reply-To: <87y26bu0ih.fsf@gnus.org> (message from Lars Ingebrigtsen on Fri, 29 Oct 2021 20:52:22 +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:278243 Archived-At: > From: Lars Ingebrigtsen > Date: Fri, 29 Oct 2021 20:52:22 +0200 > Cc: Glenn Morris , Stefan Kangas , > emacs-devel@gnu.org > > Lars Ingebrigtsen writes: > > > That work flow sounds fine to me in general -- but what about those > > changes to emacs-28 that shouldn't be merged? > > I know there's other projects that don't do merging at all between > long-lived branches like this. > > In Emacs, that would mean that things that are supposed to be > emacs-28-only are developed there, and are pushed as normal. Any things > that are supposed to go to both master and emacs-28 are committed to > master, and then cherry-picked for emacs-28. (Or cherry-picked the > other way, but that risks "losing" changes if you forget.) > > Doing it that way would involve much fewer special rules (about commit > message formats) and less magic. 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"? 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. Cherry-picking makes much more sense when branches are short-lived, which is not the case here.