Hacker News Reader

Comment by to3m | Hacker News Reader

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.

View on HN

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.

https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00...

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.

And on top of that, "github issues" are missing core functionality, such as attaching files.

When RMS allows Emacs development to be hosted on Github, Hell will freeze over and the Cubs will win the World Series.

It's a pity Github has become the central place for people to host free software while not being free itself.

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.

bzr is a DVCS.

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 ;)

> but also some long term contributors have ceased contributions because they considered bzr to be too much of a hassle

I wonder who those could be. I can't remember any major contributor leaving because of bzr.

E.g.,

* John Wiegley, author of eshell and other things. * The ada-mode was moved to GNU elpa because the maintainer didn't want to work with bzr.

Reply on news.ycombinator.com