Talk:Requests for comment/pywikibot git hosting

Git hosting after migration

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)

Move with WMF to Phabricator.

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. phab:T127
• Reliance on WMF staff to support/maintain pywikibot development environment, which is sufficiently different from the MediaWiki dev environment that it breaks and isnt fixed quickly. Currently this includes:
  • code linter on upload for every patch before review commences. This was broken on 14 Jan 2015 due to a policy change at WMF, and has not been fixed yet after 18 days. phab:T87169
  • a link to Github, as that is where all of our complete test suite run. This link was broken for nine days. phab:T87248

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)

If we are even going to lose review data (strange), we are still in a better position than core MediaWiki - we moved in recently and there is not so much to loose. Phabricator is by nature a bit less git-aligned (it works fine with SVN), but I am in favour with abandoning gerrit and pre-commit review in particular.  « Saper // talk »  13:43, 2 December 2014 (UTC)

Move to GitHub

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)
• Although Github is extremely user-friendly, I do not consider it suitable for our community-focused code review workflow. --Ricordisamoa 08:40, 10 December 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.[1] 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)

  Fossil is really cool. I really love it for my little personal projects, where I can competely

auto sync my code between various laptops/servers and test on different platforms immediately. Only used it as a version control and network syncing tool. Much better than git in that respect, since git wants to have a bare repositories to push to and this is a big inconvenience.  « Saper // talk »  13:40, 2 December 2014 (UTC)

• Gitlab offers free hosting. I've had a bit of a look and cant see any significant benefit over github, excepting that it is open source code, and to be honest isnt far behind github for most functionality. It did feel a bit slower than github. John Vandenberg (talk) 16:14, 26 November 2014 (UTC)

I've no idea what migration means for me and the current workflow. Could someone give me some hints about the version control system (git|svn|other) local and remote, uploading of code and other stuff and how the review process could be done under different systems.  @xqt 15:10, 18 March 2016 (UTC)