Hacker News Reader

Comment by tarsius | Hacker News Reader

> If it were part of Emacs you'd need to use the FSF's collaboration tools which have a higher barrier of entry,

No, we would continue to use Github for the foreseeable future. If a FSF hosted Gitlab/Gitea/... instance came to be, then we would likely switch to that.

Also I am not exactly a fan of either the git forge or the mailing list work-flow. So I plan to add "competitive collaboration tools" to Magit that allow a project to continue to use either back-end while also allowing all or some contributors to use collaboration work-flows that are more tightly integrated with the development and version-control work-flows. https://github.com/magit/magit/issues/2972

The primary downsides of assigning copyright to the FSF that I see is the "waiting for papers to be signed" part and that some potential contributors will no longer be able to / be willing to contribute.

View on HN

Other than getting papers from contributors, are there ways in which Magit becoming part of Emacs would significantly change the development workflow?

I would probably get drawn into more lengthy discussions.

It's important to note that when Richard said that Magit should be "part of Emacs", that really meant "part of GNU Elpa and/or GNU Emacs". If Magit is just made part of Elpa (which I believe is all that Richard wants), then that doesn't change much. We get protection at the cost of the assignment overhead.

But I already wanted to add parts of Magit to Emacs itself anyway. Low-level libraries that are useful beyond Magit itself, and which would benefit from being built-in. That includes some existing ui libraries but also new libraries I intend to write to replace old abstractions used in Magit, such as a file-handler for Git blobs and trees. Magit would benefit if other Git related packages used those, instead of everyone reinventing the wheel.

Once some code is part of Emacs itself it will be more difficult to change than if it were living in a separate repository. On the bright side, that would likely motivate me to write tools to make that process less painful.

>No, we would continue to use Github for the foreseeable future.

The FSF does not consider Github to be a suitable VCS host for its projects. Gitlab has, to my memory, a rating of "good enough", but only Savannah (which the FSF hosts instances of) is truly thought of as excellent, and it's what's used for all the current projects under their control.

If Magit were to become a FSF project, it would be made to migrate.

The user you're responding to is the maintainer of Magit - I would wager he has a better idea of his hosting situation than you do.

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.

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

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/packag...

> Can you show me an example of such a package?

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.

> 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...

That doesn't seem that onerous. It's just a pull and and a merge—it's what git is designed for.

Orgmode is another example.

Reply on news.ycombinator.com