I know the argument: Someone, somewhere has a copy of each repo checked out, so we (the nebulous "we") could reconstruct everything from the diaspora of ".git" directories.
It just bothers me to think how dependent OSS has become upon GitHub.
There is a silly joke about that even. It usually goes like --
"Gee, I wish someone would invent a decentralized version control system".
Fortunately the bug was closed.
Is there any GitHub-esque outfit waiting in the wings that provides free OSS hosting?
https://www.fogcreek.com/kiln/
https://about.gitlab.com/gitlab-com/
I must admit, I rather like bitbucket, you can get free private repositories with them too.
"To create a new project you simply register at SourceForge and then submit a new project request. Most projects are approved immediately, and you'll typically get an email notifying you of the approval in ~ 24 hours "
Used by projects like Qt, GnuTLS, Haiku and CMake.
sircmpwn@homura ~/s/K/kernel master> ssh irc.sircmpwn.com git init --bare kernel
Initialized empty Git repository in /home/sircmpwn/kernel/
sircmpwn@homura ~/s/K/kernel master> git remote add backup irc.sircmpwn.com:kernel
sircmpwn@homura ~/s/K/kernel master> git push backup master
Counting objects: 4735, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (1765/1765), done.
Writing objects: 100% (4735/4735), 7.62 MiB | 650.00 KiB/s, done.
Total 4735 (delta 2954), reused 4699 (delta 2930)
To irc.sircmpwn.com:kernel
* [new branch] master -> masterWhat is our definition of a "point"?
If you have an external hard-drive backup of your laptop, that's 2 points of failure, right? If someone else has 10 external hard-drives that they keep in different places, that's 10 points, yes? But what stops you from calling all those hard-drives "a giant single point of failure"? If all of them are destroyed, the data is lost.
I just don't get these arguments... The chances of all GitHub data being lost is probably less likely than BitBucket and SourceForge combined.
I'm thinking: shut down due to the business model not working, or some other business-model variant, such as gradually getting intolerably crappy like SourceForge. Cash flow isn't great; let's introduce "sponsored" code. Etc.
- 3 images of your data (1 original + 2 copies).
- 2 types of media (e.g. extHD and DVD)
- 1 offshore location (e.g. bank vault, your parents' house,etc.)
A single issue tracker with hundreds of issues for all these projects. A single database of commiter permissions. Etc.
I'd love to see all that metadata in a separate git repo (just like wikies).
To start with, pull requests could be implemented in the main git tool. They're no longer experimental and many, if not most, git users rely in them in some form or another (Github, Gitlab and BitBucket all support them). Folding them into the core would just standardize all the implementations.
It would also be good to define protocols for collaboration. Off the top of my head, that could mean a fork:// browser protocol that would allow a BitBucket user to fork a Github repository and seamlessly submit pull requests back upstream. Some of that is possible today, but there would be some new requirements around federated authentication to enable this (i.e. how to allow a user who is registered with a different service to create a pull request).
If the mechanics of interoperability are standardized, people will develop competitors to Github and things will get more decentralized. But, as mentioned above, Github has a lot of momentum and no incentive to cooperate with other providers. The only way they're really forced to work with others is if these changes and standards are coming from the core Git project.
Even a duopoly (!) would be preferable to a single vendor.
The initial drafts of CSS 2.1 on the other hand, were published in 2002, yet it was 2011 by the time it became a full reccomendation despite having been in use for a long period by that stage. CSS3 colors (i.e. rgba() etc.) also became a full recommendation on the same day.
> Two months earlier, in March of 1998, CSS 2 had become a W3C Proposed Recommendation (PR) which meant that it was considered "done" and was simply awaiting a procedural W3C member review and vote. For all practical purposes, nothing else was going to get fixed in CSS 2. There wasn't a Candidate Recommendation (CR) phase back then, as evidence by the fact that no-one (including my Tasman team as part of Microsoft Internet Explorer 5 for the Macintosh) was able to implement CSS 2 as specified. The problems in CSS 2 were far more severe than mere errata - we had to develop a full revision to fix it.
http://tantek.com/2011/160/b1/css-2-1-css3-w3c-open-web-stan...