Update coffee-mode in ELPA/move to ELPA #122

rrthomas opened this Issue Apr 14, 2013 · 9 comments


None yet
5 participants

rrthomas commented Apr 14, 2013

coffee-mode is in ELPA. After jumping through all the hoops to get it in there (copyright assignment &c.), the idea was that it should actually be maintained there, that is, in the "elpa" branch of the Emacs repo at: https://savannah.gnu.org/projects/emacs

For reference, here's a copy of the email I sent to Chris last July 10th:

coffee-mode has now been imported into the Emacs bzr repository. In order to continue to maintain it, you'll need to get a Savannah account, and request membership of the Emacs group (see below).

I imagine you'll also want to shut up shop on github, including some mixture of transferring existing issues and patches to Savannah, and losing them now. Since there's no automated way to transfer issues & patches as far as I know, probably it's worth applying as many as you can (to the new upstream, not to github!) to minimise the number that has to be transferred.

Even if you don't intend to spend much time on coffee-mode in the future, I suggest this work is worth doing in order to give coffee-mode a maintained future (once it's in Emacs bzr, any Emacs maintainer can commit updates). The github site can then be stubbed to point users to Savannah.

Tantus labor non sit cassus…


jart commented Apr 14, 2013

Are you trying to tell me that I have to learn a new version control system and become an emacs maintainer in order to keep working on this project? Is that hard?


rrthomas commented Apr 14, 2013

Ah, are you maintaining coffee-mode now?

Well…yes and no. Yes, you'd have to use bzr and Savannah; but to maintain a single file this is not so hard (indeed, I'm just going through this myself at the moment in order to push a couple of patches to Emacs). There's a quick-start guide for simple development of this sort here: http://www.emacswiki.org/emacs/BzrQuickStartForEmacsDevs

The advantage of maintaining coffee-mode in ELPA is that it's more likely to gain users and hence maintainance (if not maintainers) long-term, and in general it gets more love. The disadvantages are principally the different work-flow (but I hope as you can see that's a relatively small one-off cost), and that patches >15 lines need a copyright assignment to the FSF (which these days can be done entirely online, at least for US contributors).

If you decide this isn't for you, then it's probably better specifically to ask the ELPA maintainers to withdraw coffee-mode, so that users finding it there aren't disappointed by the out-of-date version and you don't suffer from either that bad impression or out-of-date bug reports, and then distribute it via more lightweight packaging systems (I see Marmalade is mentioned in another issue; even lighter is el-get, for which no action need be taken, as there's already a recipe for coffee-mode in el-get, and it always fetches the latest version direct from github).


jart commented Apr 14, 2013

Yes, I've been maintaining it... when I have the time :)

Would it be possible for me to just keep the contact information of an emacs maintainer on file so I can just email them the latest coffee-mode.el file whenever I cut a new release? I want the package to be in ELPA so it's easy for people to install. I'm happy to fill out whatever form you want online.

But I'm concerned that if development of this project is moved into the emacs tree on savannah, people wouldn't be able to understand how to contribute.


rrthomas commented Apr 14, 2013

Thanks for maintaining coffee-mode!

The simplest thing would be for you to get a Savannah account and, if you wanted to continue to maintain coffee-mode on github, simply check in a new version to Emacs's elpa branch every time you cut a new release. You can register on savannah.org and email bug-emacs@gnu.org explaining the situation (and perhaps Cc-in me in case I can help explain the situation). On the other hand, contributing via Savannah is easy: it's a GForge-based system, like the old SourceForge, and there's a patch tracker. Users can also email patches & bug reports to bug-emacs. From the perspective of a random Emacs user, who may not have come across github (I occasionally come across such people, hard to believe as it may seem) using Emacs-centric maintenance workflows is a simplification!

(I'm not an Emacs maintainer, or even currently a Coffee (and hence coffee-mode) user; I just happened to use it for a bit and did some work on getting it into Emacs as a result.)

I would say that it's probably most productive to take either the ELPA route OR the el-get route, and maintain coffee-mode in only one place.


jart commented Apr 14, 2013

You're very welcome!

I just want whatever's best for the user, and ELPA is the easiest way for them to install extensions despite the fact that it seems kind of like a gated community compared to npm/pypi/gems/pear/etc..

So I just signed up for savannah and sent that email out with you CC'd and hopefully they'll be open to the idea. I don't see much of a problem with having two development trees for such a simple project that'll probably be updated very rarely. Think of it like emacs is the stable branch and github is the unstable branch :)


rrthomas commented Apr 14, 2013

Good, I'll reply to your mail to link it to the previous list thread on the same subject. Thanks!


sandinmyjoints commented Apr 16, 2013

+1 for keeping some way of contributing to coffee-mode via github.

@magnars maintains a lot of modes for emacs on github and some of them are part of emacs itself. I know because I had to sign this FSF copyright assignments and I don't live in the US. Maybe talk to him he can probably give a lot of advice.
I would not move the development to Savannah unless of course you want to loose all contributors to the project who are more practical than RMS

dunn commented Aug 9, 2016

I see that coffee-mode is now in ELPA (https://elpa.gnu.org/packages/coffee-mode.html), but its version is stuck at If the ELPA repository isn't being maintained, it should probably be removed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment