Re: RFC: Adding BBDB to Emacs core

[Thomas Fitzsimmons <fitzsim@fitzsim.org>]

"John Wiegley" <johnw@gnu.org> writes:

>>>>>> "BB" == Bozhidar Batsov <bozhidar@batsov.com> writes:
>
> BB> You can add my voice to "I'd rather just have in ELPA (and we should be
> BB> 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.

I think the end result from the perspective of core Emacs maintainers'
maintenance burden would not be different in beneficial ways than BBDB
just being in core.

Quoting Stefan later in the thread, the (1) "fetch some packages from
elpa.git while building the Emacs tarball" method may allow for nice
out-of-the-box BBDB integration for an Emacs release, and solve the
problems I'm trying to solve for users of Emacs major release tarballs
(but not users/developers who build the Emacs they use out of git, and
I'd worry about last-minute integration of all this stuff -- who makes
sure it all works together, at what point before release?).

But method (1) wouldn't solve the EUDC package maintenance aspects for
me (EUDC requiring something not in the tree).  For that, we'd need
Stefan's solution (2) "also clone elpa.git when you clone emacs.git"
solution.  That may solve both cases if it's done completely, see below.

To get the same benefits for BBDB as it being in core, I'd want solution
(2) to ensure that core maintainers always clone BBDB into their tree,
so that they always build it.  Then they can check for compile errors,
and usage of new features, as they change the core parts of Emacs around
BBDB.  I get very useful patches to EUDC from the core maintainers from
time to time even though they don't know EUDC functionality or
internals; I would hope that with solution (2) I'd still get those types
of patches.

Assuming (2) achieves all that, from the core maintainer's perspective,
what's the difference?  The downside is they have two repos to deal
with, and the interactions between the two to always consider (e.g., do
we branch all of ELPA to match Emacs branches (probably not), or write
all ELPA packages to work on any Emacs branch (probably), etc.).

Or is there some other way of bumping ELPA packages up to first class
status that you're envisioning?  I'm willing to help experiment with
different approaches to solve EUDC/BBDB issues, FWIW, but as yet I can't
envision the end result.

(Philosophical aside: I really don't want to see Emacs major releases
become just an Elisp language runtime, class libraries and package
management.  That would be sad.  Emacs is special, not just another
language environment.  Package discovery via GNU ELPA (over the network)
just isn't the same as feature discovery within the running Emacs
instance -- there's always an extra level of annoyance, network access
and configuration associated with external packages.  I'm hoping that by
Emacs 27.1 I'll have a window manager in my text editor.

Maybe Emacs could do like GNU/Linux distributions and publish e.g.,
emacs-minimal-27.1.tar.gz alongside emacs-27.1.tar.gz though.)

Thomas