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: mouse-1-click-follows-link Date: Tue, 14 Jun 2005 10:37:04 +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 1118741358 13459 80.91.229.2 (14 Jun 2005 09:29:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 14 Jun 2005 09:29:18 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 14 11:29:11 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Di7iR-00072b-00 for ged-emacs-devel@m.gmane.org; Tue, 14 Jun 2005 11:28:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Di7nP-0001uY-8S for ged-emacs-devel@m.gmane.org; Tue, 14 Jun 2005 05:33:23 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Di7TQ-0005Qm-Vr for emacs-devel@gnu.org; Tue, 14 Jun 2005 05:12:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Di7TD-00059h-KV for emacs-devel@gnu.org; Tue, 14 Jun 2005 05:12:37 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Di76f-0003Pm-5p for emacs-devel@gnu.org; Tue, 14 Jun 2005 04:49:15 -0400 Original-Received: from [64.233.182.193] (helo=nproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Di6wA-0002wS-6P for emacs-devel@gnu.org; Tue, 14 Jun 2005 04:38:22 -0400 Original-Received: by nproxy.gmail.com with SMTP id i2so118811nfe for ; Tue, 14 Jun 2005 01:37:04 -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=s5OEUnDPq9WwcW1s7E+z/j/daq91uzZXuqhkn6zXkJxvMSkv8/820/L2ibuWS4a59Q9L6/H0NkMAA1MOXDMSpD0SAkOGr04TWsmuLjY09Fk45HfZSRgujfZb94wr6qTVqc6zj95W44b+0QiuBSdg17PSg2IODQW6hgBmzgBwnsc= Original-Received: by 10.48.249.6 with SMTP id w6mr92022nfh; Tue, 14 Jun 2005 01:37:04 -0700 (PDT) Original-Received: by 10.48.250.5 with HTTP; Tue, 14 Jun 2005 01:37:04 -0700 (PDT) Original-To: Nick Roberts In-Reply-To: <17070.36649.525270.871681@farnswood.snap.net.nz> 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:38794 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:38794 > Its not the changes that are going into Emacs that are holding up the rel= ease. > Its the requirement that all the items in the file FOR-RELEASE are comple= ted > first. Perhaps. Still, in the past month or so there have been quite a few comments about the success of the freeze (or lack thereof). > That's Richard's choice, and clearly its his prerogative Of course. > but completion of the list might take a long time. If we fork now then e= very > change that is considered to be a bug fix will have to be applied to both= the > head and the branch and it still won't speed up the release. That it won't speed up the release is your opinion, and it's clear I don't agree. There's no way to know who's right. What *is* clear is that the current procedures do *not* induce speedy releases. As discussed several times before, many projects, some with far fewer people than this, do just fine with forking to prepare a release and let people do new developments on the trunk. And in these projects, people backports bugfixes to the release branch too. And, as you say, completion of the list might take a long time; so there's a kind of pressure on people to apply small new features to the trunk. When I left Emacs development a year ago, the freeze was already in place. I just don't want to count how many new features have been installed since then. All in all, I don't know what's the perfect answer. No one knows. But I do feel than there's something wrong with a project the size and importance of Emacs holding new features for three and a half years (and counting). 21.1 was released on October, 21, 2001. So perhaps it's time to think what's wrong with our release process, and "people doesn't want to work on the issues important for the release" just doesn't cut it: I don't think Emacs developers are very different from other projects' people. --=20 /L/e/k/t/u