Talk:Requests for comment/pywikibot git hosting

Try to keep gerrit
Unlikely to happen.

Pro

 * Familiar workflow

Discussion
Can we set up our own gerrit on labs, and move the existing data (old and pending code reviews) to it? That part is probably easy for us to host and maintain, on labs or elsewhere. Continual integration (jenkins/zuul/workers) is going to be the hard part, I assume. John Vandenberg (talk) 02:37, 16 November 2014 (UTC)

Pro

 * We keep integration with the WMF community, including e.g. unit testing
 * Patch workflow comparable to Gerrit

Contra

 * Currently not trivial to contribute without Arcanist installed []

Discussion
Will WMF migrate all Gerrit data into Phabricator? T617 suggests they wont, which means we loose all of our design discussions. NHJ!. Actually, I am a bit stunned that the MediaWiki team might be happy to loose their code review data. John Vandenberg (talk) 02:54, 16 November 2014 (UTC)
 * There's no obvious need to migrate Gerrit stuff to Phabricator, similar to how SVN was not migrated to Gerrit. So long as the old read-only Gerrit data is kept around for reference (similar to Special:Code here), that ought to be enough for the pywikibot project? (I'm saying this as a complete outsider, knowing nothing about pywikibot...) This, that and the other (talk) 06:15, 16 November 2014 (UTC)

As a person who was involved in all of migrations: We migrated from svn to git (actually we forced to do so) one year ago. When the mediawiki was moving to gerrit and git in 2010, pywikibot community decided to stick to the old system and we moved three years later and that's what made migration to phabricator a tall order. Break the chain of being conservative (by being a little too radical for once). For seeing how good is Phabricator read this Quora question and the RFC Ladsgroup (talk) 15:04, 16 November 2014 (UTC)

Pro

 * Larger developer audience

Contra

 * Different, patch workflow
 * GitHub is closed source

Discussion

 * all that movements of WMF from one platform to one are quite tiring. For me GitHub is even more user friendly that Gerrit and I don't consider "different patch workflow" as a contra point. Rubin16 (talk) 17:17, 15 November 2014 (UTC)
 * If we move to Github, the core development team can use GerritHub https://review.gerrithub.io/, and the 'small changes' (e.g. changes of template names for one wiki) can be done as github pull requests or if they become big changes they can be pulled into GerritHub for more formal review. There is also a good chance that we can migrate the old Gerrit code reviews into GerritHub (for a once off fee, probably, or maybe we can do it ourselves) John Vandenberg (talk) 02:32, 16 November 2014 (UTC)
 * Calling Github closed source is not really fair. They open source a lot of the code used in the infrastructure.  e.g. https://github.com/github/markup .  As an organisation, I would characterise Github as rapidly-pro-open-source - their business model depends on open source.  We care about whether we can get our data out if they ever turn anti-open-source, or a significantly better provider arrives on the scene. John Vandenberg (talk) 02:41, 16 November 2014 (UTC)

Other options (list below)

 * Bitbucket
 * Gitorious (https://gitorious.org/about)
 * Fossil (http://www.sqlite.org/debug1/doc/trunk/www/fossil-v-git.wiki) hosted via http://chiselapp.com/ or even on sf.net at http://fossilrepos.sourceforge.net/

Discussion

 * The one feature of Bitbucket that could make it a winner is its integrated Windows client application. OTOH, Github allows editing of 'source code' in a web browser, and the next release of Gerrit also allows in browser editing of code. John Vandenberg (talk) 03:33, 16 November 2014 (UTC)
 * SourceTree also has GitHub integration. Valhallasw (talk) 09:38, 16 November 2014 (UTC)
 * Fossil provides an interesting alternative, and pulls all of the project data (bugs, code, code review) into the same distributed repo, which can be hosted anywhere. John Vandenberg (talk) 03:33, 16 November 2014 (UTC)