From: "Óscar Fuentes" <ofv@wanadoo.es>
To: emacs-devel@gnu.org
Subject: Re: Incorrect merge
Date: Tue, 02 Nov 2010 21:44:30 +0100 [thread overview]
Message-ID: <87wrovh2vl.fsf@telefonica.net> (raw)
In-Reply-To: 87d3qnwk0v.fsf@uwakimon.sk.tsukuba.ac.jp
"Stephen J. Turnbull" <stephen@xemacs.org> 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.
next prev parent reply other threads:[~2010-11-02 20:44 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-01 13:48 Incorrect merge Ken Brown
2010-11-01 15:46 ` Chong Yidong
2010-11-01 16:02 ` Chong Yidong
2010-11-01 17:54 ` Eli Zaretskii
2010-11-01 20:21 ` Juanma Barranquero
2010-11-01 20:37 ` Eli Zaretskii
2010-11-01 22:19 ` Juanma Barranquero
2010-11-02 1:50 ` Stephen J. Turnbull
2010-11-02 14:54 ` Stefan Monnier
2010-11-02 15:57 ` Óscar Fuentes
2010-11-02 16:45 ` Stephen J. Turnbull
2010-11-02 17:14 ` Óscar Fuentes
2010-11-02 18:34 ` Stephen J. Turnbull
2010-11-02 18:56 ` Óscar Fuentes
2010-11-02 20:25 ` Stephen J. Turnbull
2010-11-02 20:44 ` Óscar Fuentes [this message]
2010-11-03 5:22 ` Stephen J. Turnbull
2010-11-03 6:46 ` Óscar Fuentes
2010-11-03 7:44 ` Stephen J. Turnbull
2010-11-03 13:51 ` Stefan Monnier
2010-11-04 20:16 ` Lars Magne Ingebrigtsen
2010-11-05 9:30 ` Andreas Schwab
2010-11-05 11:42 ` Eli Zaretskii
2010-11-08 16:03 ` Stefan Monnier
2010-11-03 6:52 ` Óscar Fuentes
2010-11-03 7:47 ` Stephen J. Turnbull
2010-11-02 17:22 ` Stefan Monnier
2010-11-02 17:37 ` Óscar Fuentes
2010-11-02 18:38 ` Eli Zaretskii
2010-11-02 19:19 ` Óscar Fuentes
2010-11-02 21:21 ` Stefan Monnier
2010-11-01 23:02 ` Óscar Fuentes
2010-11-02 1:29 ` Jason Rumney
2010-11-02 5:16 ` Óscar Fuentes
2010-11-02 9:16 ` Andreas Schwab
2010-11-02 14:17 ` Óscar Fuentes
2010-11-02 17:24 ` Stefan Monnier
2010-11-02 17:41 ` Óscar Fuentes
2010-11-02 17:44 ` Davis Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wrovh2vl.fsf@telefonica.net \
--to=ofv@wanadoo.es \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.