Page MenuHomePhabricator

Move Wikibase components from GitHub to Gerrit
Closed, DuplicatePublic

Description

The review-rate on GitHub is almost non-existent. Apparently nobody even notices there are patches waiting for review. I currently have 69 (!) patches on GitHub waiting for review, see https://github.com/search?q=is:pr+is:open+author:thiemowmde. Most of them so small that it should take minutes to review and merge them, but some are just sitting there for weeks and months. This is getting frustrating. Linking these patches to Phabricator tickets barely helps. Sometimes it just doesn't make any sense to create a ticket for a patch that's so small that it's basically a no-brainer. In other cases where I link patches to tickets they don't get reviewed either.

The only final solution I see: Move everything to Gerrit so I can add people for review. This is not possible at all on GitHub and I consider this the main reason why GutHub is just bad for what we are trying to do in a team.

Intermediate solution: Merge all DataValue components into a single one. The way this component is split doesn't make much sense anyway. Some interfaces are in the "Interface" component, but others are in "Common". Some data values do have their own component, e.g. Time and Geo, but others are bundled in "Common". Why? Also see T92268.

Event Timeline

thiemowmde raised the priority of this task from to Needs Triage.
thiemowmde updated the task description. (Show Details)
thiemowmde added projects: Wikidata, DataValues.
thiemowmde added a subscriber: thiemowmde.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 10 2015, 3:23 PM
Aklapper added a subscriber: Qgil.Mar 10 2015, 3:25 PM

T74907

All in for merging DataValues repositories. However, there should be generic parsers for more complex data structures like Time. I could imagine such residing on GitHub as the potential of motivating other developers to contribute is probably higher over there. Such components should be generic enough to allow immediate re-use though.

Looking at the DataValues components, I'm not seeing any big issues with how they are split. Some of them contain crappy code, and others have boundary problems. The general organization seems fine though. If there are concrete problems with the components design, I'd like to hear them. I'd also like you to think about the implications of putting them all into a single component.

I consider code being scattered around an issue. Trying to work with these components gets messy fast, see T92268.

Having all DataValues in one repository introduces only one issue, as far as I can see, and that doesn't even really qualify as an "issue": If a user doesn't care about, for example, QuantityValue, he will have some unused files in his repository. But how is that an issue?

On the other hand: It's not possible to use NumberValue without QuantityValue because they are in the same repository anyway. It's not possible to not use BooleanValue because it's in one of the base components. And there are 3 or 4 of these base components, I lost track. Time related stuff is still scattered around a lot, mostly in Wikibase\Lib. There is a component called "common", but it only contains Mono- and MultilingualTextValues. "common" also contains parsers, e.g. a BoolParser, while the BooleanValue is in a component called "data-values". That "data-values" component also contains some interfaces, while there is a separate component called "interfaces". StringValue is in "data-values", StringFormatter and StringValueParser in "common" and a StringValidator in an other component called "validators".

What's "validators"? What's "common"? What's the difference between "common" and "data-values"? Is "data-values" not common? What's the difference between "common" interfaces and "interfaces" interfaces?

TL;DR: It's a mess and needs cleanup anyway.