[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Incorrect merge
From: |
Óscar Fuentes |
Subject: |
Re: Incorrect merge |
Date: |
Tue, 02 Nov 2010 21:44:30 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
"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.
- Re: Incorrect merge, (continued)
- Re: Incorrect merge, Eli Zaretskii, 2010/11/01
- Re: Incorrect merge, Juanma Barranquero, 2010/11/01
- Re: Incorrect merge, Stephen J. Turnbull, 2010/11/01
- Re: Incorrect merge, Stefan Monnier, 2010/11/02
- Re: Incorrect merge, Óscar Fuentes, 2010/11/02
- Re: Incorrect merge, Stephen J. Turnbull, 2010/11/02
- Re: Incorrect merge, Óscar Fuentes, 2010/11/02
- Re: Incorrect merge, Stephen J. Turnbull, 2010/11/02
- Re: Incorrect merge, Óscar Fuentes, 2010/11/02
- Re: Incorrect merge, Stephen J. Turnbull, 2010/11/02
- Re: Incorrect merge,
Óscar Fuentes <=
- Re: Incorrect merge, Stephen J. Turnbull, 2010/11/03
- Re: Incorrect merge, Óscar Fuentes, 2010/11/03
- Re: Incorrect merge, Stephen J. Turnbull, 2010/11/03
- Re: Incorrect merge, Stefan Monnier, 2010/11/03
- Re: Incorrect merge, Lars Magne Ingebrigtsen, 2010/11/04
- Re: Incorrect merge, Andreas Schwab, 2010/11/05
- Re: Incorrect merge, Eli Zaretskii, 2010/11/05
- Re: Incorrect merge, Stefan Monnier, 2010/11/08
- Re: Incorrect merge, Óscar Fuentes, 2010/11/03
- Re: Incorrect merge, Stephen J. Turnbull, 2010/11/03