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: New branch Date: Fri, 29 Jan 2010 13:24:37 +0900 Message-ID: <87r5p9sflm.fsf@xemacs.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1264738368 17480 80.91.229.12 (29 Jan 2010 04:12:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Jan 2010 04:12:48 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 29 05:12:45 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 1NaiDo-0007yu-4C for ged-emacs-devel@m.gmane.org; Fri, 29 Jan 2010 05:12:40 +0100 Original-Received: from localhost ([127.0.0.1]:56356 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NaiDm-0007BM-Re for ged-emacs-devel@m.gmane.org; Thu, 28 Jan 2010 23:12:38 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NaiDh-00079d-Bk for emacs-devel@gnu.org; Thu, 28 Jan 2010 23:12:33 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NaiDc-00077V-U7 for emacs-devel@gnu.org; Thu, 28 Jan 2010 23:12:33 -0500 Original-Received: from [199.232.76.173] (port=47306 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NaiDc-00077S-Q1 for emacs-devel@gnu.org; Thu, 28 Jan 2010 23:12:28 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:59833) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NaiDa-0005JZ-7F; Thu, 28 Jan 2010 23:12:26 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id D7F86820E; Fri, 29 Jan 2010 13:12:17 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 2E122136DD3; Fri, 29 Jan 2010 13:24:37 +0900 (JST) In-Reply-To: X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" a03421eb562b XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:120627 Archived-At: Stefan Monnier writes: > But note that in the context of Bzr, those questions don't have the same > importance&meaning as within CVS. That's right; they're *far* more important! ;-) > After all, creating a branch is > nothing else than cloning, so initially the new branch is absolutely > identical to the "parent". > I expect at some point we'll do something like: > > (cd pending; bzr merge ../trunk; bzr commit) > mv trunk emacs-23.2 > mv pending trunk Gawd, no! For that to work, you really want to be rebasing pending on to trunk after *every* commit to trunk. Otherwise, what you propose here will AFAICT result in exactly the kind of Mainline Twist that you personally just set ARO to prevent. But that seems like makework to me. The whole point of having a pending branch should be that they can go their separate ways for a while, and during that while, commits of new code to the public branches are discouraged and require effort to (a) do and (b) test. If you are not trying to discourage work on new code, then you should cut a separate release branch. > or maybe > > bzr clone trunk emacs-23.2 > (cd trunk; bzr merge ../pending; bzr commit) > rm -rf pending Better, but that last line should give you pause. Sure, it's needed, because pending is now obsolete. But bzr gives no way to notify people of that except that their attempts to pull or push will fail (I hope). It seems to me that pending is not a great idea. Patches that don't belong in trunk can just stay in personal private or public branches until trunk opens again. If pending would really accumulate significant amounts of work, your release process has more problems than just "where to put pending work".