On Fri, Dec 18, 2015 at 1:29 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Ben, Hi All,
I'm quite conservative when it comes to relying on others' infrastructure so I need some help making me take the plunge. Please see below:
On Thu, Dec 17, 2015 at 7:15 AM, Ben Coman btc@openinworld.com wrote:
On Wed, Dec 16, 2015 at 1:00 AM, Ben Coman btc@openinworld.com wrote:
On Wed, Dec 16, 2015 at 10:43 AM, Ryan Macnak rmacnak@gmail.com wrote:
What would be more helpful is if the VM build was fixed to work with a cross compiler, so it would compile fast enough to test ARM and MIPS on Travis CI alongside IA32 and X64.
It would also help if the top-of-tree Intel VMs were always kept working so we'd know which change broke something. Moving the Subversion repository to a more reliable host (which likely means migrating to Git) would also cut down on the false positives Travis reports because the Subversion server has a habit of dropping connections.
+1 github :)
btw, Did you know that github supports subversion clients since 2011 [1]? Here are supported features [2]. Are these sufficient for your current svn workflows? Potentially we could have ONE repository and those liking subversion can stick with it and those liking git can use that. Of course, this would need to be proven.
Ah, that's interesting. So my concern is whether github is a safe long-term bet. Specifically what is there to prevent some third party from buying github, or of github going public and the board taking the decision, or github on its own, deciding to charge for hosting, keeping the data hostage to extract payment? What safeguards are in place to prevent this?
I'm not interested in "this will never happen" arguments. I'm interested in hard data please.
Obviously there are no guarantees. The main safeguard is that git's distributed architecture provides by default that your local repository is a complete cache copy of the *entire* history. Your "code" data can *never* be hostage. You can push it to any other git server or peer. This would not be the case if you are using svn client, but then there'll be a dozen other people with a local cache, plus you could separately cron a git client to regularly pull to a backup location on your local system.
Any of the auxiliary services like code review comments, issue tracker and wikis might be another story, but I'll wait to know how critical you consider those before I defend them.
Now while an broad statement "it will never happen" cannot be relied on, it may still be worthwhile to consider some supporting reasons why the free service will
1. Today data storage is *cheap*. Consider other free services: http://www.minterest.org/onedrive-vs-dropbox-vs-google-drive/ * Google drive 15GB free * Microsoft Onedrive 15GB free * Amazon cloud 5GB free * Box 10GB free * Mega 50GB free Code as text is low overhead - particularly since git manages content by hashing thus duplicate eliminated.
* Google Gmail - I see your use gmail. Are you overly concerned about google someday holding your data hostage to extract payment?
2. Github make money from auxiliary services. Profitable companies exist today that help recruit top-talent. Github are ideally placed to provide such a service from the unique contributor data available only to them. http://www.cnet.com/au/news/forget-linkedin-companies-turn-to-github-to-find...
3. Similar Indirect Sale-Value business models apply to providing a free service and providing open source software... http://www.catb.org/esr/writings/magic-cauldron/magic-cauldron-9.html a. Loss-Leader / Market Positioner - without a free service, someone else will come along with a free service to gain some market share b. Give Away the Recipe, Open A Restaurant - sell services as *The*Expert* - much like Red Hat does. c. Freemium businees model that makes money from additional services. With 26 million repositories, 10 million users and 60 thousand organisations, you only need to convert a small percentage to be profitable - but you need to continue to keep competitors away. https://github.com/pricing https://enterprise.github.com/home
So the business decision is to balance what risks, financial costs and opportunity costs are ameliorated today by using 3rd-party infrastructure, versus risks, costs and likelihood of needing to move to other servers some time in the future.
cheers -ben
[4] Provides pragmatic advice for cutting over. Esteban appears to have done similar to step 1 and 2 [3] - but it seem sometimes his modifications directly update this mirror so its not clear to see when that branch is an *exact* copy of the current svn trunk. So I'd love to see a github repository that is always an *exact* mirror of the svn repository, with any pharo mods occurring in a branch off that. Even better if the repository for svn users resides on github in place of that mirror.
I've been googling around for problems reported using github via an svn client, and haven't found any smoking guns. Is this something we can trial? I'm willing to put some effort into it. A key requirement would be not interrupting Eliots work on Spur-64. Potentially we could stay for months on step 3 [4] with the CI infrastructure running on the git side, but code check-ins continuing onthe svn side.
btw2, [5] provides a use case for the advantages of a full switch.
cheers -ben
[1] https://github.com/blog/966-improved-subversion-client-support [2] https://help.github.com/articles/support-for-subversion-clients/ [3] https://github.com/pharo-project/pharo-vm/network [4] http://blogs.atlassian.com/2013/01/atlassian-svn-to-git-migration-technical-... [5] http://blogs.atlassian.com/2013/01/svn-to-git-how-atlassian-made-the-switch-...
-- _,,,^..^,,,_ best, Eliot
vm-dev@lists.squeakfoundation.org