Re: Merging release branch

[Lars Ingebrigtsen]

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.  And,
yes, they'll forget to do this as they forget to put "don't merge" into
the commit messages, but there's one major advantage to the
cherry-picking here: Even if they forget, it's not then too late (as it
is with the commit message thing).  They can just cherry-pick the next
day when somebody reminds them.

> 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.  Being able to apply commits to master would be faster for me,
and cherry-picking to the release branch can be largely automated.

And I don't see any demotion of status here.  If anything, I see an
elevation -- we're deeming that branch so important that we're being
careful with it.

> Cherry-picking makes much more sense when branches are short-lived,
> which is not the case here.

I think it's rather the opposite?  The projects I'm familiar with that
use cherry-picking have very long-lived release branches (several of
them), and they keep on cherry-picking bug/documention fixes from the
trunk for years and years.  (Which we don't do, because of our
merge-from-release strategy.)

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