From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: FOR-RELEASE.W32 Date: Tue, 09 Aug 2005 12:03:51 +0200 Message-ID: <42F87F87.7070209@student.lu.se> References: <853bpjwiul.fsf@lola.goethe.zz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1123585525 4469 80.91.229.2 (9 Aug 2005 11:05:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 9 Aug 2005 11:05:25 +0000 (UTC) Cc: Juanma Barranquero , Emacs Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 09 13:05:23 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1E2Rv6-0004bA-Ay for ged-emacs-devel@m.gmane.org; Tue, 09 Aug 2005 13:05:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1E2Ry8-0001Hq-IC for ged-emacs-devel@m.gmane.org; Tue, 09 Aug 2005 07:08:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1E2RU0-0001XH-Lo for emacs-devel@gnu.org; Tue, 09 Aug 2005 06:37:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1E2RTz-0001Wa-Gq for emacs-devel@gnu.org; Tue, 09 Aug 2005 06:37:19 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1E2RR9-0008Uk-0V for emacs-devel@gnu.org; Tue, 09 Aug 2005 06:34:23 -0400 Original-Received: from [81.228.11.98] (helo=pne-smtpout1-sn1.fre.skanova.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1E2RBZ-0006m9-85; Tue, 09 Aug 2005 06:18:17 -0400 Original-Received: from [192.168.123.121] (83.249.204.33) by pne-smtpout1-sn1.fre.skanova.net (7.2.060.1) id 42B813B0007684D1; Tue, 9 Aug 2005 12:03:55 +0200 User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en Original-To: David Kastrup In-Reply-To: <853bpjwiul.fsf@lola.goethe.zz> 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:41771 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:41771 David Kastrup wrote: >Juanma Barranquero writes: > > > >>As Richard has said that Emacs-on-Windows problems shouldn't delay >>the release, Lennart and I have been thinking of adding a file >>(tentatively named admin/FOR-RELEASE.W32) listing things that would >>be nice to have before releasing a binary tarball for Windows. >> >> > >Personally, I think really bad problems on Windows should at least >delay the release of a Windows binary: Emacs is one of the most >important migration applications to GNU systems: once a Windows user >uses Emacs for his editing tasks (and utf-8 is increasing our chances >here), he'll be likely to install the GNU utilities (MSYS or Cygwin) >so that many of Emacs' external commands will work. And then the step >to going GNU all the way is rather small. > > I really agree to this. >In my opinion, a good Windows Emacs is useful for getting people to >use GNU. That does not mean that Windows problems should delay >releasing 22.1 for Unix-type systems, but I would tend not to release >Windows binaries that are deficient. Even if that means that such >binaries will only appear with 22.2 or so. > I do not believe that minor problems in w32 or any other port should delay the main release. However we do have one major problem (emacsclient/server not working) and I think that is so serious that it should be fixed before release. Otherwise I think we get a bad impression on w32 and that does not help us reach our goals. I would also suggest handling minor platform specific problems with platform specific "subreleases". On such case is the lacking documentation for w32 specifics. I see no reason to handle binaries on w32 different than the source code there. Maybe you mean that we just should not make any w32 release until major problems are fixed there?