Re: RFC: Adding BBDB to Emacs core

[Roland Winkler <winkler@gnu.org>]

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