Re: Merging release branch

[Dmitry Gutov]

On 30.10.2021 15:11, Eli Zaretskii wrote:
> > 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.

People seem to generally want to push changes to the release branch. If 
only to get them to the users sooner.

> > > 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.

By the author of the change, that's the point.

So I also think it might justify the additional overhead of having to 
cherry-pick every change.

> 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.

Do we have a volunteer who will take over from Glenn?