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: Wed, 15 Jun 2005 00:54:35 +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 1118790071 15256 80.91.229.2 (14 Jun 2005 23:01:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 14 Jun 2005 23:01:11 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 15 01:01:11 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DiKP7-00011z-W6 for ged-emacs-devel@m.gmane.org; Wed, 15 Jun 2005 01:01:10 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DiKRw-0002Cg-Sv for ged-emacs-devel@m.gmane.org; Tue, 14 Jun 2005 19:04:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DiKRQ-00027f-BB for emacs-devel@gnu.org; Tue, 14 Jun 2005 19:03:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DiKRH-000237-1x for emacs-devel@gnu.org; Tue, 14 Jun 2005 19:03:24 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DiKRG-00021J-Sq for emacs-devel@gnu.org; Tue, 14 Jun 2005 19:03:22 -0400 Original-Received: from [64.233.182.205] (helo=nproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DiKKe-0005ZW-N1 for emacs-devel@gnu.org; Tue, 14 Jun 2005 18:56:52 -0400 Original-Received: by nproxy.gmail.com with SMTP id i2so148723nfe for ; Tue, 14 Jun 2005 15:54:35 -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=hb5XXSy1Ad4K2vjasssJzzaIfZfJRhx/3ryVV8zfbNMpDSrQlSrhkXxhdtT9NNsW10XGAq/a3VytbDQmZYzJLD37uCJuh70bYXDEer0oSmkYYso23kSQw5sbiMirmU13vw0ZFLPaBgGjX37xm7+1mf4nelGQrFGCZUAYsVv4azs= Original-Received: by 10.48.4.10 with SMTP id 10mr108619nfd; Tue, 14 Jun 2005 15:54:35 -0700 (PDT) Original-Received: by 10.48.250.5 with HTTP; Tue, 14 Jun 2005 15:54:35 -0700 (PDT) Original-To: Eli Zaretskii 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:38843 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:38843 On 6/14/05, Eli Zaretskii wrote: > I don't think the procedures are the main culprit, or even an > important one. I didn't say "the procedures preclude speedy releases", only that they "don't induce" them. > What holds the release is the enormous amount of > mundane work to be done before we consider ourselves ready for the > next release This is part of the procedures I'm talking about. Or, call it quality standards, if you prefer. It's obvious Emacs releases are of very high quality. I, for one, would much prefer yearly releases of medium-high quality than fourth-year releases of insuperable quality. I think frequent releases (I'm not talking weekly or even monthly, but certainly yearly doesn't seem outrageous) help increasing both the user and developer base of a free project. (This is a subjective perception, of course; YMMV.) > and the relatively small number of people who get > themselves busy working on those mundane issues. Why so few developers involve themselves in "mundane" issues? Perhaps they don't feel the issues are *that* important, or maybe they don't feel qualified to do the work (I know that happens to me with a lot of bugs, and certainly I don't feel comfortable writing English documentation). But, whatever the reason, it is a *fact* that there's so many people who will do the footwork, no more and no less. Three years of freeze didn't increase the number significantly. Complaining will not change things (I'm not speaking of you personally, of course.) > It's not useful to blindly copy procedures from other projects, IMHO. I know. In fact, I think you said the same thing last time I brought the issue ;-) > Most of them don't get anywhere near Emacs in complexity and diversity > of the features, nor are their different subsystems so loosely coupled > as they are in Emacs, and so demanding many different talents and > expertise in many almost unrelated fields. Most of them do not. Some others do: Linux (kernel), GNU/Linux, FreeBSD, Gnome, GCC... these are complex beasts and still they do appear regularly. > There are other important factors not to be forgotten: for example, the s= tate of the > documentation of most other projects is abysmal compared to Emacs, > largely due to Richard's insistence on having the manuals updated and > proofread several times before Emacs is declared as release-ready > (which, of course, holds off releases, sometimes for a very long > time). Etc., etc. I know that; Emacs documentation is one of its stronger points, and I like it a lot. Still, many projects make do with suboptimal documentation. It's nice having good docs, but good docs aren't any good if they, and the features they document, stay on the CVS for years and years. I suppose what I'm saying is: yeah, I know what our rules are, and our quality expectations. It'd be very nice to have a hundred people ready to smash the release into being, by implementing these requirements and in short notice. It's Just Not So. And so, we've taken three and a half years in coming to a point where the release is not only not much stable than a year or two before (I'm not saying "not more", just "not much"), but the funny thing is: we *don't* know when we'll be able to do a release. We can't plan. We can't have a tentative schedule. We're somehow hoping that we all will feel guilty or something and stop developing new features and go hacking at etc/FOR-RELEASE items. I don't think that's likely. I'm not diminishing anyone's work by saying that: I know of the people who's steadily improving documentation, etc. But results speak by themselves. I don't know what the magic bullet is, but arguments and feelings aside, I don't think anyone can negate the truth that we aren't doing new releases. That's a fact. So, we can consider what we do, and what we ask for a release, and decide whether we are doing (and expecting) the Right Thing or not. Last time we discusses that I brought the example of Subversion (and was said it was a much smaller project :). I know. But they do something which I find quite interesting: they plan a release, and they try hard to stick to the date, even if they *know* it won't be perfect. They're not afraid of getting 1.2.0 out even if they know about non-critical bugs; 1.2.1 will follow in a few weeks. I think this generates good karma. --=20 /L/e/k/t/u