[Top][All Lists]

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

Re: ELPA policy

From: Achim Gratz
Subject: Re: ELPA policy
Date: Mon, 09 Nov 2015 20:58:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Eli Zaretskii writes:
> If that's not on the table, then please tell what in your opinion _is_
> on the table.  You did want to propose something practical that could
> be done soon, right?  Because this discussion was about what we want
> to do from now on with ELPA, not what we might want considering in
> some distant future that might never come.

I did want to propose something that could become a vision for some time
in the foreseeable, yet somewhat distant future that we can then take
steps towards.  ELPA is foremost for _users_ and any decisions taken
should put the users first and developers second.  As a user I don't
have the luxury of chosing which Emacs version I get to use and what
packages are already installed on the system (indeed in my day job that
changes when I switch between project workspaces).  Wouldn't it be
splendid if ELPA helped me making those differences fade into the
background, if not disappear entirely?

> So please, let's be practical and consider alternatives that
> realistically can be taken soon.  Like tomorrow or the next month.
> Okay?

No, not okay.  There's still no consensus of even roughly where we want
to end up, so starting a random walk to find out who's feeling well or
not with whichever direction is certainly not my idea of progress.

> Moving out a few large packages that are developed outside Emacs
> anyway is a no-brainer, provided that their developers agree.

Again, it's not.  It simply doesn't work at this moment, not for Emacs,
not for the package developers and not for the users.  That doesn't have
anything to do with the size of those packages best I can tell.  To
change that (without moving the sources anywhere, just to not go down
that rabbit hole again) we'd need to devise a way to have an Emacs core
package whose autoload definitions can be separated and that can be
overridden (maybe only with a newer version) on the installation level
or by the user.  That would be the first step before any others can
follow, provided you even want to go that direction.

+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:

reply via email to

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