From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Chong Yidong" Newsgroups: gmane.emacs.devel Subject: Re: What holds the release (was: mouse-1-click-follows-link) Date: Wed, 15 Jun 2005 11:05:58 -0400 (EDT) Message-ID: <3158.220.255.175.166.1118847958.squirrel@www.stupidchicken.com> References: <8564wi2ag7.fsf@lola.goethe.zz> <17070.36649.525270.871681@farnswood.snap.net.nz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1118847965 5202 80.91.229.2 (15 Jun 2005 15:06:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 15 Jun 2005 15:06:05 +0000 (UTC) Cc: Juanma Barranquero , Eli Zaretskii , miles@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 15 17:05:55 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DiZSQ-0001V2-F4 for ged-emacs-devel@m.gmane.org; Wed, 15 Jun 2005 17:05:34 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DiZXe-0007ze-Ku for ged-emacs-devel@m.gmane.org; Wed, 15 Jun 2005 11:10:58 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DiZVG-0006xM-Ql for emacs-devel@gnu.org; Wed, 15 Jun 2005 11:08:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DiZVA-0006ui-3V for emacs-devel@gnu.org; Wed, 15 Jun 2005 11:08:24 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DiZV9-0006sX-Tn for emacs-devel@gnu.org; Wed, 15 Jun 2005 11:08:23 -0400 Original-Received: from [64.21.80.18] (helo=shark.dnsvelocity.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1DiZUU-0001gq-C7; Wed, 15 Jun 2005 11:07:42 -0400 Original-Received: from stupidch by shark.dnsvelocity.com with local (Exim 4.50) id 1DiZSp-0002qE-1y; Wed, 15 Jun 2005 11:05:59 -0400 Original-Received: from 220.255.175.166 ([220.255.175.166]) (SquirrelMail authenticated user cyd@stupidchicken.com) by www.stupidchicken.com with HTTP; Wed, 15 Jun 2005 11:05:58 -0400 (EDT) In-Reply-To: Original-To: snogglethorpe@gmail.com, miles@gnu.org User-Agent: SquirrelMail/1.4.4 X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - shark.dnsvelocity.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [32675 33085] / [47 12] X-AntiAbuse: Sender Address Domain - stupidchicken.com X-Source: /usr/local/cpanel/3rdparty/bin/php X-Source-Args: /usr/local/cpanel/3rdparty/bin/php /usr/local/cpanel/base/3rdparty/squirrelmail/src/compose.php X-Source-Dir: :/base/3rdparty/squirrelmail/src 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:38888 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:38888 > The thing is, the trickiest-sounding items in FOR-RELEASE -- those > under the "* FATAL ERRORS" section -- also sound like some of the > most important. Releasing an Emacs that crashes in recent kernels > isn't so nice... > > [Many of the other items seem not so important to me; I suppose if > nobody can be found to fix them, many of those could just be dropped > without noticeably decreasing the quality of the release.] It may be better to be specific, so here are the contents of FOR-RELEASE, as well as some of my opinions on them. I haven't contributed as much to Emacs as the others on this list, so my opinion about various bugs "not worth blocking the release" may seem arrogant. However, I'm pretty frustrated, because helping to get the 22.1 release out the door seems like a sisyphean effort -- more stuff keeps getting into FOR-RELEASE, and the release that's coming "soon" keeps getting pushed back! It's a vicious cycle -- people want to check in every last bugfix, because the next release will be year away. But the reason for the long release cycles is that big bugfixes keep getting checked in, creating still more bugs to fix! In many projects, a "feature freeze" includes a moratorium on fixes for fringe problems, or those that can't be fixed without major destabilizing changes. Several of the items in FOR-RELEASE seem to be of this variety. > Make VC-over-Tramp work where possible, or at least fail > gracefully if something isn't supported over Tramp. > To be done by Andre Spiegel . This has been sitting there for several months now. Has it already been done? Is it a major inconvenience worth delaying 22.1 for? > define-minor-mode should not put :require into defcustom. > See msg from rms to emacs-devel on 21 Dec. The relevant URL is http://lists.gnu.org/archive/html/emacs-devel/2004-12/msg00732.html I've tried working on this, with no result. I couldn't find a clean way to implement RMS's suggestion, and I'm not sure it even makes sense. A workaround for the particular problem originally reported by Stephen Stahl is to add (require 'font-lock) to font-core.el and a ":require 'font-lock" tag to the definition of global-font-lock-mode. Maybe we should just do that, and wait for 22.2 for whatever general solution is required. (It would be *nice* to get it into 22.1, but what it would *not* be nice to delay 22.1 into 2006 just for that.) > ** Update Speedbar. The relevant URL is http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg00180.html It sounds like this will be fixed soon. > Enhance scroll-bar to handle tall line (similar to line-move). This is a feature request, not a show-stopping bug. In the real world, 99.9% of users don't use Emacs as an image viewer; they use a specialized image viewing program. Emacs is currently a mediocre image viewer; it would be nice if it were a great image viewer, but not essential for the release. > Adapt mouse-sel-mode to mouse-1-click-follows-link. I fixed this a couple weeks ago. This entry should be removed. > Make unexec handle memory mapping policy of the latest versions of > Linux. If I understand correctly, this problem only crops up on Red Hat systems running ExecShield, which has been known to cause problems with other programs -- not just Emacs. Furthermore, this is a non-trivial bugfix, so introducing it at this stage will probably create still more bugs, which will delay the release yet again... > Investigate reported crashes in compact_small_strings. This seems to be a real bug. Relevant URLs are: http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-10/msg00374.html http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-11/msg00143.html http://lists.gnu.org/archive/html/bug-gnu-emacs/2005-04/msg00224.html In the last of these messages, the reporter said he could get "reliable" crashes, but somehow the discussion wasn't followed up. > Investigate reported crashes related to using an invalid pointer > from string_free_list. I couldn't figure out which bug report this refers to. > Ange-ftp should ignore irrelevant IPv6 errors: I've tried contacting the bug reporter, but he has not responded to any of my three messages over the last two months. My DNS server also returns IPV6 addresses, but I do not experience this problem. I suspect it only shows up for rare broken configurations that include a router and/or FTP program that doesn't handle IPV6 properly. It may not be worthwhile delaying the release for this. > Make GTK scrollbars behave like others w.r.t. overscrolling. I don't experience any problem with GTK scrollbars. It does not seem to be a show-stopper. > Avoid unbreakable loops in redisplay. This is an "it would be nice" feature, not a show-stopper. It would be nice to have a safety feature to avoid running inappropriate display properties, but AFAIK people aren't actually being affected by such bugs. This shouldn't block the release. > Finish updating the Emacs Lisp manual. Seems pretty much done. > Update lispref/README. What needs to be done here? > Update the Emacs manual. Seems done. > Update AUTHORS. Already done. > Reorder NEWS entries. Already done. > Check the Emacs manual. Already done (some chapters have only been checked by one guy, not two.)