From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Malformed interactive spec in replace.el Date: 06 Jul 2004 11:26:41 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20040706101540.5870.JMBARRANQUERO@wke.es> <20040706104047.587A.JMBARRANQUERO@wke.es> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1089106051 5810 80.91.224.253 (6 Jul 2004 09:27:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 6 Jul 2004 09:27:31 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Jul 06 11:27:25 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BhmEX-00088x-00 for ; Tue, 06 Jul 2004 11:27:25 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BhmEX-0006bN-00 for ; Tue, 06 Jul 2004 11:27:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BhmGX-0001X3-HO for emacs-devel@quimby.gnus.org; Tue, 06 Jul 2004 05:29:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BhmGN-0001W1-U3 for emacs-devel@gnu.org; Tue, 06 Jul 2004 05:29:20 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BhmGN-0001VU-3e for emacs-devel@gnu.org; Tue, 06 Jul 2004 05:29:19 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BhmGM-0001Uv-UY for emacs-devel@gnu.org; Tue, 06 Jul 2004 05:29:19 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BhmDr-0002dV-HZ for emacs-devel@gnu.org; Tue, 06 Jul 2004 05:26:43 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1BhmDq-0001KU-Qu; Tue, 06 Jul 2004 05:26:43 -0400 Original-To: Juanma Barranquero In-Reply-To: <20040706104047.587A.JMBARRANQUERO@wke.es> Original-Lines: 50 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:25473 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25473 Juanma Barranquero writes: > On 06 Jul 2004 10:35:45 +0200 > David Kastrup wrote: > > > That's a result of the recent disruptive changes of Stefan that were > > seemingly checked in without discussion. > > I don't know about "disruptive changes". I think in this case the > problem is something trivial, like a missing `progn'. > > > Could we restrict ourselves to changes that conceivably work towards > > getting into a consistent state for the release? > > This is an experiment: we're now trying to see whether we can "restrict > ourselves" into working to get a release out. And the way to do that is checking in completely new functionality that changes existing APIs, replaces existing functionality by something different without apparent need or discussion, and needs additional work to get it documented, tried out, compared to the behavior it replaces, and even just to work? It is my opinion that such changes should at the very least be only attempted if there is some consensus that they are unambiguously desirable for the next release. Our policy is feature freeze right now. "Policy" does not mean that exceptions are impossible, but then we should have some consensus about them. > Perhaps we can (and more power to us), and perhaps we cannot, and > then, other models (like branching for a release and leaving the > trunk open for people who wants to do new stuff) would be better. So you claim this is just Stefan's way of suggesting he thinks we should not concentrate on the release? > It's a matter of group dynamics, and much, I think, depends on the > size and cohesion of the group. > > But in any case I see no point in getting angry about the outcome :) I fail to see those changes as an "outcome" to an "experiment" trying to see whether we can "restrict outselves into working to get a release out". It's like eating a cake as an experiment for checking whether one can keep one's diet. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum