This sort of thing is very important. One of the (many) issues that hinders open source projects is that it is difficult to jump into the code, even for experienced developers. Every project can benefit by making contributing easy and building as quick and painless as possible.
I still remember a couple years ago I wanted to contribute to Chromium. I took one look at the build instructions and decided I didn't want to contribute that badly...
Jesus Christ, (and I say that as a Buddhist) thanks for that rabbit hole. Thanks. I have spent 45 minutes so far on it, and it just keeps getting deeper. If I had enough karma I would downvote you for effectivly killing my evening, but as I don't I upvoted you instead in the hope that you will read my message and think twice in the future about posting such a fascinating, interesting time sink that will kill people's productivity. Cheers
ESR's post provides a link to a long but worthwhile article by Jelmer Vernooij on the history of Bazaar and why it lost to Git.
The key paragraph:
We lost sight of what mattered for our users, focusing on features that were nice but perhaps not as necessary as we thought. We overengineered. We didn't get rid of the crufty unnecessary features. It's harder to comprehend, contribute to or fix performance issues in a large layered codebase. And the larger a codebase becomes, the larger the surface for bugs, the harder it is to refactor.
Eric also lent considerable aid and the use of his reposurgeon tool to doing the actual migration. Despite his storied rivalry with Stallman, the two actually worked together over the past 10 months to get this shit done.
Is this :
"
It impedes people stuck on old (low spec) computers, too. For example,
in my adventures w/ git-bzr, i have managed to do the initial clone, but
512M RAM is not enough to achieve the tantalizingly compact footprint
that "git gc --aggressive" purports. I'm a stubborn fool and will find
a way eventually (suggestions from git-bzr / git experts welcome!), but
it's an unqualified slog that i imagine is just not worth the trouble
for others in similar straits."
just ideology? I would have expected most individuals in position to be doing development work in 2014 to have a little more ram than this.
Development work in the richer countries, yes. In the not so rich countries 1G is still quite normal and a program that's conservative (if using 512M can be called conservative in this case) with RAM is to be appreciated at all times, even when you have lots of it.
Well, it would be, if it were true. I'm pretty sure Emacs was invented after 1928. Half a century later, actually. I found that claim really odd. Maybe there's a joke or reference in there I'm not getting?
It's simply a joke about Emacs having a long history. Don't take it too seriously. Just like the "greatest thing since sliced bread" phrase. I mean sliced bread is not great at all.
I rarely buy sliced bread. But then again I usually buy real bread and not that "toast"-thing, which seems to be mislabelled as "bread" in the anglosphere.
I can't believe you've not met a bread elitist before. Any European who isn't British or Irish would probably count...
My housemates (in London) are from Palestine, Poland, Romania and Hungary, and in average British terms all count as bread elitists. None can understand why the squashy, tasteless, white bread is popular here, and struggle to understand why people would buy crap bread, of all things!
A chinese person recently asked me: "In America, does the bread usually contain other things, or is it just bread?"
To understand the question, you need to know that if you buy a bread product in a Chinese bakery, there will be some sort of filling -- beans, a hot dog, anything -- hidden in the middle (well, a hot dog will usually stick out visibly on either side).
When I replied that bread is bread all the way through, there was a followup question: "If it's all just bread, how can one bread be different from another bread?"
It was hard to know how to respond. Different breads taste different. Some are high-quality, some are low. People aren't just imagining the difference between sourdough and wonderbread.
I grew up worshiping the Wonderbread kids, now I cringe in horror. There really is no comparison between real bread and the other stuff. It's kind of like Velveeta.
A lot of my relatives live oversees and most of them, every time they come home, buy a lot of bread, take it back to another country and store in a freezer. Because it's nearly impossible to find a good, tasty bread in most western countries (from my personal experience: UK, Denmark, Norway; but I've heard the problem is much wider).
Especially bread. It's a staple food in many cultures. It's an important item. Why should we not demand high quality? Where I'm from people eat good bread. I grew up with good bread. It is really interesting but also sad, that the anglosphere seems to lack a decent bread culture.
I had a patch to emacs accepted about a year ago and I just used the previous git mirror for everything.
esr's apparent attempts to get everybody to move to git are a little quixotic, I have to say - but if it happens, it's probably a good thing. Where a DVCS is a good fit, then you might as well use git. But even while I support this move and assume workflow will be improved for emacs regulars, I wonder whether it will prove so valuable for occasional contributors. (N.B., I'm English, so I guess what I mean is: I don't believe that this will make much difference.)
I've now seen a couple of attempts to frame this change that way and I'm not sure I buy it.
If you read the email by ESR [1] explaining the rationale, I really think that he is right. It's not that bzr isn't good enough to keep on going, it's about the image exposed by Emacs as a project that still uses bzr.
And he does have a point. I for one do not look kindly on projects that still use Google Code or SourceForge for hosting or other version control systems other than Git or at least Mercurial. And this is because I look out for projects that aren't well maintained - after all, the noise amongst open-source stuff is incredible and I take notice of things such as when the last release or last commit was, current issues, mailing list activity and yes, the tools used.
That said, it's a pity that Emacs isn't being hosted on GitHub or BitBucket, because if these services are good at something, that's quick browsing of recent activity, plus they provide pull requests.
GitHub and BitBucket are proprietary web applications. This makes them unfit for hosting Emacs.
Also, the pull request system is not very good, IMO. It encourages bad practices like having to use git push --force to submit a new patch set without opening a brand new pull request (I suppose you could delete the remote branch and recreate it each time). And then there's the merge commit that it adds if you merge via Github, rather than rebasing to master and doing a fast-forward for a clean history. As ugly as it is, I much prefer submitting a patch set to a mailing list.
I wouldn't be too quick to judge a project by the version control system. OpenBSD, OpenSSH, LibreSSL, OpenSMTPD, and a few other affiliated projects all use CVS.
But anyway: bzr has simply become a barrier. Not only to attract new developers but also some long term contributors have ceased contributions because they considered bzr to be too much of a hassle. But it's not only that git has simply become the vcs everybody knows. Bazaar development has stopped and it's in "maintenance mode", which sadly means that some bugs aren't getting fixed. Switching to git therefore made sense from several perspectives.
Yes, bzr is a DVCS. And when a DVCS is a good fit, you might as well use git! Which is what they're doing. My point wasn't that switching to git isn't a good idea, just that my guess would be that out of all the reasons why people might not contribute to emacs development the VCS in use is not a huge factor.
But, I myself used the git mirror rather than bother with bzr. And this certainly is giving emacs some publicity, which (as I understand it) is always a good thing. And if it's being spun as some kind of a push to be friendlier to new developers, mabye the whole exercise will indeed prove more significant than I expect?
Anyway, fortunately we are now in a position to test my theory, one way or the other ;)
That's the official Vim repository, yes. There are a lot of contributors to Vim, but for consistency with the way Vim patches were handled before it had an SCM, changes are sent as diffs to the mailing-list and manually committed by Bram, rather than just being slurped into the repository with the original author information intact.
I still remember a couple years ago I wanted to contribute to Chromium. I took one look at the build instructions and decided I didn't want to contribute that badly...