@Negative24 started Template:Phab_file, once we get it working well enough it can become the new Template:Git_file on mediawiki.org and wikitech. It looks doable, just hundreds of lines in a {{#switch: {{{project}}} | ... }} ParserFunction to map project= paths to diffusion callsigns.

In T101358#1336478, @Spage wrote:

It looks doable, just hundreds thousands of lines in a {{#switch: {{{project}}} | ... }} ParserFunction to map project= paths to diffusion callsigns.

ftfy

Because we have

{P726, lines=15}
...
(obviously)

In T101358#1336478, @Spage wrote:

@Negative24 started Template:Phab_file, once we get it working well enough it can become the new Template:Git_file on mediawiki.org and wikitech. It looks doable, just hundreds of lines in a {{#switch: {{{project}}} | ... }} ParserFunction to map project= paths to diffusion callsigns.

#switch is a terrible idea to store such map:

• it is going through the Parser and its is quite slow
• its going to be a pain in the ass to keep up-to-date
• LUA module!!!

The Gerrit project name and Diffusion names do not match and are inconsistent (the last created project names in Diffusion have / as separator whereas it was a dash previously). Might have an impact as well.

What about having the Phabfile template to use the callsign? It is more or less meant to be an immutable human friendly ID and saves the crazy #switch.

So instead of:

{{phab file |project=mediawiki/extensions/Flow |file=composer.json }}

Do:

{{phab file |callsign=EFLW |file=composer.json }}

And the lookup map is gone.

Can we instead please teach diffusion to lookup repositories by name?

In T101358#1337239, @JanZerebecki wrote:

Can we instead please teach diffusion to lookup repositories by name?

I'd like that too, but two caveats:

1. Old Gerrit names don't have an easy way to tell the corresponding Phab name...repo names are far more flexible.
2. People can change their repo name in Phab (see #1), whereas callsigns are set in stone.

So I think having a way to find a repo based on repo name is nice, but can't be relied on 100% of the time. Getting things to speak callsigns makes that problem go away.

In T101358#1336865, @hashar wrote:

What about having the Phabfile template to use the callsign? It is more or less meant to be an immutable human friendly ID and saves the crazy #switch.

Callsigns are Phabricator-specific and must die.

Getting things to speak callsigns

What things? Callsigns are not meant to be usable or used. Deprecating the "project" parameter of https://www.mediawiki.org/wiki/Template:Git_file would invalidate thousands of usages, it's way better (albeit still horrible) to have the template do the conversion.

(And yes, eventually as Ricordisamoa says Phabricator is supposed to become sane and get rid of callsigns.)

If we stored the mapping in phabricator then a bit of custom code could look up the phabricator callsign based on the gerrit project. We did something sorta similar for redirecting bugzilla urls to phabricator urls. We'd have to store the mapping _somewhere_ though and I don't know where exactly to put it. Also, over 9000 repositories.

In T101358#1338106, @mmodell wrote:

If we stored the mapping in phabricator then a bit of custom code could look up the phabricator callsign based on the gerrit project. We did something sorta similar for redirecting bugzilla urls to phabricator urls. We'd have to store the mapping _somewhere_ though and I don't know where exactly to put it. Also, over 9000 repositories.

I was thinking of doing something along those lines. But remember, it'll only be for historical repos coming from Gerrit (of which we have 1320, lol). Since we have the upstream URLs already at repo creation time, it's easy to infer the repo name from there and store it. Then building redirector on top of that is super easy.

@demon: so we could make a url mapping in phabricator that was essentially https://phabricator.wikimedia.org/r/old/gerrit/path and route that to diffusion, then the wiki parser function could just replace gerrit.wikimedia.org/ with phabricator.wikimedia.org/ and be done with it.

In T101358#1338071, @Ricordisamoa wrote:

In T101358#1336865, @hashar wrote:

What about having the Phabfile template to use the callsign? It is more or less meant to be an immutable human friendly ID and saves the crazy #switch.

Callsigns are Phabricator-specific and must die.

Immutable repo names are Gerrit specific and must die.

Seriously, repos have to have a way to be referred to that is immutable. Phab uses callsigns for this, not the repo name (which is more Github-esque, you can always rename a repo if the project changes). If we had been using callsigns all this time and were talking about changing to Gerrit, we'd be having the same argument in reverse.

As long as we have the proper tooling around redirecting old repo usages to the new ones, I fail to see the problem.

In T101358#1338077, @Nemo_bis wrote:

Getting things to speak callsigns

What things? Callsigns are not meant to be usable or used.

{{cn}} on not being usable or used.

Deprecating the "project" parameter of https://www.mediawiki.org/wiki/Template:Git_file would invalidate thousands of usages, it's way better (albeit still horrible) to have the template do the conversion.

I don't really care where the links get fixed, as long as they eventually end up in the right place (Diffusion). If we have them go through a redirection, that's cool, we need the redirection for Gitblit deprecation anyway.

(And yes, eventually as Ricordisamoa says Phabricator is supposed to become sane and get rid of callsigns.)

AIUI, they're going to be optional. For migration an existing system to Phabricator we'd still need them as we require a sane way to know a 1:1 mapping from old repo to new repo (and since repo names can change....)

In T101358#1338121, @mmodell wrote:

@demon: so we could make a url mapping in phabricator that was essentially https://phabricator.wikimedia.org/r/old/gerrit/path and route that to diffusion, then the wiki parser function could just replace gerrit.wikimedia.org/ with phabricator.wikimedia.org/ and be done with it.

Something like that yeah. We'd need the same ability for deprecating Gitblit too.

{{cn}} on not being usable or used.

There was a wide consensus on http://markmail.org/message/jtdipertspvwdgpd

In T101358#1338204, @Nemo_bis wrote:

{{cn}} on not being usable or used.

There was a wide consensus on http://markmail.org/message/jtdipertspvwdgpd

Ok, on the usable bit. They are very much used.

The alternative to callsigns in phabricator will be to use an integer. R1, R2, ... R9001 see https://secure.phabricator.com/T4245#53345

In T101358#1336865, @hashar wrote:

What about having the Phabfile template to use the callsign?

Could do. I assume it's possible to use a bot to go through the ~1600 pages on mw.org (most of which are translations) to update {{git file}}.

If we maintain a mapping, then it should be output by a Lua module. Some other templates and bots will need it.

The key issue is what's the most "correct" and future-proof way to specify a repo for {{git file}}:

1. project=mediawiki/extensions/Flow (current, a gerrit path)
2. callsign=EFLW
3. name=extension-Flow (the diffusion name in https://phabricator.wikimedia.org/diffusion/query/all/)

I don't know enough about diffusion and arcanist (but I'll blabber anyway :) )

(2) is obviously Phabricator-specific, but note (1) is not simply the project's git repo name, it's path/to/reponame. If and when we transition to arcanist and diffusion, will there still be a canonical path/to for each project, and where will it be shown? As hashar noted

The Gerrit project name and Diffusion names do not match and are inconsistent

In some cases you need to clone a repo in a certain directory structure (e.g. extensions/Flow or the old integration/jenkins/jjb/zuul ). But if the path/to in project= is arbitrary then it'll force people to invent arbitrary project path names that we have to add to a 1276-line mapping file, that others trying to make a {{git file}} link won't know.

So maybe (3) name=diffusion-name is the future, a loose mapping. Can you use that in a link to a git file, or will we have to maintain a mapping extension-Flow -> EFLW for it?

Ultimately everything is a naming problem :)

What do you propose instead?

Your suggested syntax {{phab file |callsign=EFLW |file=composer.json }} is unwanted.

I have added the point to the Release-Engineering-Team weekly meeting agenda for August 25th.

We can generate the callsign mapping in phabricator. One option that @demon and I came up with is to offer a static url, something like https://phabricator.wikimedia.org/r/mediawiki/extensions/Flow which would simply redirect to https://phabricator.wikimedia.org/diffusion/EFLW

This way the mapping to callsigns is maintained in the repository configuration within phabricator and there wouldn't be a maintenance issue. Also this way existing templates would continue to work with minimal modification.

In T101358#1582108, @mmodell wrote:

We can generate the callsign mapping in phabricator. One option that @demon and I came up with is to offer a static url, something like https://phabricator.wikimedia.org/r/mediawiki/extensions/Flow which would simply redirect to https://phabricator.wikimedia.org/diffusion/EFLW

I created T110607: redirect gerrit repo paths to diffusion callsigns. Great, so project=path/in/gerrit/to/reponame will continue as the way we specify a repo in templates. I think a project path makes sense, at least until we no longer use gerrit.

{{git file}} is already using Diffusion, all the callsigns were updated in D139: Full dump of all existing callsign to repository mappings. What's left?

Then someone can copy over all the callsigns :)