Re: [PATCH] Add prettify symbols to python-mode

[Eli Zaretskii]

> From: Achim Gratz <address@hidden>
> Date: Wed, 23 Sep 2015 08:22:58 +0200
> 
> Stefan Monnier writes:
> > It is.  Python.el's maintainer has worked on the elpa scripts so that
> > GNU ELPA packages can be built directly from the emacs.git source code.
> > This way packages like python.el and seq.el which want to be bundled
> > with Emacs as well as distributed via GNU ELPA can do so without having
> > to duplicate them between elpa.git and emacs.git.
> 
> This is good, but I can't help thinking that the other way around would
> have been infinitely more useful.

Useful for whom, may I ask?

> In other words, emacs.git wouldn't contain any other eLisp than what
> it needs to bootstrap and pulling in everything else as a proper
> ELPA package while building.

It would be a nightmare for a small team of maintainers to keep such a
package in even an approximately good shape, QA-wise.  We currently
don't have enough manpower even for such a basic thing as timely
review of patches proposed by occasional contributors; how will we
ever be able to make sure hundreds of separately developed packages
could ever work together when pulled?

One of the gravest problems I see for the future of Emacs development
is that we slowly but steadily lose old-timers who know a lot about
the Emacs internals and have lots of experience hacking them, whereas
the (welcome) newcomers mostly prefer working on application-level
code in Lisp.  If this tendency continues, we will soon lose the
ability to make deep infrastructure changes, i.e. will be unable to
add new features that need non-trivial changes on the C level.

Moving most Lisp packages out of the core will give a tremendous boost
to this slippery slope, by even further detaching many contributors
from the core and segregating the core's ever dwindling bunch.  That
way lies stagnation and death.

Please don't even think about suggesting this, unless you plan to come
on board and become a very active member of the core team, responsible
for these aspects specifically.