From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: =?iso-8859-1?b?Suly9G1l?= Marant Newsgroups: gmane.emacs.devel Subject: Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.] Date: Tue, 28 Sep 2004 11:01:35 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <1096362095.4159286fdb4c7@imp4-q.free.fr> References: <1096285717.4157fe159930b@imp1-q.free.fr> <1096291460.4158148407699@imp6-q.free.fr> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1096382679 9887 80.91.229.6 (28 Sep 2004 14:44:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 28 Sep 2004 14:44:39 +0000 (UTC) Cc: emacs-devel@gnu.org, rms@gnu.org, "Kim F. Storm" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 28 16:44:15 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CCJDC-0002Od-00 for ; Tue, 28 Sep 2004 16:44:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CCJJU-000762-Sh for ged-emacs-devel@m.gmane.org; Tue, 28 Sep 2004 10:50:44 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CCJEd-0003pL-Ss for emacs-devel@gnu.org; Tue, 28 Sep 2004 10:45:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CCJEc-0003nz-Cg for emacs-devel@gnu.org; Tue, 28 Sep 2004 10:45:42 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CCJEc-0003mv-09 for emacs-devel@gnu.org; Tue, 28 Sep 2004 10:45:42 -0400 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CCJ7J-00075o-Rl; Tue, 28 Sep 2004 10:38:10 -0400 Original-Received: from [213.228.0.169] (helo=postfix3-2.free.fr) by mx20.gnu.org with esmtp (Exim 4.34) id 1CCDvo-0001jv-7v; Tue, 28 Sep 2004 05:05:56 -0400 Original-Received: from imp4-q.free.fr (imp4-q.free.fr [212.27.42.4]) by postfix3-2.free.fr (Postfix) with ESMTP id 01E4CC871; Tue, 28 Sep 2004 11:01:36 +0200 (CEST) Original-Received: by imp4-q.free.fr (Postfix, from userid 33) id EE2E1EDBE; Tue, 28 Sep 2004 11:01:35 +0200 (MEST) Original-Received: from mure.msy.sagem.com (mure.msy.sagem.com [62.160.59.178]) by imp4-q.free.fr (IMP) with HTTP for ; Tue, 28 Sep 2004 11:01:35 +0200 Original-To: Stefan Monnier In-Reply-To: User-Agent: Internet Messaging Program (IMP) 3.2.5 X-Originating-IP: 62.160.59.178 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:27644 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27644 Quoting Stefan Monnier : > >> Actually, we already have "the RC branch" from which 21.2 and 21.3 c= ame. > >> So I agree to the extent that "Debian patches" should be applied to = the RC > >> branch of Emacs rather than just to the Debian Emacs package (assumi= ng the > >> fixes are sufficiently clean, of course). > > > It is much easier to create a new branch for every stable release: yo= u > > can then avoid the pain of CVS merges for the same cost (I'm not > > inventing anything, GCC people do this). > > OK, it seems we're mis-communicating because I assume you know things y= ou > don't. "The" RC branch is the branch that's created when a new major > release is made. I.e. when 21.1 was released, a new branch was created > (EMACS_21_1_RC). From this branch were cut the bugfix releases 21.2 an= d > 21.3. When 21.4 will be release a new RC branch will be created. I knew about this branch but I've been confused by 21.2 and 21.3 being bugfix releases. This is why we do propose a different versioning scheme for such releases. > I.e. right now there's a single RC branch for the simple reason that th= ere's > only been a single major release since we switched to CVS. But there w= ill > be more (but obviously at any point in time only one RC branch is activ= e, > because we don't have the manpower to continue releasing bugfix release= s of > several major versions). > > I.e. what you're suggesting is "what we already do" except that you're > proposing to be more actively involved in maintaining the RC branch (an= d you > suggest we call the revisions 21.1.N rather than 21.2, 21.3, ...). I t= hink > that any separately maintained set of patches is a waste of resouces, s= o of > course I'd welcome it if Debian put their patches directly in the RC br= anch > rather. This is exactly what we offer to do. Cheers, -- J=E9r=F4me Marant