https://www.mediawiki.org/wiki/Upstream_projects#Components and below would be useful.

Instead of asking Bitergia to add this repo and remove that other repo, we would need a way to manage this ourselves. It cannot be that difficult...

According to the work done in T104845: Automated generation of (Gerrit) repositories for Korma, I've updated the list of Gerrit repositories. I didn't find some of the ones listed there, but this may be a good way to start working on this list. You can see the differences at [1].

In addition to this, should we keep that list in the Bitergia-GitHub account? or should this be part of the korma repo at some place? In any case this should the central point to work with the list of repos.

[1] https://github.com/Bitergia/mediawiki-repositories/commit/9a3c55614a09b8ec1d4424b1b82481a631d55a0b

Varnish doesn't appear at https://github.com/Bitergia/mediawiki-repositories/blob/master/gerrit_projects.conf anymore, but is still scoring 5th in http://korma.wmflabs.org/browser/gerrit_review_queue.html. Is gerrit_projects.conf already defining the list of projects that korma should feature or not yet.

As agreed in our meeting some weeks ago, let's keep that list in the Bitergia-GitHub account for now.

In T103984#1570832, @Qgil wrote:

Varnish [...] is still scoring 5th in gerrit_review_queue.html

Varnish not listed anymore. After testing a few items on the first 3 pages this looks good so far.

After closing some of the tasks related to automation of the gerrit-retrieval repositories, I'll try to detail how we all should modify trackers to be added or removed to Korma.

Let's focus only on Gerrit, what will help to divide the problem.

At https://github.com/Bitergia/mediawiki-repositories, there's a list of files. There are indeed two files with Gerrit information:

• gerrit_trackers.conf
• gerrit_trackers_blacklist.conf

The first of them contains information directly retrieved from Gerrit. This was retrieved using a command similar to: "ssh -l <user> -p 29418 gerrit.wikimedia.org gerrit ls-projects"
This information at some point should be automatically updated at the Git repository and should never be updated by any of us.

Regarding to the second file, this file lists all of the trackers found in the first file that shouldn't be part of the analysis. In other words: this is the list of projects to ignore during the analysis.

So, we all expect to update the 'blacklist' files.

With respect to the internal machinery, the process is as follows:

• The list of gerrit projects is retrieved each day.
• If there were changes in such file, a new version of the gerrit_trackers.conf would be uploaded to the Git repo.
• A resultant list of projects to analyze is calculated as gerrit_trackers minus those found in gerrit_trackers_blacklist.
  • If a new project was added to the blacklist, this would be removed from the database.
• In addition to this, if a project was removed from the gerrit list, the machinery would detect such change and this project would be also removed from the database.

@Qgil, as you commented in another ticket, ExternalArticles should be part of the blacklist, although I have to add this.

Thank you! I have documented this at https://www.mediawiki.org/wiki/Community_metrics#Code_review. Please review.

@Qgil, thank you for the documentation :).

I'll close this task and the blocking one as we finished the development. The process for Gerrit should be fully automated, this is a matter of updating the blacklist file to fit this with your requirements.