From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Giorgos Keramidas Newsgroups: gmane.emacs.devel Subject: Re: Syncing Gnus and Emacs repositories Date: Sat, 23 Jun 2007 11:13:17 +0300 Message-ID: <20070623081316.GA1502@kobe.laptop> References: <18033.64249.816850.550250@kahikatea.snap.net.nz> <85ejkcq32v.fsf@lola.goethe.zz> <85k5u4nlrh.fsf@lola.goethe.zz> <878xahbvoq.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1182587615 6844 80.91.229.12 (23 Jun 2007 08:33:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 23 Jun 2007 08:33:35 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 23 10:33:34 2007 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.50) id 1I213m-0002bt-2e for ged-emacs-devel@m.gmane.org; Sat, 23 Jun 2007 10:33:34 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I213l-0006Ya-EG for ged-emacs-devel@m.gmane.org; Sat, 23 Jun 2007 04:33:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I213h-0006X8-OB for emacs-devel@gnu.org; Sat, 23 Jun 2007 04:33:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I213h-0006WJ-1j for emacs-devel@gnu.org; Sat, 23 Jun 2007 04:33:29 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I213g-0006WA-U0 for emacs-devel@gnu.org; Sat, 23 Jun 2007 04:33:28 -0400 Original-Received: from igloo.linux.gr ([62.1.205.36]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1I213g-0001Di-9E for emacs-devel@gnu.org; Sat, 23 Jun 2007 04:33:28 -0400 Original-Received: from kobe.laptop (dialup237.ach.sch.gr [81.186.70.237]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l5N8WuRv025541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 23 Jun 2007 11:33:05 +0300 Original-Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l5N8Wmgl002143 for ; Sat, 23 Jun 2007 11:32:49 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Original-Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l5N8DHtL001840; Sat, 23 Jun 2007 11:13:17 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Content-Disposition: inline In-Reply-To: <878xahbvoq.fsf@uwakimon.sk.tsukuba.ac.jp> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (cached, score=-3.768, required 5, ALL_TRUSTED -1.80, AWL 0.63, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-detected-kernel: Genre and OS details not recognized. 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:73690 Archived-At: On 2007-06-18 15:53, "Stephen J. Turnbull" wrote: > Also, David Kastrup is quite right about the deficiencies of CVS. > XEmacs did something similar to what is being proposed here. Under > pressure from people who were not primarily interested in the 21.4 > release, we branched in January 2001, pushing blue-sky projects off on > a branch, and keeping 21.4 on the trunk. It immediately became clear > this was unsustainable due to the difficulty of using cvs annotate, > cvs diff, and cvs update -j with mainline on a CVS branch. So in > April 2001, less than three months later, we transplanted the trunk > (starting from the fork) to a new release-21-4 branch, and the 21.5 > branch back to the trunk, at fairly high cost in current usefulness of > annotate, diff and update -j. However, with mainline on the branch, > that cost was increasing rapidly, while with mainline on the trunk, > the cost decreased to negligible by the end of summer 2001. While in > the end we avoided total disaster, the rationalization effort was > unaccompanied by any net benefit whatsoever, in fact, there were net > costs both before and after the rationalization compared to doing it > right by putting mainline on the trunk as soon was the 21.4 feature > freeze was implemented. That's very interesting. I am not watching the development of XEmacs very closely, but can you please describe how developing on a 'release branch' made things difficult for XEmacs? Please feel free to email me privately if this would increase the noise in emacs-devel, without a lot of benefit for Emacs developers. I'm asking because of my existing experience with how the FreeBSD CVS tree is used to work on FreeBSD development. It may not be very useful for Emacs development, but the model used by the FreeBSD CVS tree is: [1] ----X--------------------------> trunk | : : | : : +-----------X--------X--> RELENG_6 [2] [3] | | | | | +--- RELENG_6_1 | | +------------ RELENG_6_0 Where 'X' points are tags, and ':' lines denote selective merging of features from the CVS trunk. 1 == RELENG_6_BP 2 == RELENG_6_0_0_RELEASE 3 == RELENG_6_1_0_RELEASE When the CVS trunk is considered ready for the 6.X branch, we freeze trunk, the release engineering team tags the trunk as RELENG_6_BP and the RELENG_6 branch is branched off RELENG_6_BP. Some time after the release branch RELENG_6 stabilizes enough for us to roll out a release, we freeze the RELENG_6 and finally we tag it with RELENG_6_0_0_RELEASE and then we create a 'security branch' off the release tag (RELENG_6_0). Each release is tagged with RELENG_X_Y_Z_RELEASE. Each release has an associated RELENG_X_Y security branch, which can accept _only_ security fixes and nothing else. Each major line of development has its own RELENG_X 'mainline'. Development of cutting edge features, which may be unstable for long periods of time, experimental, or even be completely removed before they ever hit a release branch is done in the CVS trunk. Development of 'stable' versions, which can only make conservative bugfix and security fix changes, is done in the RELENG_X mainline. I don't know if such a model would fit the development of Emacs, or if the description was clear enough. Please feel free to ask any questions regarding the way we branch or tag FreeBSD, or how the release process of FreeBSD is organized around CVS. It if helps us make the development of Emacs more 'streamlined', then I'll be glad to work with the main Emacs developers to see which parts of the FreeBSD model can fit the way the development of Emacs works already and which parts we can adopt to improve things :) - Giorgos