From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: Reordering etc/NEWS Date: Wed, 09 May 2007 14:56:38 -0700 Message-ID: <87fy65k6eh.fsf@red-bean.com> References: <2wmz0iriyj.fsf@fencepost.gnu.org> Reply-To: Karl Fogel NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1178747814 31932 80.91.229.12 (9 May 2007 21:56:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 9 May 2007 21:56:54 +0000 (UTC) Cc: Eli Zaretskii , rms@gnu.org, emacs-devel@gnu.org To: storm@cua.dk (Kim F. Storm) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 09 23:56:52 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 1Hlu9S-0005R8-FZ for ged-emacs-devel@m.gmane.org; Wed, 09 May 2007 23:56:50 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HluGg-0004uh-O5 for ged-emacs-devel@m.gmane.org; Wed, 09 May 2007 18:04:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HluGc-0004rT-RM for emacs-devel@gnu.org; Wed, 09 May 2007 18:04:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HluGb-0004r5-Aj for emacs-devel@gnu.org; Wed, 09 May 2007 18:04:14 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HluGb-0004r2-8x for emacs-devel@gnu.org; Wed, 09 May 2007 18:04:13 -0400 Original-Received: from sanpietro.red-bean.com ([66.146.193.61]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Hlu9K-0007gp-FC; Wed, 09 May 2007 17:56:42 -0400 Original-Received: from localhost ([127.0.0.1]:44285 ident=kfogel) by sanpietro.red-bean.com with esmtp (Exim 4.63) (envelope-from ) id 1Hlu9I-0007S2-Aa; Wed, 09 May 2007 16:56:40 -0500 In-Reply-To: (Kim F. Storm's message of "Wed\, 09 May 2007 10\:57\:35 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.98 (gnu/linux) X-detected-kernel: Linux 2.6 (newer, 3) 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:70715 Archived-At: storm@cua.dk (Kim F. Storm) writes: > The problem with your principles is not only the (forever delayed) > release as such, but just as much the implied "feature freeze" which > is really blocking a lot of new development on the project. > > The current feature freeze has now lasted for more than 3 years, > during which Emacs _development_ has practically been at a > stand-still, so it is no wonder your team of _loyal_ developers is > getting frustrated and starts to question your principles, and > may start looking for other (more productive) projects to work on. What Kim said. I don't get excited about making improvements to Emacs these days, because I know I won't be able to check them in. So I make fewer of them. Again, I don't see any reason, in Emacs or any project, why there should be no place to check in bleeding-edge development changes. There is no technical reason why a release (or N simultaneous releases, for that matter) should impede new development work. The current state of affairs means that we are using our version control system poorly, or that we're making incorrect assumptions about the fungibility of volunteer developers' time (e.g., the false assumption that if someone is unable to work on new code, they'll just take that time and devote it to release work instead, which is obviously not true). This isn't meant as badgering, or as a personal attack. But I see a number of developers wishing we could have the same non-obstructive release process as other software projects... yet so far I've only seen two people (RMS and, sort of, Stefan Monnier) defend our current system, and the defenses have not really addressed the issues raised above. Maybe I've missed a few posts, but it seems pretty clear that a majority of developers would like to work in a different way. One possible response to this is: Emacs is not a democracy! :-) Okay, fine, but even in a dictatorship our release system can still be broken. I think it is, and I've described why above, concretely. The project doesn't have to be a democracy, but it does need to function. Why are we blocking new changes? Why not (say) have an open trunk, and use a release branch to isolate the release from churn, like other projects do? -Karl