Page MenuHomePhabricator

PHP libraries as Gerrit top-level projects
Open, Stalled, MediumPublic

Description

Somehow it became a convention to split out tiny little snippets of PHP code from MediaWiki and make them top-level Gerrit projects. This seems like a really bad idea. Having a directory for PHP libraries would make them easier to find, and would make it possible for them to inherit permissions.

The following PHP libraries are top-level projects in Gerrit:

  • CLDRPluralRuleParser
  • IPSet
  • RelPath
  • RunningStat
  • WrappedString
  • at-ease
  • avro-php
  • base-convert
  • cdb
  • data-values
  • php-session-serializer
  • utfnormal
  • wikimedia/textcat

I suggest mediawiki/libs, by analogy with mediawiki/php and mediawiki/services, which are similarly products of the MediaWiki community which are not dependent on the MediaWiki core. JavaScript libraries like unicodejs could also go there.

I have heard that it is not easy to rename repositories in Gerrit. So we should make a container project as soon as possible, and put new libraries in it, so that the backlog for renaming does not continue to grow. We could also copy the affected repositories and make the old locations read-only.

Event Timeline

tstarling raised the priority of this task from to Needs Triage.
tstarling updated the task description. (Show Details)
tstarling added a project: Gerrit.
tstarling added subscribers: tstarling, demon.

In the Phabricator future, all repositories are flat anyway (there's no hierarchy), so finding related repositories is based on having them associated with a project that you can search from.

Re: top level projects in Gerrit though....permission inheritance is a non-issue as a repo can inherit from anything, not just what looks like the parent. The use of foo/bar/baz is just a convention for organization & grouping, which is a valid concern, but I'm not sure is worth the manual labor to rename 12 projects--which have denormalized references across a couple of database tables.

On T125031, @tstarling wrote:

Having a directory for PHP libraries would make them easier to find, [..]

Yeah, the discoverability and namespacing would be useful. We'll need to find a different way to group repositories in Phabricator.

On T125031, @tstarling wrote:

[..], and would make it possible for them to inherit permissions.

Re: top level projects in Gerrit though....permission inheritance is a non-issue as a repo can inherit from anything, [..]

Actually, I don't think all libraries should all have the same implicit ACL. Our libraries tend to follow FOSS conventions that most MediaWiki extensions don't: semantic versioning, independently runnable tests, documentation and coverage publishing, readme, sense of ownership from their maintainers.

This means maintainers can easily be aware of new patches (via built-in discoverable Gerrit search queries) and review these in a timely manner. While people sometimes follow this model socially in MediaWiki core, it's quite blurry. People feel much to comfortable adding "just this one thing" when they need it.

Short of having product managers for libraries - who decides the direction of any given library, what APIs it is supposed to have and how. Note that this is irrespective of whether the code has good quality, I think we can trust mediawiki/* to ensure good code quality. But having a list of project maintainers (enforced through Gerrit) seems desirable.

This, and other factors, is why some projects are or were using GitHub instead.

The libraries currently follow a viral ownership model. Maintainers can easily hand out permissions when they see fit. And as @demon mentions, we can (and do) already inherit (or include) mediawiki permissions for some libraries where it was felt appropiate.

I suggest mediawiki/libs

Sounds good. Though we'll need to make sure to update our repo-creation instructions for libraries to include a step that says to rename-over-redirect the mirror on GitHub, so that it is not named like this. This makes sure that the php-composer package is appropriately named (which are published via GitHub's web-hooks).

The somehow in how this happened was as I recall discussions on irc between @demon, @ori, and myself during the Librarization project. I can try to dig around an find some logs; I'm fairly certain those discussions would have been in the #mediawiki-core freenode channel.

My recollection is that we talked about putting the various libraries in a gerrit "folder" and then decided rather arbitrarily that there wasn't much point in doing so. Putting the "MediaWiki" brand on these libraries especially didn't seem to be necessary as they were explicitly being designed to allow usage outside of the MediaWiki ecosystem.

I don't have any strong feelings one way or the other about gerrit organization. If someone wants them renamed and can figure out how to make that happen its fine with me. Depending on the timeline for Gerrit to Diffusion+Differential migration that effort may have limited returns.

If someone wants them renamed and can figure out how to make that happen its fine with me. Depending on the timeline for Gerrit to Diffusion+Differential migration that effort may have limited returns.

The timeline is long enough that renaming them will happen far sooner than the migration. But at the same time, see what I said above:

I'm not sure is worth the manual labor to rename 12 projects--which have denormalized references across a couple of database tables.

It's a pain in the freaking butt...

I created the mediawiki/libs placeholder repository today, so new libraries can be created under it. The first one is mediawiki/libs/WaitConditionLoop :)

hashar triaged this task as Medium priority.Dec 3 2019, 9:59 AM
hashar updated the task description. (Show Details)
hashar changed the task status from Open to Stalled.Sep 6 2020, 10:14 PM
hashar subscribed.

I am strongly in favor of relying on namespaces in Gerrit for the repositories. Unfortunately that is stalled until we find out how to properly rename a repository in Gerrit: T239693: Support renaming repositories in Gerrit

I have finally added the Gerrit plugin to rename a repository. There are a few more things that would need to be adjusted though such as updating files in the repository (.git-review, composer.json), updating the URL used by packagist.org, renaming the mirrored project on GitHub etc.

I guess we can give it a try with a single repository at first?

I have finally added the Gerrit plugin to rename a repository. There are a few more things that would need to be adjusted though such as updating files in the repository (.git-review, composer.json), updating the URL used by packagist.org, renaming the mirrored project on GitHub etc.

I guess we can give it a try with a single repository at first?

Given the disruption, should we just move them to GitLab instead?