emacs-devel
[Top][All Lists]
Advanced

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

Re: PL support


From: Dmitry Gutov
Subject: Re: PL support
Date: Thu, 14 May 2020 03:59:56 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 12.05.2020 17:44, Eli Zaretskii wrote:

Most of the code in Emacs doesn't have an "owner", so this cannot work
for us.  Heck, we don't even have appointed few who'd triage every
report quickly and efficiently (which would be one way of preventing
too many people from reading too many email messages).

These are the main reasons why I'm wary of adding more packages to Emacs
core without solid justification.

I don't think adding a few more will cause any tangible changes.

True, but I'd rather we took the steps in the other direction.

It also seems like a missed opportunity to show that the Emacs leadership takes GNU ELPA seriously, that it *is* "almost part of Emacs" it has been touted to be rather than a collection of toys somewhere in the backyard.

That would mean incorporating the use of it in some official documentation. And what better examples to start with than Eglot and Company (or something else, maybe).

We
are also regularly retire packages to lisp/obsolete/.

We generally do that only when we're fairly sure the package has very little users, and/or its functionality has been superseded by other packages. Meaning the case where we already have no expectations of it ever being picked up.

But in cases where we think a package is still useful for some, just not important enough for us to carefully maintain, we could move it "somewhere visible" (and GNU ELPA is better for that than lisp/obsolete/) with an explanation, and with the hope that, if there are enough users, someone will pick up the responsibility.

I would also like to move out Gnus/Org/Tramp/CEDET personally, but all of these sounds like separate, difficult discussions.

Having more core developers should be a plus for sure, but the extra
cognitive load for everyone else seems unavoidable either way.

Of course.  But adding packages also tends to add core developers,
albeit slowly.

And then the developers leave, and we end up maintaining the packages more or less indefinitely. CEDET would be one example.

So it seems to me that the logical thing would be to try to slim it down
where feasible rather than simply keep growing.

Unless we are going to move a significant fraction, it won't help.  To
say nothing of the fact that ELPA packages shouldn't be abandoned,
they should still be maintained.  And moving a package to ELPA doesn't
cause someone outside of the core team to take ownership on that
package, so the overall burden will not be affected.

People read package description more often than they read the contents of lisp/obsolete.

We don't have to entirely un-maintain the "moved out" packages, the degree of continual involvement could be a subject of discussion, or it could be decided on a case-by-case basis.



reply via email to

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