This is tracking steps for splitting wikibase.git.
Jeroen De Dauw, 13 July 2014, "Splitting the Wikibase git repo":
Now that we have code that in some way depends on things in the Wikibase git (ie Wikibase Query depends on Wikibase Repo and Wikibase Lib), the state of this git repo is becoming problematic. It forces development against master and pulling in of both repo and client.
To address the most immediate problems, I suggest the following steps:
- We create a 0.5 tag, which Wikibase Query and co can then use
- We split the git repo in 3: repo, client and lib
- The new components get bumped to 0.6 alpha
- Wikibase Query and co reference the new components when we get to it
This is not blocked by, or blocks, further cleanup of repo and client, and the further breakup and phaseout of lib.
Things to consider before proceeding:
- We do not want to do this close before the branch point, preferably close after one
- This will change how things are installed (no more need for these silly wgEnableWikibaseRepo and wgEnableWikibaseClient settings). Not sure this requires work from WMF side, since we got the build. Build and install docs will need updating though
- We will need to migrate commits awaiting review. Commits that span across the different components will require the most work. So getting the review queue down and avoiding big commits is helpful
Jeroen De Dauw, 28 October 2014, "Testing the Wikibase.git split":
Last week I created an experimental split of the Wikibase.git repo, as previously discussed. Before doing this for real, I'd like some help with testing, and ensuring we are all good to go.
These repos are at:
(They are on GH since it's easier to create and delete repos there - the real split will be on Gerrit.)
The PHPUnit tests run fine for me. No idea about the Selenium or QUnit tests (this is mainly what I want help with).
There is one known blocker at present, which is an issue with the paths of the resource loader modules in various of our components. These components determine their location relative to the extensions directory , which obviously breaks if they are not in the extensions directory. When installing them in the wiki root, they end up at wikiroot/vendor/[ValueViewPath], end thus break. Currently this is avoided because they are installed in Wikibase.git, end thus end up in wikiroot/extensions/Wikibase/vendor/[ValueViewPath]. We need to update these components to either figure out the path correctly in both cases or mark them as MediaWiki extensions rather than libraries, so they end up in wikiroot/extensions/[ValueView]. Adrian told me he is already running into this problem and has some local hacks. I'd appreciate input from the people working on these JS components on how to proceed.
The path issue will not occur for deployment, since the paths will end up in wikiroot/extensions due to our build step. It is however a blocker since else people would be force to use the build step during development, which is silly. For testing purposes I've created this "extension" that you can include in LocalSettings.php as shown in the README file, and then run "composer install" in it to pull in Repo and Client. https://github.com/JeroenDeDauw/WikibaseBuild