From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. Date: Thu, 9 Jan 2014 14:27:47 +0100 Message-ID: References: <87mwj6f23d.fsf@bzg.ath.cx> <20140109002754.GA22950@thyrsus.com> <20140109012554.GA23333@thyrsus.com> <20140109052705.GA3424@thyrsus.com> <20140109123702.GB5361@thyrsus.com> <20140109131337.GA6053@thyrsus.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1389274111 23582 80.91.229.3 (9 Jan 2014 13:28:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Jan 2014 13:28:31 +0000 (UTC) Cc: Bastien , Emacs developers To: Eric Raymond Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 09 14:28:38 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W1Ff2-0006wR-Bf for ged-emacs-devel@m.gmane.org; Thu, 09 Jan 2014 14:28:36 +0100 Original-Received: from localhost ([::1]:51954 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1Ff1-0000j9-VN for ged-emacs-devel@m.gmane.org; Thu, 09 Jan 2014 08:28:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58509) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1Fex-0000gc-JU for emacs-devel@gnu.org; Thu, 09 Jan 2014 08:28:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1Few-00054O-GE for emacs-devel@gnu.org; Thu, 09 Jan 2014 08:28:31 -0500 Original-Received: from mail-ee0-x22a.google.com ([2a00:1450:4013:c00::22a]:33497) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1Feu-00052x-H6; Thu, 09 Jan 2014 08:28:28 -0500 Original-Received: by mail-ee0-f42.google.com with SMTP id e53so1315597eek.15 for ; Thu, 09 Jan 2014 05:28:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1jJVGhV3dl5soceeC2Q/LvGedG//vgpWva+NqS4rUbk=; b=sRAVc7txkCqabUfxRZhNd9Q8Lq8uwJbWUcGDsWokM3krTt0+7BYiPEAGZvfTQ1aMXB buwGpkd67FhKkejeZdqDqiBweZswb8R0fEhCD8t3F3w1GIzUkATKupkPTCF/ofpSpUAf DBfWFTJo2RXXtliPcDp8W2gk46BI9GslTclNE5hn57gsdbduO0wOhDWH4SntoKT8j4Zj Tcexe71n/DxB8sWssWFz66MQUvFanBwakI2jeDX+n9JfKZHSsSp/9gyo5sRLIm5+KSF8 3PtbTun+fClJ9Uay+VmoFP86d2bYwN+4MLphRFPbpHefitQ4WSoFiREVL22DRgCxJPh5 XtfQ== X-Received: by 10.15.48.201 with SMTP id h49mr3302638eew.43.1389274107332; Thu, 09 Jan 2014 05:28:27 -0800 (PST) Original-Received: by 10.14.209.69 with HTTP; Thu, 9 Jan 2014 05:27:47 -0800 (PST) In-Reply-To: <20140109131337.GA6053@thyrsus.com> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c00::22a X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:167901 Archived-At: On Thu, Jan 9, 2014 at 2:13 PM, Eric S. Raymond wrote: > Wouldn't defining emacs-bzr-get-version as an obsolete function alias > for emacs-repository-get-version solve the problem in a way > satisfactory to both of us? Sorry, no. It is not compatible. Code has been written that understands the case that emacs-bzr-version isn't bound, or bound and nil, or bound and meaningful (with structure). That code will have to be changed if you insist in conflating it with your higher-level API which IMO is not really a new layer (Emacs is not going to have to deal with several underlying DVCS at once in its repository, as you said yourself a few messages ago; DVCS-specific functions and variables are not only not a bug, but a feature). > It wouldn't reintroduce a layering bug into loadup.el, and it would give you > your compatible API. Even accepting that it is a layering bug (which I don't), there's no problem in keeping it in loadup.el; that's why we have make-obsolete(-variable). We don't need to clean up in a hurry every possible clue of past mistakes; just fix the mistakes. And, as said, what you offer is not compatible. emacs-repository-version is not compatible with emacs-bzr-version; the structure was documented, it never was a magical, opaque cookie. J