6 ms·

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 Goo

by ggreer 12y ago

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-google-code.html http://google-opensource.blogspot.com/2015/03/farewell-to-go... 2. https://groups.google.com/d/msg/vim_dev/ehzfCDccmek/PU1sTZNdsTUJ https://groups.google.com/d/msg/vim_dev/ehzfCDccmek/PU1sTZNd... 3. https://code.google.com/export-to-github/ https://code.google.com/export-to-github/

zzalpha 12y ago
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.
- guelo 12y ago
  Why would the source of the remote make a difference for fetching from an upstream?
  - mackwic 12y ago
    Technically, it doesn't. In practice, using a unified and polished interface like Github make things easier.
    - Crito 12y ago
      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?
  - samspot 12y ago
    Vim appears to be Mercurial while Neovim is Git. I imagine merging is a lot easier when you are on the same VCS :)
    - deleted 12y ago
      [deleted]
    - michaelmior 12y ago
      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/ https://hg-git.github.io/ [1] https://github.com/cosmin/git-hg https://github.com/cosmin/git-hg
    - sigzero 12y ago
      I don't think there is going to be a lot of merging behind done so it probably doesn't matter.
mempko 12y ago
It it true that patches are dropped or forgotten? Or is this a personal opinion?
- brunosutic 12y ago
  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.
  - reidrac 12y ago
    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.
    - brandonwamboldt 12y ago
      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.
      - jessaustin 12y ago
        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.

by ggreer 12y ago

zzalpha 12y ago

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.

guelo 12y ago
Why would the source of the remote make a difference for fetching from an upstream?
- mackwic 12y ago
  Technically, it doesn't. In practice, using a unified and polished interface like Github make things easier.
  - Crito 12y ago
    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?
- samspot 12y ago
  Vim appears to be Mercurial while Neovim is Git. I imagine merging is a lot easier when you are on the same VCS :)
  - deleted 12y ago
    [deleted]
  - michaelmior 12y ago
    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/ https://hg-git.github.io/ [1] https://github.com/cosmin/git-hg https://github.com/cosmin/git-hg
  - sigzero 12y ago
    I don't think there is going to be a lot of merging behind done so it probably doesn't matter.

mempko 12y ago

It it true that patches are dropped or forgotten? Or is this a personal opinion?

brunosutic 12y ago
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.
- reidrac 12y ago
  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.
  - brandonwamboldt 12y ago
    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.
    - jessaustin 12y ago
      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.