Vim is moving to GitHub
github.com
github.com
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...
[0] https://hg-git.github.io/ [1] https://github.com/cosmin/git-hg
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...
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.
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
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.
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.
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.
The vim development model (patches + mailing list) has been pretty frustrating for some people. That's one of the reasons why NeoVim was forked.
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.
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.
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.
For example, you could enter a "bold formatting" mode, where you could say type "fun" and it results in "๐๐ฎ๐ง". All these are Unicode characters, so you wouldn't need a separate document format like Word.
Presumably one can have a "math" mode where you could type math like you would type regular text obviating the dollar signs and backslashes in LaTeX.
As I understand it, LaTeX has an incredibly complicated architecture with multiple layers of macros before the lowest layer of TeX primitives. You could replace all that with Unicode symbols.
In math mode you could type "in" and get the Unicode symbol "โ". Then you would be able to copy-paste math and send it over email, instant messaging et cetera, and easily type it with a WYSIWYG editor using a traditional keyboard. Of course, there would be numerous problems with typesetting integration limits, fractions et cetera but I think these can be solved using Unicode and clever programming.
I currently do not solve say Group Theory problems on my computer because LaTeX is way too inconvenient.
I think on a hypothetical editor with a math "mode", one could touch-type math. Maybe I'm missing something and there are insurmountable obstacles to implementing such a solution. If so, I would be happy if someone could point out what they are.
Having different modes seems like a very powerful feature, and I'm just surprised the last editor using modes was written 40 years ago.
That said, it's really awful at copy-pasting into other programs my experience. But it does a decent job of exporting explicitly, like for instance with TeXForm.
Also, a slightly different thing you can do in Vim is to use the conceal feature to visually "collapse" LaTeX escapes into their unicode characters. For example, the document says "\lambda", but it will display as ฮป (unless you position the cursor on the same line, so that you can edit it). I find it helps reduce visual clutter a bit.
First, when using other commands one should be able to input in bold as well. For instance, while searching. Otherwise, one wouldn't be able to search for the bold version since it is encoded differently.
Second, search and other commands should be aware that "f" and "๐" represent the same letter. Otherwise, each search becomes a game of trying all the styles to see what gets results.
Third, and this is a matter of taste, I prefer to keep the presentation separated from the structure as much as possible. I much rather write \myStyle{fun} and keep writing. Later, when the writing part is done, I can define \myStyle as bold or whatever makes sense.
...as long as GitHub doesn't become an evil empire of some sort.
Github without distributed commits isn't based on git anymore, and the other stuff is ancillary (and also easily exportable)
designed to discourage GPL use
What the hell are you on about? From choosealicense:
The GPL (V2 or V3) is a copyleft license that requires anyone who distributes your code or a derivative work to make the source available under the same terms. V3 is similar to V2, but further restricts use in hardware that forbids software alterations.
Linux, Git, and WordPress use the GPL.
This is in the middle of the front page [1]. What is discouraging or inaccurate about this?
Furthermore, the license chooser under the new repo page has the GPL as the second friggin' option [2].
Acerbic? Yes, but I don't appreciate people peddling lies.
First of all, it says that the main default simplest license should be the permissive one. It chooses that first on purpose. Second, they say that you should use Apache if you care about patent issues when actually GPLv3 is arguably superior for that. So, they worked to actively relegate GPL to the last choice.
And you picked out the small text. The big text is "I care about sharing improvements" โ what does that mean? It's much more wishy-washy than "I want to block the code from being used in proprietary projects" or "I want to require that derivatives stay free". The motivation behind the GPL is about freedom, not about improvements. But GitHub doesn't want to talk about freedom, they only want to talk about code improvements.
Anyway, it's already aggressive to encourage people to use GPLv2 instead of GPLv3, given that v3 specifically closes loopholes that GPLv2 has.
Anyway, it's not a lieโฆ watch https://www.youtube.com/watch?v=-bAAlPXB2-c to hear the GitHub co-founder explicitly tell people to reject the GPL in the very presentation in which he announced the choosealicense site.
How about: "The GPL (V2 or V3) requires anyone who distributes your code - or a derivative work - to make the source available. V3 is similar to V2, but it also demands that, whenever the code comes "pre-installed" in a device, the user can run a modified version in the device"
Or even: "The GPL (V2 or V3) requires anyone who distributes your code - or a derivative work - to make the source available. V3 is similar to V2. Only worry about the difference for code that comes "pre-installed" in a device"
The GPL is objectively a more restrictive license than BSD/MIT/Apache - just because you think the word "restricted" is ugly doesn't change this rather uncontroversial fact.
Furthermore, the FSF are precisely the last people I'd go to for a forthright and non judgmental description of the GPL and its purpose. The FSF is at least a primary source in this matter, and furthermore an advocacy group.
So lets change the "I want it simple and permissive" text to "I want attribution. The MIT License only requirements is that users provide attribution back to you and donโt hold you liable."
Its a forthright and non judgmental description of the MIT license and its purpose, and it matches perfectly with the style of the GPL description.
(and yes. If you dont know if you want MIT or GPL, "dont worry about" V2 vs V3)
The "purpose of those restrictions" is the whole and entire point of the GPL. If you don't explain (to users or developers) why the GPL restricts distribution of code and future changes the way it does, well, you might as well just not mention it at all.
You are omitting what is probably the most important part of the GPL.
I disagree that it is an important thing about what is its intent
If I'm choosing a license for a project, it's important that I know that changes other people make will be available to me under the same terms as my own code.
A license that requires you to make the changes available but allows you to restrict my use of those changes is plainly in contrast with the intent of the GPL.
better ?
(sure, there is a tradeoff between comprehensibility and precision ...)
I don't think issues and PRs, along with all the comments on them, are ancillary.
Github does make it easy to export that data, but then it's not necessarily easy to bring it in somewhere else and keep using it. That's not Github's fault, but there is definitely a degree of lock in.
I'm pretty sure there is a tool to transfer a GitHub repo and all meta data to GitLab (which is open source).
That's a good point, but Google Code was never a core business of Google.
Github would have to undergo a serious shift before hosting code repos isn't a core business function.
The free-as-in-beer parts of github.com are not (guaranteed to be) a core business of Github either. Just look how lousy Atlassian is with bitbucket.org; their core business is Stash.
Atlassian's core business is Jira and Confluence. Stash is pretty much an also-ran at this point. (Bitbucket, the free product still looks better and has more features - Stash has literally no reason to exist unless your company is terrified of the cloud - and then, Github Enterprise is superior in every way.)
A company I used to work for once had a customer demand (and pay for the purchase of) a separate HPC cluster just for running the simulations for that customer. Because we could not guarantee 100% that it was impossible to circumvent the access controls on the regular cluster, which only had users from the same company, but not all those users had clearance for that project.
Let me just drop this here: https://bitbucket.org/site/master/issue/8436/not-all-github-... shows that Atlassian can't even be bothered to make it easy for people to migrate to Bitbucket, their repo import tool cannot handle the pagination the github.com API does. They can't be bothered to let people paying to Github pay them instead. My guess is: they don't care about your $5 (or whatever puny amount it is) payment for private Bitbucket repos, they care more about the $XX,000 they get from every Stash license sold. And mentions on Bitbucket tickets make it look like Stash is quite popular in some corporate circles.
NB: GHE may be superior in every way, but does it integrate with JIRA as well as Stash does? What if you've already invested in JIRA and want to add a repository management platform? (Also, don't underestimate the portion of the market "terrified of the cloud".)
* 250 user Stash license: $12000 first year, $6000 after [1]
* 250 user GH Enterprise license: $61750 per year [2]
If you need on premise git hosting, I'd look at Stash or Gitlab, long before I thought about looking at Github Enterprise!
[1] https://www.atlassian.com/licensing/stash#serverlicenses-1
I'm trying to see why this is held to be a bad thing. Even if Github shuts down the way Google Code is, I don't see that is a particular problem except for projects that are already essentially abandoned.
Last I saw, they only (rarely) show that they have a 'GitHub Client for Win and OSX'.
Command line interface and all other Git tools are usable. Hell- when you create a new, empty repo they give you the commands to type into your terminal to upload from there.
A great deal of (good!) proprietary software is currently in the hands of consumers too. So?
What is that supposed to mean? Software is software
Different classes of software exist with different licensing concerns.
Let's take a step back:
>>> For (B), that's a good thing. Nowadays, the GPL merely prevents software from having widespread use.
>> Bizarre claim. Doesn't seem to have affected Linux/Android or git itself from achieving widespread use. reply
> Platforms versus modules.
I don't understand what the last line means. I'm not agreeing or disagreeing with it, because I don't know what it means in the first place.
Rebuttal: Didn't impact Android, Linux, or Git.
Operating systems and developer-only tools are special cases and are not relevant to the general claim of "GPL preventing widespread use".
You seem to be distinguishing between two things, but I cannot see what they are.
Three orders of magnitude of what? What is being measured? Do you mean that platforms are bigger than modules?
What I meant is that the software is used differently, and it is developed differently. It seems obvious to me that the ideal licensing for software that is vastly different from these examples of gargantuan/universal FOSS might not be GPL.
According to Wikipedia, SourceForge hosts about 300,000 projects, and GitHub has 10 million as of December 2013.
I still have pretty strong confidence that the majority of open source projects are not GPL'd.
[1] http://www.phoronix.com/scan.php?page=news_item&px=MTg4NDY
One conclusions reached from this is that people tend to not care about licensing when they just want to push this weekends freshly created project into github, which result in the MIT license getting higher statistics in github compared to repositories with some quality requirements. One can also assume that uploading things to github is much easier that SourceForge, and people use github as a development platform instead of a pure publishing platform.
I dunno, I'll admit this thread has been eye opening. The GPL is definitely more common than I originally thought. But I think really nailing down specifics on this would be tough.
Perhaps you meant on a site that's designed to also serve the needs of proprietary programmers, as opposed to just FOSS programmers?
It makes sense for Github to promote other licenses.
Do you consider "proprietary software developers" to be anyone who develops proprietary software, even if they contribute to open source as well? Because even if you did both I would think you would prefer non GPL code since you wouldn't be restricted in where you can use the code.
So again it seems like "on a site by and for programmers it makes sense to discourage GPL" to me, for all except FOSS programmers.
See vdaniuk's response in this same thread.
Also, just because someone hacks on proprietary software doesn't mean their preference is to hack on proprietary software.
As for vdaniuk's response, I read it and I dont see what value it adds. The comment basically said overall GPL is good, without any explanation. Obviously I dont disagree that its good but dont see why one would encourage it over MIT or BSD.
If there's a competing library under a permissive license with mostly the same functionality, the GPLed version doesn't really help. The point of the GPL is to create an ecosystem of software with compelling functionality that makes it much easier (and more fun) to hack on Free Software than proprietary software.
And if you're hacking on proprietary software, repeatedly encountering GPLed libraries you could be using instead of recreating their functionality from scratch makes it easier to make a case to management that maybe the thing you're working on shouldn't be proprietary after all, as well as making it more tempting to change what you're working on.
There are several reasons to give away code. It's perfectly reasonable to want people to share improvements with you, in which case the GPL is the right choice. But it's also reasonable to just not care what happens to the code after you send it off, in which case the GPL is likely to be as much a burden on you as on downstream programmers. Using Stallman's terminology, the GPL prevents people from boarding your code, but it also prevents them from using it with incompatible open source licenses (say, licenses with an advertising clause or a choice of law clause) without special permission. I just don't get all that worked up over whether somebody wants to use the Apache license version 1.1.
I don't care if someone profits from my work. Had O released it as GPL, they would have profited the same from something else. What difference did my chioce of GPL do, other than to prevent others from using my code? None.
Then again, having GPL licensing isn't the only incentive for recieving patches. A developer of closed source, using my library will want future updates to be easily applied without their fixed bugs getting reintroduced. Not sending me a pull request would be counter productive.
I've never noticed a shortage of GPLed projects on Github. But I think it would make sense for Github to nudge programmers into choosing licenses other than the GPL. When I start a project, I appreciate the ability to build off of permissively licensed libraries. At the least, it means that I don't have to worry about various pretend lawyers wasting my time with emails about how the GPL handles some edge case.
We're animals. The feeling of community arises when we're not alone yet feel being in private. Community is us (versus the rest). Github is a faceless "everybody" (vs. nobody left), which on the animal level translates to "me" (vs. everybody else).
It was easier to maintain a tiny community in the times of janky sites with mailing lists and diffs emailed around. Github gives you access to a larger pool of potential drive-by contributors, but you can't create a loose ring of a handful of people in /issues and /pulls. The community arises through people joining, and then failing to leave, a mailing list, and then contributing to the project through occasional replies to questions asked by beginners.
There may be seven long-term subscribers to your niche project's mailing list. When a newcomer shows up with a question, one of them might answer it before you get up. And even if they don't, their continuing passive presence on the list is still a currency that helps you push the niche project further.
Stars on a github.com repository just don't carry that much weight. Seven people might star your niche project repo. If they use their "dashboards", the entry for the new issue (the newcomer asked a support question by filing a ticket since you have no janky old school mailing list) got lost among the other tens and hundreds (even thousands) entries for individual commits and comments in repos those people have starred beside yours. They won't answer that support call for you. And, even if they did, they won't feel being part of any niche project's community either: it was just a drive-by comment on a random issue they spotted on their feed...
tldr: github.com is the largest open-plan office in the world.
http://article.gmane.org/gmane.editors.vim.devel/49968
Looks like as a result, vim is also switching to git for development.
>NOTE: Before the actual migration the current repository on github will be wiped!
Congrats Vim.
Congrats on you not having a clue what git is.
I understand your point that git is git. The code wouldn't be lost. But it would be an undeniable several months of chaos if Github's servers were wiped. Every project standing up its own site... the open source world would effectively cease development for a short time.
It's remarkable that no one really seems to care.
I believe that's more to do with the process than the platform. Having to remember different processes to contribute fixes/features is a pain. I can't count how many times I had to register an account, log into their custom bug tracker, find the darned obscure remote (looking at you, apache SVN), check out, figure out who I have to email the patch... And then doing it all over for a different project makes the entire process a little ridiculous. With Github, it's ridiculously simple: Log in, fork, clone, push, PR, repeat.
> I see this dependence as very bad and dangerous for the global free software movement.
OTOH, having a place to call "home" for FOSS developers generates a better sense of community. It's like hosting a conference across multiple buildings: sure, the venue's big enough to hold X amount of people, but it doesn't seem like there's X people attending if I can't see everyone without having to traverse buildings.
Also,
> It's trivial to push your local copy to bitbucket, or even your own git server. Lock in is not really an issue, in my opinion.
I'd much prefer that over github, as my account sits idle there, while my gitlab gets plenty of use. I suppose it's something I should look into.
It's probably even simpler to use the hosting site for Fossil at http://chiselapp.com/ It's advertised as a free service and houses several hundred publicly accessible sites. Kind of like a low-key GitHub for Fossil repos.
How well does Fossil scale? SQLite (https://sqlite.org/), "the most widely deployed SQL database engine in the world", can't be too small a project. Certainly a nice-looking site, under its skin pretty much a plain-vanilla web-facing Fossil repo.
NeoVim has my full attention; it's a forward thinking project that is doing everything I hoped Bram would do. With that said, it's going to take years before distros start standardizing on neovim, but it will happen.
The GitHub workflow for this - submitting a patch to a project you're not heavily involved with - is very good, and probably a large contributor to the way GitHub is eating everything. No need to subscribe to a mailing list, and no need to get involved with discussions you might not be interested in. But you can easily commit to staying subscribed to your pull request/issue thread.
Of course, that may not suit all changes - but as a default, I think this arrangement a good one.
I've been loosely involved in 2 open source projects which were previously hosted on self-hosted SVN repos.
After a move to Github, not only did the projects pick up new developers, but also gained a bit of visibility.
Github is something unique in my experience... it really is the "place to be" for developers wanting visibility (for any reason). A lot of folks use it as sort of a resume of skill and activeness in the community, and having public projects contributed to under their account serves to bolster that reputation.
How are they going to do that? By selling private repos?
Well, yes. Github makes most of their revenue from Github Enterprise ($5,000+ per year) for large organizations.
Take 10 migrated github repos at random (1) If they did not increase(2) the number of serious(3) contributors, I lose 10$. If they did, you lose 5$.
(1) random sampling: take a repo by using the last digits of a public number (like, say, the nasdaq index). Eliminate repo if "too small" or "not migrated", until you have 10
(2) compare 1 year before github to 1 year after. This gives you three numbers: at start of first year(A), at start of migration(B), at end of migration(C). N1=B/A, N2=C/B. If avg(N1) not > avg(N2), you win
(3) serious means 20 contribs in the year
(further terms will be settled upon if you want to bet, before you accept)
---
(btw, I think it might not mean much to VIM that it moved =P)
Also, the metrics you propose are quite meaningless. There are contributions that actually waste core developer's time but are grudgingly accepted either for political reasons or to shut up the proponent.
These kinds of contributions are certain to increase by a migration to GitHub.
Also, fixes seem to be flowing from vim to neovim.
Before Github, the primary means individuals discovered projects was just by stumbling upon random websites... often times ones that hadn't been updated in who-knows-how-long.
Github clearly shows the health of a project by providing at a glance how long ago the most recent commit was, how many people have contributed to the project, how many people are "following" the project, how many contributions via Pull Requests are pending, etc.
"To see how well this works I have created a SNAPSHOT of the repository. This way we can try it out. "
I just ported all my stuff to Neovim earlier this week and everything works out of the box. I just had to cp everything vim to nvim (.vim -> .nvim, .vimrc -> .nvimrc, etc).
Unfortunately there are no immediate benefits, but I agree with Neovim's long-term goals, so I suppose I'l be there when we get async plugins written in Lua.
% grep SHA256 /usr/ports/editors/vim/distinfo | wc -l
559
It isn't the primary, but it is very much an official mirror. GNOME and the FSF often disagree, even if RMS will have you think otherwise.
The one thing I haven't set up yet is YouCompleteMe (or an autocomplete replacement that uses neovim's threading), as at a quick glance it looked like it would be more than just a few minutes' setup.
http://vimdoc.sourceforge.net/htmldoc/version7.html for the whole list.
What exactly would you like changed? I mean, the termlib stuff could be cleaned up, but that's a universal problem more than anything else.
Please don't do it, the space time continuum will collapse.
DO NOT TRY THIS AT HOME, AT WORK, OR ANYWHERE.