From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: What holds the release (was: mouse-1-click-follows-link) Date: Thu, 16 Jun 2005 10:09:39 +0200 Message-ID: References: <8564wi2ag7.fsf@lola.goethe.zz> <17070.36649.525270.871681@farnswood.snap.net.nz> Reply-To: Juanma Barranquero NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1118909426 17078 80.91.229.2 (16 Jun 2005 08:10:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 16 Jun 2005 08:10:26 +0000 (UTC) Cc: eliz@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 16 10:10:15 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DipQg-0007em-Sz for ged-emacs-devel@m.gmane.org; Thu, 16 Jun 2005 10:08:51 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DipW3-0003IW-Cd for ged-emacs-devel@m.gmane.org; Thu, 16 Jun 2005 04:14:23 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DipTr-00035f-Az for emacs-devel@gnu.org; Thu, 16 Jun 2005 04:12:08 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DipTg-00033E-9x for emacs-devel@gnu.org; Thu, 16 Jun 2005 04:11:58 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DipTd-00030n-6I for emacs-devel@gnu.org; Thu, 16 Jun 2005 04:11:54 -0400 Original-Received: from [64.233.182.207] (helo=nproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DipTG-0007LL-FP for emacs-devel@gnu.org; Thu, 16 Jun 2005 04:11:30 -0400 Original-Received: by nproxy.gmail.com with SMTP id i2so10756nfe for ; Thu, 16 Jun 2005 01:09:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=V4EhTTuI6cRJsjSwicvdWwX2mT87h7CIaSvfapqjQi020L5N4bWo2G8io4yMpgD6c5oBvLfjkO5upRW/plpV2N/NubK8xuQEkUC9uTL0fbU02Sri/2G2v6uH4I1NZTF7U23tZp2azJo7sZ3o0XsdHRg4Djr3oKNdeuVe5GhZMyE= Original-Received: by 10.48.4.10 with SMTP id 10mr8913nfd; Thu, 16 Jun 2005 01:09:39 -0700 (PDT) Original-Received: by 10.48.250.5 with HTTP; Thu, 16 Jun 2005 01:09:39 -0700 (PDT) Original-To: rms@gnu.org In-Reply-To: Content-Disposition: inline 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:38942 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:38942 On 6/16/05, Richard Stallman wrote: > We have not had "three years of freeze". It has been less than one > year--and we are a lot closer to a release now than we were a year > ago. Oh, I got a bit carried away. It's not been three years of "freeze", and I don't know the exact date the freeze was decided, but I've just read a message by me on Nov, 4, 2002 discussing the exact same issues that we're discussing today (only the feature-pack release was called 21.4 back then). Stefan said: "I obviously agree since I called for a feature freeze a few weeks (months?) back already." Eli disagreed, and a discussion very much like this one followed. So we're kicking this ball for the past 2.61+ years. Doesn't that seem a long time to you? > I do not want to do releases more often by lowering the quality > or having outdated manuals. OK 100% wrt the manuals. "Lowering the quality" seems loaded language to me, given the different POVs about the relative importance of FOR-RELEASE items. And 100% disagree with you that branching for a release and leaving the trunk for new development would "divert resources" (you stated this position back then, if I'm not misremembering). The truth is, when there's only one input point, "feature freeze" is somewhat difficult to enforce, as past experience shows. --=20 /L/e/k/t/u