Re: Incorrect merge

[Óscar Fuentes]

"Stephen J. Turnbull" <address@hidden> writes:

>  > Uh? With common-fixes you merge the commits there into emacs-23 and
>  > trunk. That's all.
>
> No, you have to choose whether to work in -23, trunk, or common-fixes.
> This involves checking whether the bug affects both or not, and
> whether the fix is the same.  Often trivial, but not always.
>
> And what if you fix a bug in trunk, and only later realize it needs to
> be backported?

And how is this different from the current workflow? Right now people
must decide the scope of the patch. Adding the common-fixes branch
simplifies the task from the conceptual POV: instead of

 * commit fixes for emacs-23 and trunk into emacs-23
 * commit fixes intended for trunk only into trunk.
 * commit fixes intented for emacs-23 only into emacs-23, put something
  into the log message and hope it is noticed.

you have

 * commit fixes for emacs-23 and trunk into common-fixes.
 * commit fixes intended for emacs-23 only into emacs-23.
 * same for trunk.

[snip]

>  > You are missing the point. common-fixes will eliminate the need for
>  > cherry-picking (and for examining each commit on emacs-23 before merging
>  > into trunk). The maintainers save time and the VC history is consistent
>  > (with commits maintaining its identity on the branches where they are
>  > installed)
>
> It doesn't eliminate the need for cherry-picking as long as there's
> more than one active branch: you can make a mistake about where to
> work.

If you come with "yes, but someone can make a mistake..." then any
schema we can think of can be dismissed with the same reasoning.

>  This should be a lot less frequent in the common-fixes
> workflow.  It does require people who would otherwise focus on trunk
> to switch between branches, and to be continuously thinking about
> which branch they should be in.

Again, the current workflow requires people to decide that.

[snip]

> Every commit on common-fixes needs to be examined before making it to
> be sure that it's appropriate for both release branches (common-fixes
> is never released).

If you want a fool-proof method, propose a gatekeeper workflow (with
several layers of verification, for enhanced security :-)

[snip]

> The VC history is consistent, but I don't think the maintainers save
> much time and it's at a higher burden to the general contributors.

The consistency on VC history is a huge win for me. The ability to
quickly decide which branches contain a given commit will turn more and
more important as feature branches proliferate. Right now we should put
the revision id (not revision number) of a fix on the respective bug
report when closing it.

> And it requires everybody to adapt a new workflow at all phases of
> their work,

This is an exaggeration. Only people who work on emacs-23 would need to
adapt their workflow (committing to common-fixes instead of emacs-23). I
admit that the big hurdle is to pass the word about the new workflow,
but this could be forced by making emacs-23 read-only for all except
some top maintainers, who would act as gatekeepers for some time.

> instead of concentrating on the cherry pick only in the
> cases where it's needed.

Doing the cherry-picking (with the current workflow) or the merge (with
my proposed branch) is something that only a few maintainers should care
about.