Page MenuHomePhabricator

[Task] Move ValueView repository from github to gerrit
Closed, ResolvedPublic

Related Objects

Event Timeline

Lydia_Pintscher raised the priority of this task from to High.
Lydia_Pintscher updated the task description. (Show Details)
Lydia_Pintscher added a project: Wikidata.
Lydia_Pintscher moved this task to consider for next sprint on the Wikidata board.
Lydia_Pintscher subscribed.

@JanZerebecki we already have a gerrit repo https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/ValueView (created long ago but think this would work and is what we want)

But this is supposed to be a library/component, not an extension, right? So it's the wrong name. Renaming a gerrit repo is not something that is done. So lets directly use the correct name. I'll create request to delete the wrong name.

@JanZerebecki it is an extension. Do we want to change that? If/how does i18n stuff work in a library?

As I recently wrote in T75020#1629613:

Even if some component does not depend on MediaWiki, I'd still consider it a MediaWiki extension if it optionally provides MediaWiki integration. Currently, all our resource loading happens through ResourceLoader, and that won't change soon.

If/how does i18n stuff work in a library?

I don't know about how the JavaScript use the i18n json files. I assume translatewiki.net only cares about there being i18n files in a location in a git repo not about extension vs component.

As I recently wrote in T75020#1629613:

Even if some component does not depend on MediaWiki, I'd still consider it a MediaWiki extension if it optionally provides MediaWiki integration. Currently, all our resource loading happens through ResourceLoader, and that won't change soon.

If it is declared a Mediawiki extension or a composer component depends only on if we use composer to depend on it or if it is a submodule in the deployment branch of mediawiki/core. If we want our deployment being sane, we should only do one at the same time. Both have different technical consequences. Some features are currently only provided by one of them. (Now it is confusing that we currently use composer to make a build of extensions in Wikidata, in the long run we want to stop that.)

Regarding that we won't remove the ResouceLoader dependency soon: That might work in practice ok even as a component. The downside of that is that we need some custom CI glue to run the QUnit tests. That might possibly look like: add a composer depencency on data-values/value-view into an installation of Mediawiki, run composer, run qunit tests as is normally done with Mediawiki.

(Btw. breaking out ResourceLoader out of Mediawiki into a component that does not depend on Mediawiki, would be an alternative to removing the dependency on it.)

I requested to not create the repo until we decided. Another thing is how to name the repo if it should be a component: The composer name is data-values/value-view. Should we name it wikibase/data-values/value-view?

We talked about this in person. Outcome:
We don't want to miss the feature of dependency resolution with versioning. Extensions don't yet get that from Mediawiki.
In practice data-values/value-view will work as is in a possible future deployment where we have abandoned our Wikidata build and everything is in mediawiki/vendor.
So we go with it being a component.

I'll go with the name: data-values/value-view

There was a question during the repo creation process I now answered.

This is now moved, please don't change the repo on github.com yourself. I.e. creating a tag needs to happen through gerrit.

https://gerrit.wikimedia.org/r/#/c/243677/ needs to be merged for the CI to pass.

Creating a tag then works like this:
git tag TAGNAME master
git push gerrit tag TAGNAME

@JanZerebecki is there still something missing or can this be moved to done?

JanZerebecki moved this task from Review to Done on the Wikidata-Sprint-2015-09-29 board.