Re: Merging release branch

[Tassilo Horn <tsdh@gnu.org>]

Daniel Martín <mardani29@yahoo.es> writes:

> TBH, I don't think there's a "silver bullet" workflow, it depends on
> the project, the participants, etc.  I presented some downsides of
> mine as well, so you can decide if the trade-offs would make it less
> time-consuming than the current one.  I suspect some of those
> trade-offs are "invisible" until the workflow is put into practice and
> given some time.

That's true.  As an anecdote: we've tried a cherry-pick-based workflow
at my dayjob for some period.  Basically, (for each released and still
supported version) we've had a "pending", and a "release" branch.
Developers committed their fixes in the "pending" branch where the QA
would test them.  If the test was successful, the commit(s) where
cherry-picked into the "release" branch.

I can report that it didn't work out well.  Things that happend quite
often were:

- Some ticket had N commits but only N-M (M > 0) commits were
  cherry-picked.  And once you notice something's wrong, you have to go
  and diff diffs to find out which one is missing since the question has
  turned from "is commit 18a9ef4 reachable from this branch's HEAD" to
  "is there some commit with the same message and same diff"?
- The compile/CI broke because the cherry-picked commit X required stuff
  of commit Y which has not yet been cherry-picked because Y's test took
  longer than X's (or X has been prioritized over Y).
- Same as the last bullet point but worse: the compile still worked but
  the runtime behavior was wrong.

So in general, my gut feeling is that merging is preferable over
cherry-picking.  Even more so if the time between initial commit and
cherry-pick can become longer.

A policy which makes sense would be (as Stefan M. suggested, I think):
if you commit in emacs-<major>, immediately do a merge into master
afterwards (with -s ours if the fix is not appropriate for master).

Bye,
Tassilo