LGTM. (Still waiting on @moranegg for the deposit URL example.)

in 288055f74683ae517770dc2f5a17a8b4bdaeff03 i've added a (Python!) script to check for CONTRIBUTORS completeness

Looks great ! I've noted down a bunch of requested changes, but they really only about style. Nothing that will get in the way of actually implementing any of this.

Thanks for this updated version, we're definitely refining various use cases here.

looks great !

I second the need of properly defining terms related to push archival.

minor caseness issue

Almost there !
(and thanks a lot for your persistence on this one)

LGTM.

Thanks a lot for this recap Morane !

There are two separate use cases here, so I'll comment on them separately:

Thanks for your interest in working on this @nahimilega , it would be very useful to move forward on a bunch of pending ingestions, including Tor !

resolved (by T691)

In T691#33551, @olasd wrote:

After processing the logs of the backfilling process to make sure to redo all the ranges that were interrupted in various database migrations, I'm now confident that this task is complete: we have a full mirror of all contents on Azure, which is kept up to date by the main archive storage backend writing synchronously to it.

Getting rid of ReCaptcha for save code now LGTM too.
I just wasn't sure that rate limit applies to Web UI submissions (e.g., will API requests come from our own IP? and if so, is that whitelisted?); I'm assuming that is what @anlambert plans to check.

In T1789#33370, @sandipbhuyan wrote:

Can we have the feature which will return the content of File Type, Language Type, and License not its URL

Hi @sandipbhuyan , I had in fact already created a task for this, it's: T1789

btw, the list is ~400 repos for now

@anarcat please hold off from using save code now for now. As we're planning to have a proper cgit lister, we can just add your instance to your rotation once that's done (unless this is super urgent, that is). That will have the additional advantage that we will automatically notice when new repos show up.

It's not really related, because gitweb and cgit are two different things.

Thanks @olasd, @ardumont, and @anlambert for this, it's a great plan and I like it a lot !

Thanks @vlorentz for this first draft. In spite of all the comments above, I think it's a very good start.

The most recent update of the state of this task has shown a regression in the journal test coverage, which, per se, is not a big deal (just a few points). But it does raise the question of how, once we have attained whatever "minimum" coverage we are OK with, we monitor overtime that there is no regression. For instance, I think that code reviews should show to the reviewers how the submitted diff affects code coverage. Ideally, reviewers should be able to so if it has a net positive or negative effect on coverage, and take that into account in their review decisions. (Which is not to say we should never accept diffs that decrease code coverage—there might be reasons to do so. But it is a data point that would be useful for reviewers to see.)