4 ms·

That's a statement on the level of Turnbull's "laws of Australia". I doubt the FSF would break its own policy for a new project, especially since the principle

That's a statement on the level of Turnbull's "laws of Australia". I doubt the FSF would break its own policy for a new project, especially since the principle is free software over user convenience. The maintainer might want to add proprietary dependencies to their project, but under FSF control, it wouldn't happen.

tarsius 9y ago
Most of the packages that are distributed using GNU Elpa (i.e. the non-built-in packages under FSF control) are developed on Github.
- ivanbakel 9y ago
  Can you show me an example of such a package? All the Elpa packages are hosted on a Savannah instance. https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/packages https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/packag...
  - tarsius 9y ago
    > Can you show me an example of such a package? https://github.com/magnars/dash.el https://github.com/magnars/dash.el > All the Elpa packages are hosted on a Savannah instance. That's the "publishing repository". You have to push there for a new version of your package to be published on GNU Elpa. But for most packages development happens elsewhere, and in most cases "elsewhere" is Github. Emacs maintainers sometimes commit directly in the Elpa repository (and package maintainers are expected to deal with the consequences, such as "two diverging mainlines"), but development happens elsewhere.
    - mnarayan01 9y ago
      > Emacs maintainers sometimes commit directly in the Elpa repository (and package maintainers are expected to deal with the consequences, such as "two diverging mainlines") Is a model like this what you mean when you say "No, we would continue to use Github for the foreseeable future"? I guess if you're doing all the legwork, it won't be overly visible to other people who want to contribute. Still though...
      - __david__ 9y ago
        That doesn't seem that onerous. It's just a pull and and a merge—it's what git is designed for.
  - BeetleB 9y ago
    Orgmode is another example.

tarsius 9y ago

Most of the packages that are distributed using GNU Elpa (i.e. the non-built-in packages under FSF control) are developed on Github.

ivanbakel 9y ago
Can you show me an example of such a package? All the Elpa packages are hosted on a Savannah instance. https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/packages https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/packag...
- tarsius 9y ago
  > Can you show me an example of such a package? https://github.com/magnars/dash.el https://github.com/magnars/dash.el > All the Elpa packages are hosted on a Savannah instance. That's the "publishing repository". You have to push there for a new version of your package to be published on GNU Elpa. But for most packages development happens elsewhere, and in most cases "elsewhere" is Github. Emacs maintainers sometimes commit directly in the Elpa repository (and package maintainers are expected to deal with the consequences, such as "two diverging mainlines"), but development happens elsewhere.
  - mnarayan01 9y ago
    > Emacs maintainers sometimes commit directly in the Elpa repository (and package maintainers are expected to deal with the consequences, such as "two diverging mainlines") Is a model like this what you mean when you say "No, we would continue to use Github for the foreseeable future"? I guess if you're doing all the legwork, it won't be overly visible to other people who want to contribute. Still though...
    - __david__ 9y ago
      That doesn't seem that onerous. It's just a pull and and a merge—it's what git is designed for.
- BeetleB 9y ago
  Orgmode is another example.