Talk:Gerrit/New repositories/Requests

Previous discussion was archived at Talk:Gerrit/New repositories/Requests/Archive 1 on 19 January 2016.

Hi @QChrisNonWMF generated-data-platform/aqs/device_analytics is just fine thanks

Thanks for confirming!

 Done

Hi all (explicitely pinging @QChrisNonWMF since you process most requests on this page). Thoughts on removing the current table-based layout from this page and using "normal" wikitext sections instead? The requesting user experience would still be similar (or better, since you don't see the "click here to see your edit" page immediately after saving), but this would let us use DiscussionTools and similar tools on the page for replies and and make it clearer where to edit existing requests manually via the "edit section" links.

This whole table is on its way out anyways.

People are moving to our GitLab, where they can create the repos on their own.

So I'd probably not bother investing time in migrating the table (and doing the follow-up work?).

Much rather, let's invest time in making it easier for people to use GitLab and nuke this table as a whole :-)

But that said, if you want to invest the time ... I'm of course fine if editing becomes easier :-D

Repo has been created and code from GitHub has been imported

I (Eugene233) requested for creation of a repository on gerrit without mentioning that the repo can be import from github at

https://github.com/eugeneegbe/commons-recon-service. I just wish this could be seen an updated. On the other hand I would have to import the code again.

No problem. I've imported the code from GitHub and added the .gitreview file.

Because of Christmas time, QChris did not see a Phab ticket, where there was an ask for Gerrit help. QChris chimed in on the task.

Apologies @QChrisNonWMF and who is allowed to edit Gerrit groups.

I've added a small note here: phab:T269782#6710708.

(Spoiler: please rename our Gerrit group and please add me and some other members to it.)

Sorry. Christmas-time made me lag. I've chimed in on the task in Phabricator.

The code to import for the repo changed. But it's sorted out now.

@QChris (WMF), thank you for creating the research/mwaddlink repo. Would it be possible to import the history from https://github.com/dedcode/mwaddlink instead? Sorry for the confusion, no worries if it's a big ordeal to do.

Mhmm. I did import the code when creating the repo. But I overlooked to update the HEAD ref to main (it was on master). That should be fixed now.

@QChrisNonWMF sorry, to be more clear, I had original asked to import the history from https://github.com/martingerlach/mwaddlink-query but in the meantime, Martin merged that code into https://github.com/dedcode/mwaddlink.

So that repo (https://github.com/dedcode/mwaddlink) is the one with history to import to gerrit's research/mwaddlink repo. Is that still possible?

Oh! I see. Of course it's still possible to import a different repo. I've just imported the new repo. (Note though, that the default branch there is again master and not main.)

Declined. No community interest and no consensus with the current repository creators (mainly QChris). —MarcoAurelio (talk) 12:42, 7 August 2020 (UTC)

Good day. @Hashar suggested on IRC the other day to have a conversation about migrating the system to request new gerrit repositories to Phabricator. I see that work was done in that regard in the past but never saw light (and it's outdated, but can be updated real quick). Ideally this should all be in one place either keep it here at mediawiki or move it to Phabricator. Creating repos is something that is being done basically by @QChrisNonWMF so Hashar and myself agreed that we shouldn't do anything without consulting with him first as he does the vast majority of the repo creations. Regards.

Same as @QChrisNonWMF and @MarcoAurelio

I do not care too much whether we use MediaWiki or some other tool to track repo requests.

For me, using MediaWiki for them is not extra nice, but it more or less works, and it for sure is good enough™. We do not have 100s of repo requests/day or something. I guess no one likes it, but it's very, very, very seldom I hear complaints about using MediaWiki for it. (And Phabricator would not address these complaints either). And the signal-to-noise ration from the watching of the pages is really good for me :-)

At some point someone took an effort to bring these requests to bugzilla. That never took off.

After some time, it was tried to bring these requests to Phabricator (as MarcoAurelio said already). It never took off either.

I am all for switching to a different tool, if it solves a real-world problem. Not sure things like "Tables suck in MediaWiki" are real-world problems though, because if $SOMEONE cannot be bothered to copy/paste the previous table row and adjust it for their request, chances are $SOMEONE cannot be bothered to fill out a Phabricator form either.

So the question for me would be: Which real-world problem is solved by switching to Phabricator?

I feel the same as QChris above. We should stick to the place/system where requestors and people that create the repos feels more confortable working. If people think mediawiki.org is better suited for this, let's keep it here. If people think Phabricator would be a better place, let's move to there. I myself do not have a strong opinion and, like I said, I think the same as QChris above. In any case, requests should be all handled in one place (either here or at Phab.) for consistency. Thanks.

On the other hand, most Gerrit stuff has been moved to Phabricator: issues and project ownership requests, so I'd say I lean towards using that platform a bit, provided that Phab is a place where people is comfortable working and requesting things.

In https://phabricator.wikimedia.org/T238950#5685565 I wrote "(I'm also puzzled that https://www.mediawiki.org/wiki/Gerrit/New_repositories/Requests exists in parallel, but that's off-topic here.)" Confusingly, https://phabricator.wikimedia.org/project/profile/330/ states NOT to use Phabricator.

It would be georgeous to discuss and decide on one single place, instead of just opening more places in parallel (which seems like what happened here) to confuse people. (If it's too hard to make an educated decision then I'd propose that a person who opened the second place closes the second place. :P )

In phab:T259147#6365032 4 more items got were brought up by hashar:

> I have at least a couple use cases:
> 
> * have CI configured as soon as a repository is created. We do not actively monitor the mediawiki.org page and often catch new repositories after the fact. We have a Jenkins job comparing what is in Gerrit and what is configured in CI https://integration.wikimedia.org/ci/job/integration-config-qa/lastCompletedBuild/testReport/ .  Having a creation task flagged with #continuous-integration-config would flag the CI admins and should help having CI configured for them.
> 
> * when cleaning Gerrit from obsolete repositories (such as via #cleanup), it is often helpful to find whom/why a repository got created. That can be find in mediawiki.org though.
> 
> * Phabricator would make it easier to cc team/person to review a repository creation.
> 
> * The discussion seems easier to handle on Phabricator rather than on the Gerrit/New_repositories/Requests page.  But that is probably a bias on my side since I really dislike mediawiki notification system :]

They might be selling points for you, I'm not sure they are selling points for me.

Having CI configured as soon as the repo got created won't work. Most of the repos we create are empty, or have just a .gitreview file. There's not much to test there or do CI with. There's no PHP files, no tox. Sometime there isn't even a branch if requesters want a totally empty repo. Not sure there is a CI that does nothing is a benefit over no CI.

When it comes to finding how/why a repo got created, I find that quite convenient the way it is. For example a search on mediawiki for 'ArmchairGM' with a 'Page title contains' of 'Gerrit/New_repositories' gives a spot on result.

In Phabricator on the other side, I have a really hard time to find things, if I do not know the relevant tags/projects. And it's not easy to find the relevant tags/projects. But that might be a bias on my side, as I do not (yet) use Phabricator on a daily basis.

I'm not so sure CCing people is easier on wiki or Phabricator and whether discussion is easier here or there. I for one like that on the wiki pages, there is text. And less cruft about who subscribed and then unsubscribed a task and tokens and what not.

MediaWiki notifications have one huge benefit for me. They stick out. I get very few emails for MediaWiki. So when I do get one, I know I need to create a repo. But Phabricator spams me night and day about tasks that are not relevant for me. But that again might be a problem on my end.

That said, this thread started 1.5 years ago, and only 4 people (well ... 5 if you count hashar's comment on Phabricator that I copied over) chimed in. Not sure the pain or pressure to change things is enourmously big :-)

(OT tip: unwatch some Phabricator projects, unsubscribe from Phabricator not interesting Tasks and change your Phabricator email preferences :) eventually ask how to configure Herald to get just what you want, without getting everything.)

@QChrisNonWMF thanks for getting in touch about the proposed releng/mw repo. We don't have a more specific name for it, and while the current scope is wrapping around MediaWiki core's docker-compose stack, the project is deliberately open-ended so that it could also interact with e.g. the kubernetes based development environment in the future. So if it's OK to leave it as something vague for now and rename it later, that would be nice. cc @MModell (WMF) and @Jdforrester (WMF) in case they have any input on it.

I'd recommend calling it mediawiki/tools/cli or something similar.

that's fine with me.

mediawiki/tools/cli ist still rather generic, but meh. Let's run with that.

It's intended to be the CLI tool for all of MediaWiki. I think it's appropriate. :-)

FYI, I’ve filed T224676 to request the automatic creation of new repositories for Toolforge tool administrators. This would cover some of the requests currently being handled on this page, so I figured I should mention it here.