Re: Brand new clojure support in Emacs ;-)

[Stefan Kangas <stefankangas@gmail.com>]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> Other than the contributor agreement there's development overhead to consider:

Thanks, I found your list of concerns interesting.

> - where are issues reported? I don't want to use the Emacs issue
> tracker, but that'd be unavoidable for something built-in, so instead
> of having one issue tracker you end up with two (one of which I really
> dislike)
> - some patches will be submitted on GitHub, some on emacs-devel - I
> highly doubt that all the clojure-mode maintainers would be willing to
> deal with this

These concerns are valid, but disproportionate.

Most users will not want to send email, and are a million times more
likely to go to GitHub and follow the workflow they are used to there.

With a package like Org-mode, we only have the occasional bug come to
the bug list or emacs-devel, and in short order someone will point them
in the right direction.  But users normally follow the instructions
given to them by the org developers, and send it directly to their list.

Even with use-package, a package that was merged into core and where we
plan to deprecate and eventually archive the GitHub page, more
discussion, issues, and even PRs end up on GitHub.

Basically, the position is that for GNU ELPA packages, we *accept* bugs
in the bug tracker, but we don't necessarily encourage it.  From our
point of view, we are usually much happier if the bugs go to the
maintainers directly, as they are in the best position to resolve them.

> - discussions related to problems/ideas would be happening in
> different places

This will only very occasionally be true, but mostly it will be as
above: expect 99 % of relevant discussions in your preferred forum.

The exceptions will be, for the most part, when Emacs developers need to
ask you something over email, or point some wayward users in your
direction.

> - there's also so overhead of keeping the GitHub repo and the code in Emacs in sync

That's true.  In practice, you could do this one or two times a year, or
even once before every release, and nothing bad would happen.

Some packages merge much less frequently too, but that's not ideal for
obvious reasons.