Page MenuHomePhabricator

[Task] Move WikibaseDataModel to Gerrit
Closed, DeclinedPublic

Description

I suggest moving https://github.com/wmde/WikibaseDataModel to Gerrit. Personally, I see no strong arguments against doing this. Are there any blockers for this?

Event Timeline

Tobi_WMDE_SW raised the priority of this task from to High.
Tobi_WMDE_SW updated the task description. (Show Details)
Tobi_WMDE_SW added subscribers: Krenair, Tpt, Lazowik and 22 others.
Qgil removed a subscriber: Qgil.Feb 11 2016, 12:43 PM
Bene added a comment.Feb 11 2016, 8:05 PM

How do releases work on gerrit? Do they integrate with packagist the same way it works on github currently?

Currently we have the github mirror configured to tigger packagist and packagist configured to use the github mirror. There is T87768. Also I think using something that is not github with packagist currently would result in composer not being able to use archives instead of git clones.

Basically you create a tag on gerrit, that gets mirrored to github, which on good days triggers packagist, which updates its meta data from github.

Have you considered moving to Phabricator + Differential instead of gerrit?

How would that fulfill our CI needs?

Bene added a comment.Feb 11 2016, 8:42 PM

Have you considered moving to Phabricator + Differential instead of gerrit?

I'd really appreciate that. Having code and tickets at one place will help us a lot imo.

Is there already code hosted here on phabricator, or would that be a jump into the deep end?

(Which is basically run composer update && composer test for a few php version or the zuul template composer-test.)

Do we want to have yet another place we need to tell people to get our code from and submit patches to? Github and gerrit is already a challenge for people apparently. If you think the benefits outweight the drawbacks I will not object but please keep this in mind.

Bene added a comment.Feb 12 2016, 10:23 AM

What I expect is that eventually all our code will be located here on phabricator and integration with our ticket and sprint system will improve significantly. The question is when this transition will happen. I'm all in favour of trying new things out but maybe we shouldn't do that testing with one of our most important components like the data model.

Lydia_Pintscher moved this task from ready to go to consider for next sprint on the Wikidata board.
demon moved this task from Bugs & stuff to Repo Admin on the Gerrit board.Jul 25 2016, 3:47 PM
demon added a subscriber: demon.Jan 25 2018, 2:52 AM

@Addshore: thoughts, especially in light of all the work we did to clean up the build process?

Moving this component alone is not really worth much. We are barely touching it any more. It's just some git repository, and it really should not matter that much where a git repository lives. It matters for other reasons than the build, but as said, as far as I'm aware of there was never that much pressure or even demand to change anything here.

If Wikibase-DataModel is moved, please make sure at least these repositories are moved the same time:

Thanks for ping @Addshore. I have no strong opinion here. Some rambling below.

Description mentions there are no strong arguments against the move. I wonder what would a win after such move?

I understand it might make sense from WMF point of view as "all things in one place" (but then it should probably rather be moved to Diffusion than to Gerrit, right?). But this library is not installed from github any way, but it is part of mediawiki vendor, so I guess the location of the "main" git repo does not make much of a difference?

This library is used by several tools except Wikibase. For these it might be preferred to keep on Github? But I am not convinced either, for such tools it is probably only important that composer/packagist picks it up and installs it. After move to Gerrit/Differential, I guess we would have a github repo as a mirror for packagist, or would packagist be happy with gerrit/differential repo as well?

In any case, we would probably keep the github repo any way (as a mirror or so) for better visibility of the lib (also referring the recent discussion at the developer summit etc).

So to end up this babbling, I think it would be fair to ask "third-party" users of this library what they think. @Addshore and @JeroenDeDauw are the ones I am aware: what do you guys think?

As a 'third party user' I have no real preference for the location, as long as it is installable via composer.

demon added a comment.Feb 12 2018, 4:50 PM

I understand it might make sense from WMF point of view as "all things in one place" (but then it should probably rather be moved to Diffusion than to Gerrit, right?). But this library is not installed from github any way, but it is part of mediawiki vendor, so I guess the location of the "main" git repo does not make much of a difference?

Nope, it doesn't really matter where it's at, since it's installed via Composer/mw-vendor (my impetus on bumping this task was just to get a resolution, I'm impartial to what that resolution is...could be declining the task). To answer the first comment: no, Gerrit would be the right place, not Differential.

WMDE-leszek closed this task as Declined.Feb 13 2018, 8:40 AM

Thanks @demon for explanation, and @Addshore for putting the other hat on!

One point that has not been brought up yet, is that it important for the Wikidata team as for maintainers of the said library that the PHP version compatibility is ensured by correct CI setup. We are rather happy with the existing Travis CI setup. While it would definitely not be impossible to have a similar job matrix configured using Gerrit+Jenkins combo, but that would require some work.
Given that the library is not in very active development, we prefer to not change existing working things unless there is a significant need.

Given all what's been said in the comments above, I would go ahead and say the maintainers of the library prefer the most simple solution, i.e. not doing anything. Therefore I decline this task.

This of course does not mean this cannot be revisited in the future, either by re-opening the task, or submitting a new one.

Restricted Application removed a subscriber: Liuxinyu970226. · View Herald TranscriptFeb 13 2018, 8:40 AM