Re: Merging release branch

[Lars Ingebrigtsen]

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.

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

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

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

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no