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 05:25:04 +0900 Message-ID: <87d3qnwk0v.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> 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 1288729427 5496 80.91.229.12 (2 Nov 2010 20:23:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 2 Nov 2010 20:23:47 +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 Tue Nov 02 21:23:43 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 1PDNOP-0006rU-Ie for ged-emacs-devel@m.gmane.org; Tue, 02 Nov 2010 21:23:42 +0100 Original-Received: from localhost ([127.0.0.1]:44864 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PDNON-0005TC-Hc for ged-emacs-devel@m.gmane.org; Tue, 02 Nov 2010 16:23:39 -0400 Original-Received: from [140.186.70.92] (port=41876 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PDNO9-0005Pi-3D for emacs-devel@gnu.org; Tue, 02 Nov 2010 16:23:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PDNO7-0003Ak-JW for emacs-devel@gnu.org; Tue, 02 Nov 2010 16:23:24 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp ([130.158.254.161]:37203) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PDNO7-00039s-0D for emacs-devel@gnu.org; Tue, 02 Nov 2010 16:23:23 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp (imss12.cc.tsukuba.ac.jp [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 0B8762AF543; Wed, 3 Nov 2010 05:23:21 +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 EFE032AF542; Wed, 3 Nov 2010 05:23:20 +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 EDFF73FA0531; Wed, 3 Nov 2010 05:23:20 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 714871A3EDD; Wed, 3 Nov 2010 05:25:04 +0900 (JST) In-Reply-To: <87fwvjimg2.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:132299 Archived-At: =D3scar Fuentes writes: > Almost every change on emacs-23 is intended to trunk too. Right now > those changes that are exclusive to emacs-23 must be flagged > somehow. Adding common-fixes just means that people working on emacs-23 > will work on common-fixes, except for those cases where they would flag > the change as belonging to emacs-23 only. Not so hard, IMO. Good luck to you in convincing the Emacs community, then. > > Even for frequent contributors who help with porting patches back and > > forth between the branches, this requires more thinking about where > > you should do the work. >=20 > 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? Certainly, this is to some extent balanced by the extra work of flagging -23 changes that shouldn't go into trunk. The advantage of the svnmerge-py workflow is that you make these decisions later, after the work is done. > 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. 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. This is probably a mildly bad thing; work on the trunk is generally going to be more complex, and you'd like people to concentrate there. 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). I don't think there's any saving, and in fact the decision to work on common-fixes (before you have a patch) is probably harder than the decision to merge to trunk or not (with the work complete). To some extent that decision needs to be made before doing any work, which increases the burden and the likelihood of a mistake. 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. And it requires everybody to adapt a new workflow at all phases of their work, instead of concentrating on the cherry pick only in the cases where it's needed.