From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Incorrect merge Date: Wed, 03 Nov 2010 14:22:22 +0900 Message-ID: <871v73c775.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4CCEC526.3070502@cornell.edu> <87aaltc9rc.fsf@stupidchicken.com> <83pqup53qb.fsf@gnu.org> <83fwvk6arf.fsf@gnu.org> <87hbg0jxyu.fsf@uwakimon.sk.tsukuba.ac.jp> <87d3qnk9am.fsf@telefonica.net> <87k4kvwu6w.fsf@uwakimon.sk.tsukuba.ac.jp> <8762wfk5r0.fsf@telefonica.net> <87eib3wp4j.fsf@uwakimon.sk.tsukuba.ac.jp> <87fwvjimg2.fsf@telefonica.net> <87d3qnwk0v.fsf@uwakimon.sk.tsukuba.ac.jp> <87wrovh2vl.fsf@telefonica.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1288762694 30196 80.91.229.12 (3 Nov 2010 05:38:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 3 Nov 2010 05:38:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 03 06:38:04 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PDW2r-0000nC-Nd for ged-emacs-devel@m.gmane.org; Wed, 03 Nov 2010 06:38:02 +0100 Original-Received: from localhost ([127.0.0.1]:56770 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PDW2r-00083b-5y for ged-emacs-devel@m.gmane.org; Wed, 03 Nov 2010 01:38:01 -0400 Original-Received: from [140.186.70.92] (port=53613 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PDW2f-00083S-Lr for emacs-devel@gnu.org; Wed, 03 Nov 2010 01:37:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PDW2e-00057V-ES for emacs-devel@gnu.org; Wed, 03 Nov 2010 01:37:49 -0400 Original-Received: from [130.158.254.171] (port=47134 helo=dmail02.cc.tsukuba.ac.jp) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PDW2d-00056g-To for emacs-devel@gnu.org; Wed, 03 Nov 2010 01:37:48 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp (unknown [130.158.254.130]) by dmail02.cc.tsukuba.ac.jp (Postfix) with ESMTP id 144A38725F8 for ; Wed, 3 Nov 2010 14:20:51 +0900 (JST) Original-Received: from imss12.cc.tsukuba.ac.jp (imss12.cc.tsukuba.ac.jp [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 4FEC02AF543; Wed, 3 Nov 2010 14:20:42 +0900 (JST) Original-Received: from mgmt1.sk.tsukuba.ac.jp (unknown [130.158.97.223]) by imss12.cc.tsukuba.ac.jp (Postfix) with ESMTP id 4013B2AF542; Wed, 3 Nov 2010 14:20:42 +0900 (JST) Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 3EB533FA04DF; Wed, 3 Nov 2010 14:20:42 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C54671A3EDD; Wed, 3 Nov 2010 14:22:22 +0900 (JST) In-Reply-To: <87wrovh2vl.fsf@telefonica.net> X-Mailer: VM undefined under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:132311 Archived-At: =D3scar Fuentes writes: > > And what if you fix a bug in trunk, and only later realize it needs to > > be backported? >=20 > And how is this different from the current workflow? It's not. That's precisely my point. You can reduce cherry-picking, but not eliminate it. > Right now people > must decide the scope of the patch. Adding the common-fixes branch > simplifies the task from the conceptual POV: instead of >=20 > * 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. But the svnmerge.py workflow does a lot better than that; as long as people use svnmerge.py, it does the accounting. People grumble about changing tools, but the workflow will be very similar; they'll get over it quickly. Changing the workflow is more effort, takes longer, and some people will never get over it. > you have >=20 > * commit fixes for emacs-23 and trunk into common-fixes. > * commit fixes intended for emacs-23 only into emacs-23. > * same for trunk. You're counting bzr-level tasks, but my point is that these tasks are more complex/difficult than the corresponding tasks in the other workflow because the decisions are made in advance of any commit, rather than with the actual commit to look at. > > 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. >=20 > 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. I'm not dismissing your scheme yet. I'm saying your accounting is way too optimistic. > > 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. >=20 > Again, the current workflow requires people to decide that. Again you ignore the point, which is that the current workflow means looking at an existing commit and making a decision. The commit-fixes workflow involves thinking about a prospective patch and making a decision where to produce it, or creating yet another branch and looking at the commit there. Creating a temporary branch just for that fix is precisely what I do with git, but doing that in Bazaar or Mercurial is too expensive for me. > > 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). >=20 > If you want a fool-proof method, propose a gatekeeper workflow (with > several layers of verification, for enhanced security :-) You're missing the point yet again. > > 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. >=20 > 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. I don't agree; feature branches will branch from trunk, synch to it, and eventually merge to it, being entirely unconcerned with what is or is not in the maintenance branch or common-fixes, and vice-versa. That's really the point of having a separate maintenance branch. > Right now we should put the revision id (not revision number) of a > fix on the respective bug report when closing it. >=20 > > And it requires everybody to adapt a new workflow at all phases of > > their work, >=20 > 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). But that requires examining the commits of trunk-only workers for -23 relevance, and cherry-picking if they are relevant. You can't have it both ways. Either you're serious about consistent history and avoiding cherry-picking as much as possible, which requires everybody to consider whether their fixes are -23 relevant, or you're not. True, people working only on features can avoid this. > 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. Doing it is Bazaar's problem; if Bazaar doesn't make that work as convenient as possible, we made a big mistake. The question is which way is harder to think about. Your way requires all committers who fix bugs to worry about which branch to commit to.