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 13:51:59 +0200
> 
> Eli Zaretskii <eliz@gnu.org> 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.