WMDE-leszek added a comment.
@demon commented on this in https://phabricator.wikimedia.org/T174922#3578222:
Submodules do not cause problems with CI or deployments--we do those all the time.
So it looks we're good :)TASK DETAILhttps://phabricator.wikimedia.org/T174922EMAIL
aude added a comment.
we should check with @demon if git submodules will be okay with CI / deployment. While I think they might work, I vaguely remember there being some issue with having them in extensions with the deployment toolsTASK DETAILhttps://phabricator.wikimedia.org/T174922EMAIL
WMDE-leszek added a comment.
So we've decided to go with option 3 over the option 5 to avoid the issues @JeroenDeDauw mentioned. There are some reservations in the Wikidata team at WMDE regarding the use of git submodules, so in case we hit any issues, we're going to fallback to the option 5.
WMDE-leszek added a comment.
Just got back from some days off and regarding what @Krinkle said in his last comment: I completely agree those libs should not depend on MW, and should take care of running their tests themselves not relying on MW's QUnit runner, no matter how they're included in the
Krinkle added a comment.
In T174922#3583384, @WMDE-leszek wrote:
One concern with the Option 5 I could imagine is that the separation between those libs and the "core" Wikibase is drawn less strict than e.g. when those libs are only pulled in when "building" Wikibase & co (option 4), or when
JeroenDeDauw added a comment.
If you add this code to the Wikivase.git repository you likely make it even harder to split that repository into clean well-defined parts. Suppose you want to put the client and repository extensions in their own git repository, then you'll also need to deal with
Addshore added a comment.
Marking as high as this is the one undecided thing blocking the killing of the build right now (which itself is high prio)TASK DETAILhttps://phabricator.wikimedia.org/T174922EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc:
Legoktm added a comment.
I like Krinkle's idea the most (option #5) for now, mostly because it's probably the easiest, and seems relatively straightforward to move away from in the future.
Full preference list: 5, 3, 2, 4, 1.
In T174922#3583384, @WMDE-leszek wrote:
One concern with the Option 5
WMDE-leszek added a comment.
Thanks @Krinkle for pointing this out. This indeed is a reasonable option to consider. Added to the task description.
One concern with the Option 5 I could imagine is that the separation between those libs and the "core" Wikibase is drawn less strict than e.g. when
Addshore added a comment.
In T174922#3578222, @demon wrote:
Option #3 seems easiest to me from my armchair. Submodules do not cause problems with CI or deployments--we do those all the time. The submodule update commit can--theoretically--be avoided by auto-updating submodules in Gerrit, but this
Krinkle added a comment.
Move all those libraries to Wikibase git repository
pro: dependency problem goes away
con: code provided by those libs is no longer versioned as now - all only work with current Wikibase master
con: even more code in Wikibase.git
con: no way for those libs to by used by
demon added a comment.
Option #3 seems easiest to me from my armchair. Submodules do not cause problems with CI or deployments--we do those all the time. The submodule update commit can--theoretically--be avoided by auto-updating submodules in Gerrit, but this may or may not work for our use case
12 matches
Mail list logo
