Slashdot Mirror
Emacs Needs To Move To GitHub, Says ESR
hypnosec writes "Eric S. Raymond, co-founder of the Open Source Initiative, has recommended that Emacs should move to another version control system like GitHub, as bzr is dying. In an email, Raymond highlighted the key reasons why he believes that Emacs should move. Raymond said that bzr is moribund; its dev list has flatlined; and most of Canonical's in-house projects have already abandoned bzr and moved to GitHub. ESR believes that bzr's codebase is sufficiently mature to be used as a production tool, but he does mention that continuing to use the revision control system will have 'social and signaling effects damaging to Emacs's prospects.'"
Update: 01/06 20:50 GMT by U L : ESR did not suggest Github the proprietary hosting platform for git, but rather git the version control system. Which is actually already available on Savannah (the bazaar repository is automatically synced with the git repository).
ESR's original posting does not mention Github at all.
Never heard of it.
No need to move to a proprietary hosting service like Github.
I wrote about this previously: http://www.fsf.org/blogs/community/savannah
Join the Free Software Foundation
He wants to move emacs to git and not to Github. Journalists...
The original source (ESR himself) never mentioned GitHub. Just git. Can people stop conflating the two please?
I'm surprised that emacs didn't already have a version control system built into. It has everything else.
Cheers,
Dave
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
Github doesn't have the resources to host something that bloated.
Since VC wars are almost as much fun as language wars, and I've already donned my Nomex underwear, why not Mercurial? It isn't as popular as git, but it's not going to die either (e.g. Python project uses Hg). It seems that most people or organizations that have actually sat down and evaluated Hg vs. git have chosen Hg. Examples include Google's online repository and Fog Creek's Kiln. Both now also support git, but that's because of demand by users. Of course user demand is, at least from a marketing PoV, important, but why the user demand for git over Hg? Both have technical pros and cons (and fortunately for both the dev teams compete with each other), but Hg has always had a much better command line user interface, better GUI integration, and was well designed from the ground up to be portable, as opposed to a pile of shell scripts and C programs to run on Linux. Arguably git's use on the Linux kernel is a factor, but why? For all its visibility and importance, the Linux kernel is but one FOSS project, and the vast majority of FOSS devs don't work on it.
Now for the statement that some will see as flamebait :-) but which is a sincere observation. I think the difference is the fanboi factor; people who think that git is the choice because it's from Linus, the ultimate cool kid. No, I don't think everyone who uses git does so because they're a fanboi. I suspect the main reason is going with that flow, but it's the fanbois who originally pushed that flow so hard. As your mother used to say, if all your friends decided to jump off a cliff, would you jump too? Vociferous debate welcome.
Sincerely,
Don Quixote
Why make a contentious choice between bzr and git when we could implement a new, metalevel distributed revision control system that supports revision control across multiple revision control systems, each potentially running on multiple nodes?
Given sufficient time, I'm sure we can generalize away any petty disagreements!
Apparently Eric has decided he has been out of the public eye too long, as he posts yet another self-aggrandizing screed on a mailing list.
Seriously, after the kernel configuration debacle and his hysterical rants on the Fedora list, does anyone take this man seriously anymore? Look at how he represents himself: an expert on source control systems, whose highest achievement is moving troff to a git repo. It's kconfig all over again.
"I know I will be modded down for this": where's the option '-1, Asking for it'?
Actually, is the dying one being Emacs, instead? That would be sad - but I wonder how younger generations do appreciate Emacs which is quite tricky to get used to - while so convenient and still unequaled in 2014 when it comes to some features (hyper customization thanks to (e)Lisp, M-x features with completion, intra-shell/processes, apropos, ^x-( ), languages modes ...). It seems the major IDE or text editors did not even try to reproduce the main features of Emacs - do they ignore the Emacs logic because they have no knowledge of it, or do they simply feel those features are obsolete? For once, nobody reinvents the wheel, which is going to die eventually. Sad, really.
Slashdot, fix the reply notifications... You won't get away with it...
A heretic uses XEmacs. An apostate doesn't take the time to install Emacs where it is not available, instead using vi. A blasphemer suggests that emacs and vi are essentially interchangeable, denying emacs' uniqueness and primacy. All three prefer emacs; only pagans and barbarians prefer something else.
Is there still any prospect at all? I left 5 years ago because they stopped improving anything for a decade.
A decade ago it was comparably decent IDE for Java and C++, today it's nothing thanks to incomplete project management UI, incomplete file tab support, and over-reliance on ctags which can't really understand syntax and parse things properly, and their inability to work on on-the-fly static code-analysis, which requires basic threading support that (still) isn't done.
the same could be said for Vim as well. While both remain very efficient text editors, they no longer matter because it's far more important to study and write correct code than to writing code faster, and other IDEs have improved on such parts drastically these years.
But, while ESR is likely right, my kneejerk response is to say, "No!" Why? Because ESR is such a freaking windbag, who's so damn convinced of his own moral and intellectual superiority. His whole schtick gets really tiresome after a while.
$.02.
> I wonder how younger generations do appreciate Emacs
Someone said that to me in 2002. I was a new Emacs user then, and I'm still using it now.
Debian's package install stats suggest the Emacs user base is steadily growing:
http://qa.debian.org/popcon-graph.php?packages=emacsen-common
And the developer mailing list is very active and high-quality:
https://lists.gnu.org/archive/html/emacs-devel/
However, Hip-Hop's future is looking less certain:
http://www.theonion.com/video/there-are-people-in-world-who-are-concerned-about,32163/
Expert in software patents or patent law? Contribute to the ESP wiki!
Why should it innovate? Emacs is roughly as good at being Emacs as it is likely ever be.
I became disenchanted with Gnome and KDE, not because they did new things, but because they couldn't do those new things without undermining what I liked about them. As for emacs, the world may have passed it by, but it probably has more users today than when I first learned it in the 1980s. That's healthy enough for an ongoing project. It doesn't have to, say, beat Eclipse at being an IDE, emacs has to meet the needs of its users. The fact that other, somewhat different projects are successful doesn't make Emacs a failure.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Emacs will settle on git, vim has settled on mercurial. Oh, how delicious!
Like many things, Emacs doesn't have version control as much as it interfaces or wraps it. You know, dired wraps /bin/ls (and mv and rm), compile wraps e.g. /usr/bin/make, tramp wraps ftp and grep wraps .. um .. grep. And vc wraps version control:
Emacs is the glue that binds together all the little tools into a more powerful whole. And not just Unix tools, e.g. I wrote a function (3 lines of elisp) that launches Windows Explorer with the current file pre-selected. On a Mac the same key combo launches Finder. You seriously underestimate Emacs by calling it a mere OS...
By the way, I don't use vc.el myself. Never have. Nor do I use Emacs to read mail. Unlike other editors of more monolithic design, you don't pay for what you don't use.
Two complaints, one non-complaint
Complaint #1: ESR's reasoning, and the only theoretically justifiable one in the entire blog post, is that bzr is slow. All version control systems are slow. The more you keep the modification history around, the more people you have hitting a single repo, the slower they get.
When Apple moved from CVS to SVN, it was because of two things: The first was Linux-based Apple RAID boxes that Apple was OEM'ing from a third part had some bug where they lost data, and this messed up some of the CVS backing files. With a single backing file, as in SVN, this situation only improved because the switch came around the time the bugs in AppleRAID had already been resolved; otherwise, it would have been the whole repo, not just a couple of files, getting screwed up. The second one was that the CVS repo was slow. This was pixable by sharding it so different projects used repos on different servers. The new SVN server on the other hand, was lightening fast ... until we moved over the entire modification history from the CVS server to the SVN server, and all the CVS users stopped hitting the CVS server, and started hitting the SVN server instead. Then the SVN server was just as slow as the CVS server had been, and we were back to the status quo.
The lesson you should take from this is that it doesn't matter your version control system is slow, because they *ALL* are, and so it doesn't make a difference what VCS you end up using, as long as the primary maintainer likes it.
Complaint #2: ESR claims that, because it's in bzr and not git, it's harder to submit patches to EMACS. This is patently false. The older an Open Source project is, the harder it is to submit patches, and you VCS doesn't matter to this, because the difficulty isn't the VCS, it's the politics of change.
As projects get older and older, there's kingdom building that happens, and it's nigh impossible to get a change in that's going to cross one or more boundaries between kingdoms. The more kingdoms you code changes go into, the more code it changes, the more impossible it is to get those changes in. One of the big deals here is the "I won't approve your patch until you rewrite it the way I would have written it if I'd done it, but since I don't have the time (except to review and complain, of course -- then I have buckets of time), I'm not going to take the patch". This is called "time to get a new king instead of an asshole" effect for short.
The lesson you should take from this is that it's not the VCS, it's the politics, and yeah, if you switch VCSs, you'll get a window when not everyone is up enough on the new stuff that they can get in your way, if you're working with smart people: they will be. So switching VCSs is typically a means of cutting through red tape that shouldn't be there in the first place, and it never works for long.
Non-complaint #1: ESR states that bzr is "old and crufty" and that "it's mailing lists are dying and patches are dwindling", and that this is somehow bad.
It's not bad: that's what happens with mature, purpose-built tools: once the damn things work well enough, unless you have someone pushing change for changes sake to get themselves into the commit log or README file, the changes dry up, and the tool tends not to change. So activity on a mailing list or in a commit log for a mature tool is not a way to value that tool.
Before anyone jumps on me for this posting please read this: I personally don't use bzr, so I have no skin in this game. I've used over a dozen different VCSs, and with the exception on one that ran on DOS, which I would never use again, they're all pretty much solving the same problem, and you shouldn't really give a damn about what a projects primary maintainer likes to use, as long as the thing does the job.