From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Roland Winkler Newsgroups: gmane.emacs.devel Subject: Re: RFC: Adding BBDB to Emacs core Date: Mon, 16 Apr 2018 22:23:34 -0500 Message-ID: <87vacqcy89.fsf@gnu.org> References: <87lgdpphmm.fsf@ericabrahamsen.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1523935298 2721 195.159.176.226 (17 Apr 2018 03:21:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 17 Apr 2018 03:21:38 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) Cc: Joshua Branson , emacs-devel To: Bozhidar Batsov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 17 05:21:34 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f8HBW-0000am-38 for ged-emacs-devel@m.gmane.org; Tue, 17 Apr 2018 05:21:34 +0200 Original-Received: from localhost ([::1]:36102 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f8HDc-00054t-1F for ged-emacs-devel@m.gmane.org; Mon, 16 Apr 2018 23:23:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51260) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f8HDV-00054Y-J0 for emacs-devel@gnu.org; Mon, 16 Apr 2018 23:23:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f8HDU-0005tX-Jp for emacs-devel@gnu.org; Mon, 16 Apr 2018 23:23:37 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59702) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f8HDU-0005s9-Fl; Mon, 16 Apr 2018 23:23:36 -0400 Original-Received: from [2602:30a:2e52:d720:65b7:1416:12e7:8bfb] (port=35430 helo=regnitz) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1f8HDU-0006ND-04; Mon, 16 Apr 2018 23:23:36 -0400 In-Reply-To: (John Wiegley's message of "Sun, 15 Apr 2018 22:21:58 -0700") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:224697 Archived-At: On Sun, Apr 15 2018, John Wiegley wrote: >>>>>> "BB" == Bozhidar Batsov writes: > > BB> You can add my voice to "I'd rather just have in ELPA (and we > BB> should be moving more and more packages there). > > Same here. I really don't want to see BBDB moved into core. I do want > ELPA packages to become more "first class" than they are now, so that > the desire to add such packages to core would no longer have the same > appeal. In general I tend to agree. Yet it appears to me that so far there is one problem with GNU ELPA: I believe it would help to have a better separation between ELPA being the repository for the distribution of stable versions of packages to normal users and ELPA being the repository for the development of such packages. With core Emacs, we have a master branch with the latest and sometimes buggy code. And occasionally there is a proper release with significant efforts that these releases work reliably for normal users. So far ELPA does not support such a model. - Take BBDB as an example: It is not too difficult to break a user's database by trying to improve some of BBDB's internal functions. That's why right now I prefer to continue to use BBDB's repository on savannah for code development. When a code change appears to be sufficiently stable, it is also added to BBDB in ELPA. Certainly, this is a non-ideal approach. I am wondering: Could it make sense to have a separate infrastructure like "ELPA-devel" for the on-going development of ELPA packages, where adventurous users find the very latest code similar to the master branch of core Emacs. On the other hand, ELPA becomes the place for stable versions of these packages. My terminology "separate infrastructure" is intentionally vague, because I do not yet have a clear idea how this can be implemented efficiently. A simple scheme could be a policy for naming development and release branches of packages in the ELPA git repository (beyond the current "externals" branches for individual ELPA packages), combined with tools that allow one to access one or the other version of a package. Or yet something different. Roland