That's formally true, but doing this over the objections of the
original authors would be IMO rude, and I would not agree to that
lightly.
I agree that'd be rude. I also think that'd be quite confusing for the end users and will make some of the operations (e.g. submission of bugs) a total mess. Neither the Clojure, nor the Emacs communities are big enough to engage lightly in time-wasting activities.
And, I'll say it once more - in case this was missed in the conversations. Personal misgivings about the mechanics of Emacs's development aside, I think it's not prudent to keep growing its core, which is already huge. Obviously it's up to the Emacs developers to decide what to do, but I'd be moving more things into packages and bundling less things with Emacs. You might have seen this trend in some programming languages - e.g. Ruby has slimmed down its core a lot and this helped channel the efforts of the core team.
I think by now pretty much every user of an editor or a programming language is used to installing packages to augment the core functionality, so I'm not buying the argument that we need to have more things OOTB. IMO the core of Emacs should consist of fewer, but truly essential packages.
Someone mentioned it'd be nice if Emacs suggested packages to install for certain (unsupported OOTB) file types and I think that'd be a nice way to help with package discovery. Perhaps packages can just mention this in their metadata?
On Tue, Aug 29, 2023, at 5:27 AM, Eli Zaretskii wrote:
> Date: Mon, 28 Aug 2023 16:03:27 -0400
>
> Whatever authority Bozhidar has is over the project he's a maintainer
> of, not over emacs or clojure features incorporated in it, or even,
> frankly, the software produced by his project. It is licensed as free
> software, after all. The only meaningful constraint on the creation of
> a fork, major or minor, of free software is the pain involved in
> maintaining such forks.
That's formally true, but doing this over the objections of the
original authors would be IMO rude, and I would not agree to that
lightly.
> I'm not sure why you would assume the project that
> created/maintains/develops an external package would necessarily want
> to contribute the additional labor required to participate in the
> emacs development process. If the emacs project wants to incorporate
> such a package in core, it's not unreasonable to expect it to provide
> the resources required rather than expecting the additional labor be
> done by the external project.
The Emacs project can and does provide additional labor, but not when
the authors object to including their package.