Re: Merging release branch

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> 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 <eliz@gnu.org> 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.