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.
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.
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?
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.
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.
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
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.
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
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.
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.
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.
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.
On an unrelated note, why haven't there been any more modal editors?
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.
What you're describing is an interesting idea and LyX is sort of like that. Mathematica also works pretty similarly, it has different ways of representing and entering equivalent expressions visually (e.g., TraditionalForm or DisplayForm). You can switch modes for a particular cell and the underlying meaning is preserved. There's also a special escape sequence for entering symbols and a lot of symbols have an equivalence with their obvious operators, for instance "x ∈ X" is equivalent to "Element[x, X]".
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.
There are no insurmountable obstacles to what you are asking. At least none that I can see now, but I do see some things that wouldn't be convenient.
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.
GitHub has done a remarkable job at being less evil than many proprietary companies… but they are doing one very annoying thing: actively undermining the free software movement by (A) getting everyone to use their proprietary tools and (B) craftily undermining the GNU GPL and related licenses by making their license-chooser and choosealicense website designed to discourage GPL use.
I think you'll find there are few arguments to be made for the open-ness of the platform (except for the religious ones) when data export is central to the platform's reason for existsnce.
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.
Exactly. The choosalicense site is designed to be neutral enough to avoid overt bias. It wouldn't work if it didn't appear neutral. But it is not neutral.
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.
I think the text for GPL is much more discouraging than the others ...
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"
Those edits are completely insubstantial. #1 is basically s/restrict/demand. #2 completely obscures the actual differences with a "don't worry about it" handwave.
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.
I think josinalvo has a point. Can we at least agree it's not the most likely wording that the FSF would have chosen? So while "discourage" might be too strong, it's likely not a favorable way to put it. Perhaps a pull request would be welcome?
Sure! But consider that the whole point of choosealicense is to be non-judgmental and to explain facts, and the facts are not in question here. Saying that the GPL is more restrictive is not some slight against the GPL, it is a forthright explanation of its attributes.
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.
If the point of choosealicense is to be non-judgmental, they should use non-judgmental language to do so.
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.
Trying to paint that line is a bit too politically minded for my tastes. From the perspective of choosing a license for your GitHub project, GPL is restricting the consumers of your project (other developers). Attempting to explain the purpose of those restrictions will just make this less clear.
The GPL is a political weapon, designed and built for a political purpose: to fight the venal and short-sighted policies of software producers (companies and developers.)
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.
I disagree: the intent of the GPL is to preserve freedom; the way the GPL preserves freedom is by preventing you from removing it by changing the terms.
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.
I'll try another rewording:
"GPL is a license designed so that, no matter how many times people alter your code, a user that gets the program also gets the source code. To do that, it forbids developers from using your code in some contexts."
better ?
(sure, there is a tradeoff between comprehensibility and precision ...)
If you want to propose improvements, stop accepting the V2 or V3 nonsense. Telling people to use an old version is an aggressive rejection of the new version. Adding extra version choice is a subtle way to make it more complex and even less likely for people to choose the GPL overall. V3 is an improvement over V2 in basically every respect — unless you like the loopholes in V2 or are worried about compatibility with V2-only code.
> Github without distributed commits isn't based on git anymore, and the other stuff is ancillary (and also easily exportable)
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 disagree about point A. GitHub as a whole is proprietary, but they have an exceptionally well designed API that can be used to export issues, pull requests, and wiki data. I setup a cron to backup this data weekly in case of a catastrophic github data loss event. There are multiple open source tools to get this meta data.
I'm pretty sure there is a tool to transfer a GitHub repo and all meta data to GitLab (which is open source).
My current strategy is to host on Github and mirror to Gogs on my own server. I might eventually swap that around. There are advantages to Github in terms of the number of eyeballs and ability to search, but I expect that it will go the way of all proprietary systems and probably will start becoming evil sooner or later. Developers have faith in Github in the same manner that they once had faith in Google and Google Code.
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.
Um, what? Bitbucket was around long before Stash was. Bitbucket was a startup and acquired by Atlassian back in 2010, with Stash's first release not happening until 2012.
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.)
Stash is not just if your company is terrified of the cloud. It's also perfect when your customers are extremely risk averse and will not even bring their business to you if you host anything outside your own company, which of course has to be security audited into infinity.
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.
Stash may not be the cash cow that JIRA is but it seems to make more money than Bitbucket does. My assessment of Atlassian's approach to Bitbucket is based on me observing them handling tickets for it (stonewalling for years), and other users' observations on the difference in the way they handled BB vs Stash. The silence from Atlassian on some years-old Bitbucket tickets is deafening...
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".)
> Developers have faith in Github in the same manner that they once had faith in Google and Google Code.
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.
I don't feel that they're actively underminding the GPL. I feel that they're presenting the options fairly as to what the pros and cons are for each license. Now, I'd be curious as to see if metrics would change for each license if they were to randomize the locations of the "big three", so as to give no evidence of being biased.
I think you might be responding to the wrong comment? I didn't say anything about proprietary software, or about one being better or worse than another.
It could be users, contributors, time, money, or lines. Most or all of these apply to the difference between linux/git and average software. I don't accept it as an axiom that the biggest open source project in the world should be licensed the same as something in the first percentile of (pick one).
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.
I don't think GPL needs discouragement, the dev community in large has decided they just don't like copyleft. I appreciate all that Stallman has done, but his ideas and practicality don't always align.
This is a pretty interesting article [1]. Out of GitHub, SourceForge, CodePlex and the Apache Foundation, SourceForge is largely GPL but the rest largely are not.
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.
A larger majority (>80%) of packaged programs in Debian, Ubuntu and redhat is GPL. If you look at what people actually use in their servers or open source desktops, then the majority will be GPL.
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.
The converse of that is as a frontend developer pretty much 100% of what I use is MIT or similar licensed. In fact I'm struggling to even think of one software package that is copyleft in the frontend world.
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.
Considering the vast majority of programmers are proprietary programmers, at least for most of their week, I would consider the GPL not designed specifically for all programmers, but rather FOSS programmers, which is a minority on Github (and everywhere else, except highly specific communities).
It makes sense for Github to promote other licenses.
I'm not arguing against that; it does indeed make sense that github promotes licenses that make life easier for proprietary software developers. I'm arguing against the assertion that "On a site by and for programmers, it makes sense to discourage GPL".
Why would programmers want to promote GPL, if they are not FOSS programmers?
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.
Indeed my preference is definitely not to hack on proprietary software. However if I have to do the same thing I'd prefer not to have to choose and learn how to use two different libraries for example.
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.
> Indeed my preference is definitely not to hack on proprietary software. However if I have to do the same thing I'd prefer not to have to choose and learn how to use two different libraries for example.
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.
Personally, I wouldn't; there's a difference between "code that doesn't get distributed to anyone" and "code that gets distributed to some people in binary form but not in source form". If everyone who has a binary has source, everyone who has the software can hack on it. There's nothing wrong with choosing not to distribute software at all.
I think you're wrong. GPL is designed specifically for FOSS programmers who work only on FOSS projects. Legally, it's a restrictive license that limits options for developers who develop for a day job (for a company that keeps their software proprietary). The BSD and MIT licenses are far superior for the average working dev.
What are you talking about? If I'm going to give my code away, it's because I want people to use it and share it, and letting downstream devs take my work and close it up for private gain would suck - especially since they're not obligated to share any of their private profits with me. No, if I'm going to give my code away, it's going to be "share and share alike", and that's what the GPL does best. How would it be "superior" to give my code away in a manner that lets other people take advantage without sharing?
> If I'm going to give my code away, it's because I want people to use it and share it, and letting downstream devs take my work and close it up for private gain would suck - especially since they're not obligated to share any of their private profits with me.
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.
Look, individually BSD and MIT licenses are superior for an "average" programmer, however all programmers and users would be much worse off without GPL.
> Perhaps you meant on a site that's designed to also serve the needs of proprietary programmers, as opposed to just FOSS programmers?
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.
Permissiveness is relative. GPL restricts developers from restricting the code. GPL code cannot be restricted, it is and always will be free. GPL is extremely permissive to code. "You can take my code and do anything you want with it. A person that gets the code from you can also do anything they want with it."
It need not become one to be a problem (just as it is a boon). The benefit of frictionless contributions is real, the problem of loss of federation is real just as much, and leads to the loss of community.
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.
This is an official migration. Here is a link to an actual source since I was originally skeptical because I know vim uses mercurial and that there have been unsuccessful discussions in the past.
Slightly off topic, but I am actually surprised "vim" was not a taken user name. Does GitHub grant special projects like vim its name if the name is taken but inactive?
I believe you can email github and ask for a certain user name and they'll give it to you if it has no or very little activity. For instance, Ken Thompson joined github a little while ago and he got the user name 'ken'. Don't know how he did that, but I guess it helps being Ken Thompson.
Consider how you'd phrase it if your comrade were standing next to you instead of being on the Internet.
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.
For increasingly many developers (potential contributors) a project effectively does not exist if it is not on GitHub. And, being a huge centralized service, GitHub is very susceptible to censorship (e.g. repos being taken down via DMCA or Russia blocking GitHub until they started to cooperate with the censors). I see this dependence as very bad and dangerous for the global free software movement.
> For increasingly many developers (potential contributors) a project effectively does not exist if it is not on GitHub.
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 see no technical reason why GitHub could not have been implemented as a federated system. Should we even consider convenience of a service that has serious ethical issues?
I wonder how difficult it would be to federate gitlab or gogs. Set up something like OAuth so you can log into anyone's gitlab (provided they have to set to public) and be able to fork/clone/branch to your "home" instance of it. Have an interface akin to github but have it pull in data from other gitlab instances you linked/subscribed to. You could also run some sort of public opt-in indexing service for discoverability of new projects, but the code would be hosted on your own instance.
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.
That reminds me of Fossil, a DVCS that integrates issue tracker and wiki so that every clone of a repository contains fully functional project website accessible via built-in http server.
Glad to see someone mention Fossil, a fine choice for small-medium sized projects. Fossil may not be ideal for huge projects, but easily running a Fossil repo on my own web server suits my purposes.
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.
Fossil supports incremental import and export to Git, so it should be possible to maintain a Git mirror of a Fossil repository or vise versa. This does not work for tickets and wiki, but the Fossil web server can also render markdown documentation located in the source tree.
It's highly unlikely that it's going to do anything to improve vim. It seems this is being done out of necessity, namely google sunsetting Google Code. I could be wrong, but it's unlikely that Bram has had a change of heart regarding encouraging contributions.
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.
It's possible. But if they just attract drive-by patches that people like, that's fine too. Contributions from a wider range of people, that add features they're looking for (no matter how minor) will make the project more appealing to more people.
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.
And is it a good thing to outsource one's resume to a company that somehow, at some point has to justify a $100.000.000 investment by Andreesen & Horowitz?
How are they going to do that? By selling private repos?
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)
You misunderstand completely. Of course small random projects like flappy-bird-in-cobol may benefit from a migration. I'm talking about well established projects.
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.
Vim is still usable for day-to-day work: it works on Windows, it has a gui binary, it's a stable build and not a beta. People are going to have bug reports/fixes for what they're using.
Also, fixes seem to be flowing from vim to neovim.
Github allows for people to discover projects to be passionate about that they may not have discovered otherwise.
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.
i wouldn't call them "peripheral" if they have in parts led to a fork of the project already (See discussion of of vim contribution process and it's pains otherwise in this thread)
He said that this is just to try out github for now. And for now the official development will be on Google Code. And then when he's ready to move it over, he'll wipe the current repository on github.
"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.
turns out this is because FreeBSD's vim port is really bleeding edge / development and not using stable releases. But really, it shouldn't go 500 patches and still have no new release cut...
I really do wonder if there will ever be even a semi-official emacs repository on github. I suspect not, but think it would be interesting to see if people contributed to emacs using PRs.
Official or semi-official? Never, unless github's server goes FOSS at some point. When someone attempted to get github mirrors of GNOME or GCC declared "official", the official response was that anything hosted on a proprietary git hosting site should never be official.
Interesting; thanks for the correction. Last time I'd seen that discussion, I thought the conclusion was that it was a supported mirror (as in, the GNOME project would keep it up to date), just not an endorsed mirror (as in, the GNOME project doesn't officially recommend its use).
I made the switch a week or two ago, and it was pretty painless. Kept most of my previous configuration, but only brought it over once I used it and missed it (to find out what I'm acutally using).
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.
Has my Grandpa's hammer been significantly improved in recent memory? Nope, still in my toolbox and still my favorite hammer. Ok, ok, not a good analogy but my point is that not everything actually needs constant improvement. There is a cultural bias towards newness and improvement in technology, naturally, but frankly using ViM is one way I manage to escape that on a daily basis and be thankful for stuff that works as well for me today as it did 15 years ago.
sure! to pick a few highlights, there was tree-style undo, integrated spellchecking and intellisense in v7, folding, diff mode and integrated remote editing and the commandline window in v6, syntax highlighting and vimscript in v5.
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/