Package erlang-mode in a seprate repository

[phikal]

Is your feature request related to a problem? Please describe.

I am currently packaging a few packages for NonGNU ELPA, the new copyright-exempted repository packaged in Emacs. The issue is that ELPA mirrors the entire repository, which in the case of the erlang package adds significant unnecessary overhead that we would like to avoid.

Describe the solution you'd like

Extracting erlang-mode out of the otp repository, into a separate repository. To preserve the commit history, this could ideally be done using the git filter-branch command: I have already prepared an example here.

Describe alternatives you've considered

The alternatives are not packaging erlang by default in Emacs, or mirroring the entire repository. It seems neither is preferable.

Additional context

N/A.

[essen]

Alternative: Automating your example repository so that it gets pulled by ELPA?

[phikal]

I guess that would be possible (in fact the ELPA repository itself could be pulled in this way).

I will try to find out if/how a filter-branch'ed repository can be updated, and update this issue accordingly.

[bbatsov]

I think having the Emacs mode separately would be better for the maintenance overall - e.g. separate issue tracker, CI, maintainers and so on. I don't see much benefits of keeping erlang-mode in the OTP repo. (although I recall there was some historical reason for keeping it here)

[progfolio]

Is this being considered as an option? If so, what do we need to do to make it happen? As far as maintainers go, it would probably be best to see if any of the following contributors are interested:

$ git shortlog -n -s  -- lib/tools/*.el | head -n10
    54  Dan Gudmundsson
    28  Bozhidar Batsov
    20  Johan Claesson
    20  Rickard Green
    16  Kjell Winblad
    16  Magnus Henoch
    13  Raimo Niskanen
    12  Erlang/OTP
    11  Lukas Larsson
     7  Steve Vinoski

[progfolio]

@phikal

I will try to find out if/how a filter-branch'ed repository can be updated, and update this issue accordingly.

Any progress on this?

[phikal]

I had managed it, but I lost the script and don't remember how effective it was to update the repository if the main development were still to take place in this repository.

[progfolio]

I see. I think a better option would be splitting it out into its own repo entirely and allowing development to happen there. It seems like it'd be better for everyone involved.

[bbatsov]

Agreed.

[phikal]

If the current maintainers are interested, I agree that that would be the best way forward. But I have no effect on that decision, and don't know does.

[KennethL]

I can see several possible solutions:

1. Break out the emacs mode to a separate repo under github.com/erlang and let it have its own release cycle
2. Break out the emacs mode to a separate repo under github.com/erlang and bring it in to erlang/otp as a git subtree selecting explicit version to include in an OTP release.
3. Let it stay in the otp repo and extract the emacs mode to NonGnu ELPA

I think alternative 1 is attractive since it is simple but the problem is that the testing done as part of the tools application in OTP will not work unless it is moved and ported to the separate repo. Should be possible but with a bit more work than just breaking out the emacs repo. Another drawback with alt 1 could be that users are used to get the emacs mode with OTP , so there is no need to handle the emacs mode separately.

[phikal]

I think alternative 1 is attractive since it is simple but the problem is that the testing done as part of the tools application in OTP will not work unless it is moved and ported to the separate repo.

Are you refering to these tests? Or are there other more extensive tests that test the interoperation, which couldn't be done in a separate repository?

Another drawback with alt 1 could be that users are used to get the emacs mode with OTP , so there is no need to handle the emacs mode separately.

This has happened before with other languages. An immediate example that comes to my mind is Go.

[bbatsov]

Option 1 is the most common setup in the wild today. I think that 90%+ of Emacs users install packages via their preferred package manager and almost no one will notice it is the mode disappears from the erlang/otp repo.

This has happened before with other languages. An immediate example that comes to my mind is Go.

Ruby and ruby-mode also come to mind. I think it was the same with Haskell. The times are changing. :-)

3. Let it stay in the otp repo and extract the emacs mode to NonGnu ELPA

That's essentially what we have today (it's 5 minutes of work to submit something to NonGNU ELPA, as it only needs a build "recipe"), so I don't think it will solve any practical problems.

[phikal]

That's essentially what we have today (it's 5 minutes of work to submit something to NonGNU ELPA, as it only needs a build "recipe"), so I don't think it will solve any practical problems.

Not quite, the issue that prompted this discussion is that GNU ELPA and NonGNU ELPA both mirror the entire repository, and most of otp is not related to the directory with the package we are interested in. So while erlang-mode could have been added two years ago, we never did so because of this issue.

[bbatsov]

Ah, yeah - I forgot their recipes couldn't just pick specific files from the repo like MELPA. My bad.

[phikal]

No, a package specification can indicate a lisp-directory to use when building tarballs, but we considered the weight of mirroring the entire repository too much (also it would spam the emacs-elpa-diffs mailing list).

[bbatsov]

Got it. Well, all of this makes me like option 1 (& 2) even more. :-)