From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Robert J. Chassell" Newsgroups: gmane.emacs.devel Subject: Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.] Date: Sun, 3 Oct 2004 14:20:46 +0000 (UTC) Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <1096291271.415813c757a26@imp6-q.free.fr> <20040927134714.GA20012@fencepost> <87hdphx91c.fsf@trouble.defaultvalue.org> <87655wswkv.fsf@trouble.defaultvalue.org> <01c4a6f8$Blat.v2.2.2$f6ef61c0@zahav.net.il> <20040930143404.GB2296@fencepost> <01c4a703$Blat.v2.2.2$9a627220@zahav.net.il> <1096575974.415c6be67eb93@imp3-q.free.fr> Reply-To: bob@rattlesnake.com NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1096813279 5981 80.91.229.6 (3 Oct 2004 14:21:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 3 Oct 2004 14:21:19 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 03 16:21:07 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 1CE7EY-0002zg-00 for ; Sun, 03 Oct 2004 16:21:07 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CE7L6-00030m-Is for ged-emacs-devel@m.gmane.org; Sun, 03 Oct 2004 10:27:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CE7Kz-0002xi-GS for emacs-devel@gnu.org; Sun, 03 Oct 2004 10:27:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CE7Kz-0002xH-0P for emacs-devel@gnu.org; Sun, 03 Oct 2004 10:27:45 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CE7Ky-0002x1-R3 for emacs-devel@gnu.org; Sun, 03 Oct 2004 10:27:44 -0400 Original-Received: from [69.168.110.189] (helo=rattlesnake.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CE7EL-0007R6-C6 for emacs-devel@gnu.org; Sun, 03 Oct 2004 10:20:53 -0400 Original-Received: by rattlesnake.com via sendmail from stdin id (Debian Smail3.2.0.115) Sun, 3 Oct 2004 14:20:46 +0000 (UTC) Original-To: emacs-devel@gnu.org In-reply-to: <1096575974.415c6be67eb93@imp3-q.free.fr> (message from =?iso-8859-1?b?Suly9G1l?= Marant on Thu, 30 Sep 2004 22:26:14 +0200) 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:27828 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27828 Jérôme Marant wrote, Please re-read the whole thread and come back when you have done so. You misunderstood everything, no offence meant. I just re-read the whole thread and as far as I can see, I described the situation correctly. What is not clear to me is whether Marant considers releases such as 21.2 and 21.3 as `stable'. If not, then I did not describe his proposal correctly. My understanding is that currently, *every* release by the Emacs developers is intended to be `stable'. Every release is one that should be able to fit into the Debian stable distribution without first going through unstable and testing. 21.2 was supposed to have been a tested and stable release. This is a totally different release model than that used in Debian. As Rob Browning said Debian's model is different, handling the testing *after* the intial release via the progression from unstable -> testing -> stable. Rob also introduced the term `micro release'. In this language, Emacs major and minor releases are intended to go into Debian stable immediately; `micro releases' are intended to go into Debian unstable. With Rob's term, then Marant's original proposal makes sense as one favoring `micro releases': http://lists.gnu.org/archive/html/emacs-devel/2004-09/msg00935.html What we propose is to maintain bugfix releases from stable releases. This is exactly the kind of job we are doing with the Debian Emacs package: collecting bugfixes, backporting fixes from the trunk. in which the proposal is to make releases that fix bugs in Emacs releases such as 21.2 and 21.3. However, if you do not think of 21.2 and 21.3 as stable, it also makes sense as a proposal to stop Emacs developers from making releases like 21.2 and 21.3. Put another way, two courses are possible: * to make `micro' releases from stable and pretested releases such as 21.2 and 21.3; * to abolish `major bug fix' releases such as 21.2 and 21.3 and make all bug fix releases off of a release such as 21.1. I realize I have been presuming that Emacs developers would continue to make bug fix releases as well as new feature releases and that they would also stick to their model of pretesting all releases so they are as good and as stable as they can make them. Jérôme's proposal made sense with this presumption. But it also made sense if he proposed abolishing pretested bug fix releases by the Emacs developers and replacing them with unstable and less tested releases that then go through post-release testing. -- Robert J. Chassell bob@rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc