emacs-devel
[Top][All Lists]
Advanced

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

Re: ELPA policy


From: David Engster
Subject: Re: ELPA policy
Date: Tue, 10 Nov 2015 21:02:00 +0100
User-agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.5 (gnu/linux)

John Wiegley writes:
>>>>>> David Engster <address@hidden> writes:
>
>> This is not about reaching a consensus. This is about you giving proper
>> reasons for such a big change.
>
> To be clear, I would also put Eshell (though not pcomplete) into the category
> of "big things that should be in ELPA" -- albeit, the subset of ELPA that will
> be in the release tarball.
>
> It's hard to pin down why in a manner that fits in an e-mail. If Eshell were
> in ELPA today, and we were talking about moving it into core, I would have
> just as much trouble justifying that move too. Perhaps this simply underscores
> the fact that we don't have an agreed upon ELPA policy we can all refer to.

In my opinion, the main question is whether something provides
infrastructure for other packages to use. This is precisely what CEDET
tries to do. I wouldn't have much trouble with putting parts of CEDET in
ELPA, namely those parts that do not directly provide infrastructure,
like support for certain languages, project types, indexing tools, etc.

> OK, David, I won't decide this by fiat. Let us decide what our ELPA policy
> will be, until it becomes clear, based on that document, what should go where,
> and why. We'll defer discussions of package movement until we have that in
> place.

It is still not clear to me what exactly is gained by moving core
packages to ELPA. In my opinion, packages like Org, Gnus or CEDET didn't
create significant problems for Emacs development in the past. On the
contrary, it made sure that those packages were adapted quickly when
larger changes in core were made. Those changes got synced back upstream
by people like Bastien, Katsumi and me. So in my opinion, you are trying
to fix something that is not broken.

What actually *does* create problems are packages that don't have an
active maintainer. The 'big three' however are not among those.

-David



reply via email to

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