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: Feature freeze and Tramp? Date: 02 May 2004 21:19:39 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <87zn8qlleb.fsf@emptyhost.emptydomain.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1083525713 32543 80.91.224.253 (2 May 2004 19:21:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 2 May 2004 19:21:53 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun May 02 21:21:45 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 1BKMX3-0001es-00 for ; Sun, 02 May 2004 21:21:45 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BKMX3-0006uN-00 for ; Sun, 02 May 2004 21:21:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BKMVf-000396-Nc for emacs-devel@quimby.gnus.org; Sun, 02 May 2004 15:20:19 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BKMVa-00035n-Mf for emacs-devel@gnu.org; Sun, 02 May 2004 15:20:14 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BKMV4-0002Vv-F2 for emacs-devel@gnu.org; Sun, 02 May 2004 15:20:13 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BKMV4-0002Vp-6Y for emacs-devel@gnu.org; Sun, 02 May 2004 15:19:42 -0400 Original-Received: from fencepost.gnu.org ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.24) id 1BKMV3-0000Kc-4u; Sun, 02 May 2004 15:19:41 -0400 Original-To: Kai Grossjohann In-Reply-To: <87zn8qlleb.fsf@emptyhost.emptydomain.de> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 Original-Lines: 42 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 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:22552 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22552 Kai Grossjohann writes: > I'm not sure what I should do about Tramp given the feature freeze. I > would like to merge 2.0.40 with Emacs, but it is not purely a bugfix > release: 2.0.39 contained half of the functionality needed for > password caching (it has the password cache), 2.0.40 supplies the > other half (it /uses/ the password cache). > > There is now a stable branch in the Tramp repository so that it is > easier to make sure that future revisions in the 2.0 series are > bugfix-only. > > What should I do? In a stable release, there really is no place for half-implemented stuff. Either one should rewind to the state before the half-implementation, backing it out modulo bug-fixes, or one should complete it. Considering the additional work of maintaining a separate back-ported branch that would have to be created separately, and considering the relative youth of the feature freeze and the number of things that have just gotten in, I'd say in this case put it in and maintain the stable branch from this point on. Considering your narrow focus, it is highly unlikely that problems with Tramp 2.0.40 will slow down the proper release in any manner. The purpose of the feature freeze is to concentrate on getting work done and finished, not on starting new work in the form of backports. Unless this appears necessary for getting the release out. I think that the additional work of backports will mostly be warranteed close to the finishing line. Half-finished stuff should get finished or taken out. Unless this affects stability, I'd opt for putting it in in this case. If it turns out that this has been the wrong choice, we can still back it out again. The same holds for other stuff: if it turns out that we have no way to get them stable in reasonable time, there will be a point of time when we rather take them out than try to fix them. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum