|Resolved||Addshore||T173818 [Epic] Kill the Wikidata build step|
|Resolved||Addshore||T181709 Cleanup Phabricator tickets once the build is dead|
|Invalid||None||T108946 [Epic] Improve the development infrastructure|
|Declined||None||T74907 [Task] move git repositories that are dependencies of wikidata to gerrit|
|Declined||None||T126597 [Task] Move WikibaseDataModel to Gerrit|
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.
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.
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.
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).
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.
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.