From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Pretest Date: Sun, 19 Nov 2006 11:18:48 +0100 Message-ID: <85wt5reo3b.fsf@lola.goethe.zz> References: <87slggjtbb.fsf@furball.mit.edu> <455F9024.8080000@student.lu.se> <17759.43936.82301.353794@kahikatea.snap.net.nz> <85irhbg6zx.fsf@lola.goethe.zz> <17760.11257.78362.216206@kahikatea.snap.net.nz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1163931729 25575 80.91.229.2 (19 Nov 2006 10:22:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 19 Nov 2006 10:22:09 +0000 (UTC) Cc: Lennart Borgman , Chong Yidong , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 19 11:22:06 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GljoH-0000tj-4O for ged-emacs-devel@m.gmane.org; Sun, 19 Nov 2006 11:22:01 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GljoF-0004k1-Vc for ged-emacs-devel@m.gmane.org; Sun, 19 Nov 2006 05:22:00 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GljlS-00038y-2A for emacs-devel@gnu.org; Sun, 19 Nov 2006 05:19:06 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GljlQ-00037g-JK for emacs-devel@gnu.org; Sun, 19 Nov 2006 05:19:05 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GljlQ-00037T-BY for emacs-devel@gnu.org; Sun, 19 Nov 2006 05:19:04 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GljlQ-0008Ed-Ay for emacs-devel@gnu.org; Sun, 19 Nov 2006 05:19:04 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1GljlP-0000T3-FH; Sun, 19 Nov 2006 05:19:03 -0500 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 4628E1C4D3DE; Sun, 19 Nov 2006 11:18:48 +0100 (CET) Original-To: Nick Roberts In-Reply-To: <17760.11257.78362.216206@kahikatea.snap.net.nz> (Nick Roberts's message of "Sun\, 19 Nov 2006 23\:03\:37 +1300") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.90 (gnu/linux) 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:62459 Archived-At: Nick Roberts writes: > > > > We are currently working with emacsclient. It would be very > > > > good if our changes in emacsclient were included in the > > > > pretest. We need a little bit more time for resolving some > > > > issues and for testing. > > > > > > It sounds like it's too late. If the issues can't be resolved > > > quickly perhaps the changes should be reverted. > > > > What sense is in reverting changes if it is too late? > > Too late to include changes in a pretest that is already out! The > changes were made after the first pretest for a bug that was deemed > non-critical by Richard. It seems a bit rich to ask for more time a > month later. If it's quicker to revert them than to resolve then > that seems to make sense to me. It seems like we have completely different recollections of events. As far as I remember, Richard oked getting emacsclient to work on Windows even after the first pretest (where emacsclient was not yet a part of Emacs). There is no point whatsoever in reverting to the state of the first pretest, namely "non-working". Whether there is sense to reverting to a later point of development has not been discussed yet: up to now the developers tried getting the functionality to do the right thing. Telling them that they should stop doing so and revert to some earlier stage would require agreement on just what this earlier state should be. "non-working" is what you demand. Up to now there has been no discussion about where we should exactly draw the line with regard to emacsclient (work is still going on), but I don't think that "non-working" would get much support. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum