In T95129#1181191, @Tbayer wrote:

There were many reasons to choose GitHub instead of Gerrit ;) but one of them is that code review is done by Automattic's engineers in the private SVN, so that that part of Gerrit would just be overhead.

I think one of Aude's points was that Gerrit would have empowered the community itself to review code.

Update: I spent some more time in November trying to get the approach described at http://ben.lobaugh.net/blog/147853/creating-a-two-way-sync-between-a-github-repository-and-subversion to work (after reflection, it seemed we should aim for a solution that can sync the full history, e.g. because people might want to reuse an older version of the theme without the 2015 changes or the ones that are still going to be implemented. The simpler approach by Daniel doesn't seem to provide that.)

Unfortunately, some of the steps did not work as described there. I should take some more time to describe the error messages in detail and maybe start asking on StackOverflow etc. But in the meantime, input from a Git/SVN expert would be appreciated - let me know if you would like to volunteer a few minutes to walk through this.

However, I think that once we have the setup figured out, doing the syncing will be straightforward.

In T95129#1181745, @Ricordisamoa wrote:

In T95129#1181191, @Tbayer wrote:

There were many reasons to choose GitHub instead of Gerrit ;) but one of them is that code review is done by Automattic's engineers in the private SVN, so that that part of Gerrit would just be overhead.

I think one of Aude's points was that Gerrit would have empowered the community itself to review code.

I'm not sure if that it was she meant. In any case, that's a misconception - Automattic will do that internal code review according to their standards regardless of what the setup is son our side.

In T95129#1961965, @Tbayer wrote:

Automattic will do that internal code review according to their standards

I am not sure I understand correctly. Why does the Wikimedia Foundation need a company to review their code?

In T95129#1962133, @Ricordisamoa wrote:

In T95129#1961965, @Tbayer wrote:

Automattic will do that internal code review according to their standards

I am not sure I understand correctly. Why does the Wikimedia Foundation need a company to review their code?

I believe it's because Automattic runs WordPress, which the blog is based on!

Automattic host Wikimedia's WordPress installations - the code goes into their production servers and therefore needs review by them.

In T95129#1962547, @Krenair wrote:

Automattic host Wikimedia's WordPress installations - the code goes into their production servers and therefore needs review by them.

A $60M+ organization developing a major PHP wiki engine is not able to host a WordPress installation :-\

In T95129#1962615, @Ricordisamoa wrote:

In T95129#1962547, @Krenair wrote:

Automattic host Wikimedia's WordPress installations - the code goes into their production servers and therefore needs review by them.

A $60M+ organization developing a major PHP wiki engine is not able to host a WordPress installation :-\

WMF is able to (and in the past, did) host a WordPress installation. See https://wikimediafoundation.org/wiki/Vote:Approval_of_Automattic_contract

Update: On Friday night, @Volker_E, @Tgr and I spent several hours trying to get the recipe from http://ben.lobaugh.net/blog/147853/creating-a-two-way-sync-between-a-github-repository-and-subversion to work, resuming where I had gotten stuck earlier. Thanks in particular to @Tgr's expertise, we succeeded!
The theme is now published at the planned location (see task description) and we successfully tested merging public pull requests on GitHub into the private production repo on Automattic's SVN; @Tgr also wrote us a little macro to avoid having the extra commits from merging pull requests clutter up the history more than necessary.
Regarding the other direction, I have since verified that syncing new commits from SVN to the GitHub mirror works as well (there, no changes to the original recipe were needed).

Notes about the process are here; I will clean them up and make them into a proper documentation of the setup later. To be clear, this is not an automatic mirror; every change committed (to trunk/master) on either side needs to be mirrored manually to the other side by whoever maintains the gateway on their laptop or server (currently, me). Fortunately, this only takes a minute or so if one follows the recipe.

(There were still two unexplained oddities, perhaps due to the fairly large size of the repo - 12MB -:

• The first run of git svn fetch for the initial export of the theme from Automattic's SVN reproducibly aborts with a Bad file descriptor error. But simply restarting git svn fetch appears to fix that.
• Similarly, the initial publication of the repo on GitHub with git push -f failed on one try with remote: fatal: early EOF and RPC failederrors, but succeeded on another try.)

I'm leaving this task open for now to account for further testing and documentation, and because the theme still needs to be released under an appropriate license with more detailed authorship info. (BTW the repo is missing some earlier history from 2014/15 because our developer decided earlier this year to start a fresh repo copying over the then current version of the theme.)

@Tbayer Resolved from my perspective, anything open in your opinion?

In T95129#2855244, @Volker_E wrote:

@Tbayer Resolved from my perspective, anything open in your opinion?

See my remarks from last month above. I have updated the task description to spell out these (minor) subtasks that are still open.

@Tbayer @EdErhart-WMF What should that license be? MIT or GPL?

@Volker_E sorry for the delay on this. Our default license is CC BY-SA, but I assume that's not the norm for Github. I'm fine with whichever license you think is best.

In T95129#3035506, @Volker_E wrote:

@Tbayer @EdErhart-WMF What should that license be? MIT or GPL?

Pinging @Slaporte who is the expert on this and can review the developer contract if needed. (I understand we normally go with a version of the GPL.)

In T95129#3257523, @Tbayer wrote:

In T95129#3035506, @Volker_E wrote:

What should that license be? MIT or GPL?

Pinging @Slaporte who is the expert on this and can review the developer contract if needed. (I understand we normally go with a version of the GPL.)

@Slaporte: ping?
Or is there anybody else to CC?
Or add the WMF-Legal tag?

Just to clarify the current status, the only thing missing here is an explicit license on the published code. https://wordpress.org/news/2009/07/themes-are-gpl-too/ makes it clear that the PHP parts of WordPress themes must be GPL. The only thing we still need WMF-Legal clarification on is the license status of the images and JS/CSS parts of the theme, so adding the appropriate tags. I would hope based on https://developer.wordpress.org/themes/getting-started/wordpress-licensing-the-gpl/#do-i-need-to-license-my-themes-under-the-gpl that the rest of the theme is also GPL.

What needs to happen to move this task forward? An e-mail to legal@wikimedia.org?

In T95129#4912084, @MZMcBride wrote:

What needs to happen to move this task forward? An e-mail to legal@wikimedia.org?

That's the only way to elicit attention from Legal over Phab tasks. Joe mentioned that Phabricator is not really somewhere Legal routinely looks at, apart from tasks related to NDA stuff.

Email sent today to legal@ with a link to that task.

@Slaporte :-Re-reminding you that you have been pinged multiple times over here and that you have commented over other Phab tasks since. Also, paging @CRoslof and @Jrogers-WMF. If you are discussing these stuff internally (and it is taking such a long time), you ought to have the courtesy to (at-least) make a minimalist statement over here.

In T95129#4496825, @Legoktm wrote:

Just to clarify the current status, the only thing missing here is an explicit license on the published code. https://wordpress.org/news/2009/07/themes-are-gpl-too/ makes it clear that the PHP parts of WordPress themes must be GPL. The only thing we still need WMF-Legal clarification on is the license status of the images and JS/CSS parts of the theme, so adding the appropriate tags. I would hope based on https://developer.wordpress.org/themes/getting-started/wordpress-licensing-the-gpl/#do-i-need-to-license-my-themes-under-the-gpl that the rest of the theme is also GPL.

For the sake of consistency, please use the same version of GPL for all code portions of the theme, including the JS/CSS parts. Non-code portions of the theme (like images) can be made available under a CC BY-SA license if necessary.

In T95129#5055407, @WingedBladesofGodric wrote:

@Slaporte :-Re-reminding you that you have been pinged multiple times over here and that you have commented over other Phab tasks since.

Apologies for the delay responding to this. If you need me to look at a phab task, email (slaporte@wikimedia.org) is the best method to reach me directly. Thank you!

Any news here?

If I understand the intentions well, here my two cents to avoid proposing a (brr! I'm scared thinking on it!) git←→svn continuous conversion.

We can instead:

• have our own git repository for development (like every WordPress theme in the world does to stay healthy and simplifying their own upstream review)
• have a completely separated Automattic's svn repository just to publish releases (like every WordPress theme in the world does to make Automattic happy and allowing their own downstream review)

To fit this purpose we can create a small and dummy and effective script to make an svn commit when a git commit is ready for production (when we tag that git commit?) or something like that.

And the very important rule of thumb to keep this bidirectional:

• pull from Subversion in git before pushing git in Subversion, to eventually merge their downstream patches in git (more easy to be done than to be said).

It may sound quick and dirty, but I think it will be much cleaner than maintaining a bidirectional conversion, hoping to simplify the life of the guys that will handle this.