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.

In T125031#2435249, @demon wrote:

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.

In T125031#2435460, @bd808 wrote:

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 :)