That's good to hear and it sounds fairly reasonable to me. I'm guessing that the hardest part will be getting everyone to sign the CA, as there were quite a few contributors over the years. (and ideally we'll need some simple way to get new contributors to sign the CA - I'm not sure what's the process these days)
One more thing that came to mind is how are we going to deal with updates of package that happen between Emacs major releases. I'm guessing that clojure-mode should also be available on GNU ELPA, so users can update to the latest version, right?
If you don't mind - I'd like to ask to put the topic on hold for a bit here, so I can discuss it properly with the other members of clojure-emacs and hear how they feel about it. If you truly believe that it'd be important to include clojure-mode in Emacs we'll consider this carefully. I hope you'll agree that's not super time sensitive and there's no need to make hasty decisions.
Despite the unpleasant tone of the conversation at times, I'm trying to keep an open mind here and I appreciate everyone who has provided some constructive opinions to the discussion.
> Date: Sun, 03 Sep 2023 17:37:07 +0200
>
> - 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)
There's no requirement to use debbugs for your package, even if it is
in core. Org, for example, doesn't. When people submit bug reports
about Org to debbugs, we redirect them to the Org list.
> - 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
Same here: there's no requirement to have patches submitted directly
to us. Quite the contrary: as long as you and your colleagues
actively develop and maintain the package, we'd prefer that patches
are first reviewed by you.
> - discussions related to problems/ideas would be happening in different places
Again, not a requirement. But yes, the developers should be available
on emacs-devel, because issues could pop up here. You could have a
representative, though, not all of you.
> - there's also so overhead of keeping the GitHub repo and the code in Emacs in sync
Ihor and others should correct me, but what overhead do you have in
mind? We already have a few packages that are basically developed
outside of Emacs and only merged with Emacs from time to time, so you
will not be the first package to go that way.
> I can go on and on about this - hybrid development models simply come with a lot of overhead. I get
> that here many people think that GitHub is the root of all evil, but political preferences aside - it's the
> largest forge in the world by a huge margin and I think it provides unique benefits to projects that
> can't be replicated elsewhere. At least not today.
I think the difficulties are not as great as you imagine. And our
opinions about GitHub are not relevant if the package is regularly
merged into emacs.git.