Hacker News Reader

Comment by gnuvince | Hacker News Reader

> Either all of the significant contributors to Magit must sign papers with the FSF (with code from the holdouts being replaced), or an entirely new Emacs interface to Git must be written.

False dichotomy: GNU Emacs can simply not ship with a git porcelain.

Most Emacs users I know typically have dozens of packages installed from MELPA; I don't think most users mind having to install an extra one. If an acceptable agreement regarding copyright assignment cannot be reached, I would really prefer that the status quo be maintained.

View on HN

It's not a false dichotomy. You're just working VERY hard at ignoring the context. The part you quoted comes right after the part that says "If we want to distribute something like Magit with Emacs".

If you don't think that's a worthwhile goal, that's fine, but there is no need to blatantly misinterpret the context of the discussion here.

Yeah, maybe Magit is also the killer app for the 'package' system as well.

Stallman said he didn't like having to tell users that they need to install a package in order to have the kind of functionality that Magit provides.

So? He's not the maintainer of the project. Anyway, that's clearly a non-scaleable solution. No software engineer would be attracted to this design, only someone with a fanatical obsession with GPL which blinds him to engineering considerations. The emacs core developers can't take on the burden of maintaining every bit of add-on functionality that is written throughout human history and seems useful enough to want to include in emacs. These things should have test suites; maintaining a discrete project like magit or org-mode is the job of the magit/org-mode developers, and should be isolated from the core Emacs code base, interacting via the API provided by Emacs core. One job of the core developers is to design and maintain that API.

I think you misunderstand the issue. The Emacs maintainers would not have to maintain Magit, and that's not what this is about. This is about distribution.

Note that the GNU ELPA is considered to be part of Emacs, whereas MELPA is not. MELPA may also contain unlicensed software or otherwise non-free software.

> MELPA may also contain unlicensed software or otherwise non-free software.

Some statistics on that: https://emacsmirror.net/stats/licenses.html.

I don't think I misunderstand the issue.

> The Emacs maintainers would not have to maintain Magit

That's not true. They would have to maintain it: deal with bug reports, deal with breakage due to upstream API changes in Emacs core. They wouldn't do feature development.

I used to contribute code to org-mode, so I know how this works. The magit team will make periodic releases, at which point the magit code will be copied over into the emacs code base. From that point on, the emacs maintainers are on the hook for any bugs or other problems occurring with the version of magit that they have included into Emacs. They'll have to deal with/triage magit bug reports received via the Emacs bug tracker.

> He's not the maintainer of the project

RMS' opinion is taken very seriously in emacs development community.

Why? Has he written any code lately?

Honest question, because from the outside he seems like an absolute grognard whose computing habits are so far removed from those of everyone else that he is incapable of relating to how the modern world does its computing.

Perhaps if he wants a good git interface in emacs, RMS should sling some code instead of giving the same entry-level ethics talk ad nauseam.

> Has he written any code lately?

Why would that even matter? I find this attitude very puzzling and extremely worrying.

Of all the arbitrary metrics to decide whether to listen to and consider somebody's position "lines of code written" seems like an exceptionally poor choice.

I find your comment to be a good example of what is wrong in circles that like to consider themselves part of hacker culture.

Well if he's not contributing to the project in any meaningful way, why is his opinion valued?

It's not a matter of lines of code, but of contribution at all.

What does RMS enable the emacs project to do that they couldn't do without him?

What does he bring to the table?

I'm not being rhetorical, I mean it: why do people care what he thinks?

It's not even a GPL/non-GPL issue. Magit is licensed under the GPLv3.

It's because the FSF doesn't have assignment of the copyright to the code and there's no signed contributor agreements. The insane part of this isn't wanting it to be FOSS (it is!!), it's insisting it to be a part of the core project.

Emacs already has front-ends to different version control systems. See the VC package.

> False dichotomy: GNU Emacs can simply not ship with a git porcelain.

False dichotomy: The FSF can drop their requirement for onereous copyright assignments and instead trust the GPL to do its job.

For a copyleft license to do its job you have to enforce it, otherwise it would be the same as a permissive license.

The FSF is not requiring copyright assignment. It is the choice of the GNU Emacs project that the GNU Emacs project requires them. The Emacs maintainers could change their minds about that, and FSF would be OK with that.

friendly reminder: the built-in vc-mode can interface with most version control systems, including git.

It's not as great as magit, but it works (and it has you to learn very little).

If the FSF wants Magit but can't bundle it because of their own policies (as Stefan Monnier so eloquently points out), that's a problem for the FSF to solve, not Magit.

I think this comment on the Lwn-article really highlights how bizarre this has all turned out:

> GNU began as a project to replace proprietary software with free one, and now lives on as a project to replace free software with free software.

I think that about sums it up. (And I say that as a passionate Emacs-user)

Apropos vc-mode comes with vc-annotate-mode (C-x C-v g) which is the best way to go through the history of the file

Reply on news.ycombinator.com