[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: Adding BBDB to Emacs core

From: Roland Winkler
Subject: Re: RFC: Adding BBDB to Emacs core
Date: Mon, 16 Apr 2018 22:23:34 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

On Sun, Apr 15 2018, John Wiegley wrote:
>>>>>> "BB" == Bozhidar Batsov <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]