Re: Semantic: update or remove?

[Eli Zaretskii]

> From: Psionic K <psionik@positron.solutions>
> Date: Fri, 14 Mar 2025 10:25:05 +0900
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> The logic put forth is quite simple.  Let's first divide Emacs built-in 
> packages into two groups, those that
> implement technical consensus and those that do not:
> 
> 1.  Those that provide strong technical consensus for downstream packages.  
> These are things that
> implement the language, the Elisp interfaces for C primitives etc.  
> Everything in the Elisp manual is pretty
> much in this group.  As a package maintainer or author, these things must be 
> good and definitely need to be
> in Emacs.  While the data structure chosen for keymaps may be a pain in the 
> ass, if there were multiple
> kinds of keymaps implemented ad-hoc in the external package ecosystem, the 
> pain could only be worse. 
> These packages have an overwhelming basis for cooperation.  A strong litmus 
> test for implementing
> technical consensus is the existence of numerous dependents.
> 2.  Packages that are not part of the technical consensus.  I am not really 
> aware of what arguments exist for
> these to be part of Emacs.  I suppose it includes things like "batteries 
> included" and receiving better
> maintenance and integration.  We can predict that pushback will have taken 
> the form of not wanting to
> create de-facto standards for behaviors that we expect to undergo constant 
> evolution.

Your analysis of the issue is too black-and-white.  In reality,
there's a very large gray area: packages which aren't infrastructure
and are stable, so they don't receive too many changes.  That doesn't
yet mean they can or should be removed from Emacs, because there could
be a non-negligible number of users who use them and depend on them
being available.

Our policy is not to remove packages unless they are really obsolete
and not useful, and even that after keeping them in lisp/obsolete/ for
some time, to let users enough time to object to their removal.  We
respect our users and don't remove packages just because we can.