Re: Merging release branch

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 29 Oct 2021 20:52:22 +0200
> Cc: Glenn Morris <rgm@gnu.org>, Stefan Kangas <stefan@marxist.se>,
>  emacs-devel@gnu.org
> 
> Lars Ingebrigtsen <larsi@gnus.org> 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.