News for hackers. Stuff that matters.

A comment on Vim is moving to GitHub.

Re:Vim is moving to GitHub by ggreer on Wednesday March 25, 2015 @11:14AM (#9263469)
Google Code is shutting down this year[1], so the Vim-dev mailing list discussed migration[2]. GitHub is the most popular host for open source projects, and Google Code has an export tool for it[3], so the switch makes a lot of sense.

That said, Vim's development method is rather conservative. Vim was created in 1988, but source control wasn't used until 2004 and Bram is the only one with write access. There are no pull requests. You have to send patches to the mailing list, where they are often dropped or forgotten. Hopefully, GitHub's features will modernize things a little and make it easier for more people to contribute to Vim.

1. http://google-opensource.blogspot.com/2015/03/farewell-to-go...

2. https://groups.google.com/d/msg/vim_dev/ehzfCDccmek/PU1sTZNd...

3. https://code.google.com/export-to-github/

[ Parent | on HN ]
Re:Vim is moving to GitHub by zzalpha on Wednesday March 25, 2015 @11:23AM (#9263520)
At minimum, it makes it a lot easier for a viable fork to pop up if necessary. For example, I'll bet it'll make it simpler for neovim to keep up-to-date with changes in the upstream.
[ Parent | on HN ]
Re:Vim is moving to GitHub by guelo on Wednesday March 25, 2015 @11:53AM (#9263729)
Why would the source of the remote make a difference for fetching from an upstream?
[ Parent | on HN ]
Re:Vim is moving to GitHub by mackwic on Wednesday March 25, 2015 @12:05PM (#9263819)
Technically, it doesn't. In practice, using a unified and polished interface like Github make things easier.
[ Parent | on HN ]
Re:Vim is moving to GitHub by Crito on Wednesday March 25, 2015 @02:21PM (#9264881)
I feel like actually creating a fork of vim that is viable for the community is a much higher bar. If that first bar stops somebody, is it likely that they would have cleared the second bar?
[ Parent | on HN ]
Re:Vim is moving to GitHub by samspot on Wednesday March 25, 2015 @12:07PM (#9263831)
Vim appears to be Mercurial while Neovim is Git. I imagine merging is a lot easier when you are on the same VCS :)
[ Parent | on HN ]
Re:Vim is moving to GitHub by michaelmior on Wednesday March 25, 2015 @02:54PM (#9265114)
You can use hg-git[0] to push to Git from a Mercurial repository. Then it's basically just like working with another Git repository. It does mean that you need some way of mirroring the two. I've never tried it, but it looks like you can use git-hg[1] to use a Mercurial repository like a regular Git remote.

[0] https://hg-git.github.io/ [1] https://github.com/cosmin/git-hg

[ Parent | on HN ]
Re:Vim is moving to GitHub by sigzero on Thursday March 26, 2015 @09:25AM (#9269341)
I don't think there is going to be a lot of merging behind done so it probably doesn't matter.
[ Parent | on HN ]
Re:Vim is moving to GitHub by mempko on Wednesday March 25, 2015 @11:37AM (#9263624)
It it true that patches are dropped or forgotten? Or is this a personal opinion?
[ Parent | on HN ]
Re:Vim is moving to GitHub by ggreer on Wednesday March 25, 2015 @11:51AM (#9263712)
It's true if you're not one of the regular contributors. Even small patches for things like syntax highlighting seem to languish[1][2]. For stuff that requires feedback from Bram, sometimes there's just no response[3].

Sometimes it just takes a bunch of prodding from multiple users to get a patch merged[4]. Sometimes even that isn't effective[5].

I didn't have to look hard to find these examples. I just scrolled through vim-dev looking for "patch" next to an unfamiliar name. This is a common problem with mailing lists: old things fade into oblivion whether or not they've been dealt with. Not so with GitHub's pull requests. PRs stick around until someone closes or merges them. That one difference makes it much harder for contributions to slip through the cracks.

1. https://groups.google.com/d/msg/vim_dev/iB2YYel67io/SBHYHpSM...

2. https://groups.google.com/d/msg/vim_dev/UTOY6V6UCkk/-0lqupnc...

3. https://groups.google.com/d/msg/vim_dev/0It1ZTos_QY/63Xc9NrT...

4. https://groups.google.com/d/msg/vim_dev/WeBBjkXE8H8/MRLPPMjV...

5. https://groups.google.com/d/msg/vim_dev/kG3Qaz8M9kw/YyZDzwkc...

[ Parent | on HN ]
Re:Vim is moving to GitHub by mempko on Wednesday March 25, 2015 @03:04PM (#9265190) 

  2. Bram responds the next day. The submitter responds to Bram a week later... 
  3. Bram responds the next day.
  4. Patch was merged after 4 months.
  5. Bram responds same day after patch is added to mailing list.
Looks like the response times are great!

Also it looks like a patch that is merged is put on the mailing list at the root and not as a reply to peoples messages.

So it is hard to tell how long someone submits something and when a patch is merged by looking at responses. You would have to find a patch someone submitted, then find Brams "Patch" messages to find when it was merged and compute time difference

[ Parent | on HN ]
Re:Vim is moving to GitHub by ggreer on Wednesday March 25, 2015 @03:35PM (#9265373)
1. Never merged. No replies.

2. Never merged, though a similar patch by the same person was merged a couple of weeks later. Try, try, again.

3. Never merged. Waiting on Bram.

4. Merged after 6 months, only because users constantly pestered. This patch was 12 lines, all straightforward.

5. Never merged. Bram said it was on his to-merge list in 2013.

All of these patches are pretty small. It shouldn't take long to reply with "Yes", "No", or "fix this". Yet the response is often one reply, followed by crickets. As 2 and 5 show, even the "yes" patches can fall through the cracks.

Bram's initial response can be quick, but it's often an ordeal to actually get a patch merged, even for trivial ones. This is likely due to a combination of Bram being a very busy person and mailing lists being terrible for this sort of thing.

[ Parent | on HN ]
Re:Vim is moving to GitHub by chrisbra80 on Wednesday March 25, 2015 @05:09PM (#9265929)
1) Here the real problem is the maintainer of the syntax file who is hard to reach. I have contacted him several times but never got fa reply. No real problem of Vim. 2) merged February 25th. Not bad I would say (again a runtime file problem) 3) merged with 7.4.646 4) yes, sometimes it takes a while. 5) took long but has been merged with 7.4.652
[ Parent | on HN ]
Re:Vim is moving to GitHub by mempko on Wednesday March 25, 2015 @04:40PM (#9265777)
I'm confused though. I don't ever see a response from Bram saying "merged this". Instead you see a constant stream of patches merged at the root of the mailing list.

So I don't think you can look for his response in the mailing list for a submission if it was merged or not. You have to look at the stream of merged patches.

[ Parent | on HN ]
Re:Vim is moving to GitHub by arcticfox on Wednesday March 25, 2015 @12:00PM (#9263774)
My goodness. I'm shocked anyone is motivated enough to even get stuff through that process.
[ Parent | on HN ]
Re:Vim is moving to GitHub by iterati on Wednesday March 25, 2015 @12:52PM (#9264185)
Which is why neovim exists now.
[ Parent | on HN ]
Re:Vim is moving to GitHub by sfk on Thursday March 26, 2015 @08:09AM (#9268954)
Which practically no one actually uses.
[ Parent | on HN ]
Re:Vim is moving to GitHub by sfk on Friday March 27, 2015 @07:00AM (#9275549)
I truly wonder what kind of idiot downvotes this. Pure propaganda.
[ Parent | on HN ]
Re:Vim is moving to GitHub by sfk on Friday March 27, 2015 @07:03AM (#9275558)
And the new comment was downvoted within seconds. The stakes seem to be high in this thread...
[ Parent | on HN ]
Re:Vim is moving to GitHub by DanBC on Friday March 27, 2015 @07:06AM (#9275567)
Complaints about downvotes will always get downvotes.
[ Parent | on HN ]
Re:Vim is moving to GitHub by sfk on Friday March 27, 2015 @07:09AM (#9275577)
In realtime?
[ Parent | on HN ]
Re:Vim is moving to GitHub by sfk on Friday March 27, 2015 @07:07AM (#9275572)
And the kind of hipsters who use neovim apparently have unlimited time for guarding threads and realtime downvoting.
[ Parent | on HN ]
Re:Vim is moving to GitHub by jhallenworld on Wednesday March 25, 2015 @05:21PM (#9266013)
I don't think Bram gets paid to maintain VIM, so you get what you get. Not to say that it did not take work to produce a patch, but it's also a lot of work to review and merge them.

What the hosting site could do is provide a way for users to build a customized image with selected contributed patches. This would allow the patches to be used without having to add more work to the primary developer.

[ Parent | on HN ]
Re:Vim is moving to GitHub by sigzero on Wednesday March 25, 2015 @06:49PM (#9266569)
He could broaden the team a bit with his vote overruling if needs be. That would certainly help.
[ Parent | on HN ]
Re:Vim is moving to GitHub by brunosutic on Wednesday March 25, 2015 @11:40AM (#9263641)
It's true.. a lot of the patches are forgotten unless the submitter periodically "pings" Bram (the maintianer) about it.

The vim development model (patches + mailing list) has been pretty frustrating for some people. That's one of the reasons why NeoVim was forked.

[ Parent | on HN ]
Re:Vim is moving to GitHub by reidrac on Wednesday March 25, 2015 @11:43AM (#9263663)
Is it frustrating because of the patches + mailing list or because the maintainer ignores them?

Because pull requests can be ignored as well, although it is true that they're more visible than a mail in a mailing list archive.

[ Parent | on HN ]
Re:Vim is moving to GitHub by brandonwamboldt on Wednesday March 25, 2015 @12:11PM (#9263881)
Both IMO. Patches + mailing list isn't an ideal medium for code changes, and it's not as easy to quickly browse a list of patches that haven't been merged yet.

GitHub lets you update patches easily (and see the updated patch), drop comments inline in a patch (very useful for code review), and tag patches (extremely useful for large projects).

Having to go through the extra hassle of a mailing list just to have the maintainer ignore them sucks.

Another benefit of GitHub is that users affected by an issue that has been patched but not merged can just fork the repo and merge the PR themselves and use that (I've done that in multiple cases). Mailing lists aren't as easy for this.

[ Parent | on HN ]
Re:Vim is moving to GitHub by jessaustin on Wednesday March 25, 2015 @12:53PM (#9264191)
Patches + mailing list isn't an ideal medium for code changes, and it's not as easy to quickly browse a list of patches that haven't been merged yet.

This is true, which I discovered while attempting to contribute to git itself. git's development uses this model, which probably means something, even if I can't figure it out.

[ Parent | on HN ]