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:48:31 +0300 Message-ID: <831r42ptk0.fsf@gnu.org> References: <87bl37vg9l.fsf@gnus.org> <87y26bu0ih.fsf@gnus.org> <83pmrnppqy.fsf@gnu.org> <874k8yspb4.fsf@gnus.org> <835ytepvad.fsf@gnu.org> <87mtmqr8wn.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23589"; 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:51:11 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 1mgnpG-0005w4-HA for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Oct 2021 14:51:10 +0200 Original-Received: from localhost ([::1]:50930 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mgnpF-0006yE-Bx for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Oct 2021 08:51:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43460) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mgnmw-0005Oc-Ng for emacs-devel@gnu.org; Sat, 30 Oct 2021 08:48:50 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52512) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mgnmv-00080V-Bw; Sat, 30 Oct 2021 08:48:45 -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=CUd5kIDisJXsBaCWV+ivBUSWXgX3t4ng3VJLVs5Ltd8=; b=YgOKjAOeCWVN axvxpVpfOOEg1WLor8MAebf8zZDzuXRayX+5MU3gMFzKm/6PzOS+I8RcP2sesxRH24IDUwshyrF8L 0hDLxWhZtGv0pZdCcuzyZMHSrOJsaCNBKsmj0WE3YnrMo0XdAuAlyWIPVOKojYRI/0ru+GOli7kZB A/pRkhtxYIjXdVlkGteqU7IvcJAJz0e/QF7xe706RkXhyXyOQZ2FkXK9AmRoZnCYyZwHZE0Hv/jpF oKxiJZuuMNILAv+12Zrb5imNY5q5lJrugHwqwxIc79HnovM+Mv68C/aQQ89iOkSUne17IMsUOg062 8GSDAET13kkfAUxYo34mfg==; Original-Received: from [87.69.77.57] (port=1277 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 1mgnmt-0008EI-TJ; Sat, 30 Oct 2021 08:48:44 -0400 In-Reply-To: <87mtmqr8wn.fsf@gnus.org> (message from Lars Ingebrigtsen on Sat, 30 Oct 2021 14:31:36 +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:278279 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 14:31:36 +0200 > > Eli Zaretskii writes: > > >> 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. > > That's an assumption that doesn't change -- we assume that now, and we > continue to assume so in the future. No, until now committers didn't have to merge to master, they just committed to a single branch. > >> 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 you can continue to do so -- and cherry-pick commits to master. That's a disadvantage, because Git will not help us track which changes from the branch are on master (and vice versa). > > And of course, cherry-picking doesn't remove merge conflicts, they > > will still need to be resolved. > > So that's neither more than less work than the merge based work flow -- > but with the advantage that you're resolving one pick at a time instead > of the more overwhelming thing that can happen when merging and you get > conflicts from several commits at once. Conflicts are generally rare with Git, though. > > 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. > > What's changed is that Glenn is (understandably) no longer willing to do > the merges, so something has to change. (Unless somebody else picks up > the slack, and we can continue as before.) We haven't even tried to find a new volunteer yet. You suggest that we give up before we even try.