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

[Achim Gratz]

Eli Zaretskii writes:
>> 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?

Users who want to have more control over which packages and versions
they use, system administrators that need to deal with multiple versions
of Emacs on the same system or across a bunch of systems and packagers
of distribution packets.  Last but not least the very maintainers of
said packages who will be relieved from the burden of keeping their
packages in sync with Emacs both ways.

>> 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?

It works by specifying the exact Git revisions (or tags) that are paired
up with that Emacs release (and these packages would be in the tarball
so no extra download happens when building from those).  If it's all in
ELPA anyway and already maintained from outside Emacs, then why should
these be copied again in emacs.git?

If you look around you'll find that quite a few other projects are doing
very similar things.  For instance, Perl bundles certain CPAN modules.
Yes, there's a constant discussion of what should be pure CPAN, what
should be "dual-life" modules and what should be purely core.

> 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.

That's an entirely different discussion, and one that I do not intend to
address in this thread.

> 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.

I don't see how what I proposed would even remotely cause that.  The
same people would develop the eLisp packages in the same way they are
doing it today and for each Emacs release the Emacs devs can chose which
version of those packages gets bundled.  If Emacs QA finds out there are
bugs to fix you can adress it to the package maintainers in the same way
as today (just the commits go to a different repository).

> 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.

No offense taken, but you can't be serious about telling me what to
think or what I can say or not under whichever conditions.


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

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds