Uwe Brauer writes: >>>> "AC" == Andrea Corallo writes: > >> Uwe Brauer writes: >>> Hi all >>> >>> After quite a bit of time I can say the following : >>> >>> 1) All authors/contributors have either signed the corresponding FSF >>> papers, in the very few cases where they have not, their >>> corresponding code has been completely removed and therefore >>> matlab-emacs could be in ELPA. Eli gave me his ok. (And RMS a >>> while ago, if all legal requirements would be satisfied, of course). > >> Hi, > >> that's great news! > >>> 2) Can someone please provide me with some information or a link how >>> to proceed? I have to say that we, the authors, are now cleaning >>> up a bit the repository, rebase, delete obselete branches etc, >>> before including the package in ELPA. > >> The ELPA README is the place to start from >> > > Thanks for this pointer. I had a first glance, it reminds me very much > on the xemacs package system (but that used mercurial not git😉). > > I have to read it in more details, but so far, I have two questions. > > 1. The name of the branches is fixed, that is the principal branch > has to be called main (and couldn't be called say default?) Packages usually don't have to deal with that, all the ELPA build system needs is a git repository URL, and that is usually enough to figure out the rest. If it uses some unconventional branch name that is not default, we just need to note that in the package specification. > 2. Matlab is right now in MELPA and it seems much simpler to add a > package to MELPA than to ELPA. Is one of the reasons, the github > interface MELPA uses, but ELPA is bound to savannah that does not > provide something similar? So this is the host: https://sourceforge.net/projects/matlab-emacs/? IIRC MELPA forces contributors to write their own package specifications, right? Some people do that for ELPA, but it is not expected (I usually find it easier to update elpa.git myself). In this case, the basic specification is just: