improve comment as suggested by ardumont

Add the cli option to configure this concurrency value

fine for me (but plz give a bit more insight)

I guess this is then related to T3653 somehow

move the code in get_journal_client

make the warning an exception, as suggested by vlorentz

In D6875#178755, @olasd wrote:

statsd.timing/statsd.timed do full histograms. Do we really want to keep bucketed counts for all of these values, or just a running total?

Gawd this is horrible! (not your fault!)

I'd feel more comfortable also if we have a good (aka documented and understood) reason for doing this.

vlorentz' comment + update copyright timestamps

closed by 259bf6fe1e3bacbcd2e91f8f3d55d49f5219892c

In T3134#76032, @vlorentz wrote:

wishlist: it would be nice ot be able to check the whole hash of a revision/release even when the author name/email are replaced by a hash. (eg. by making SWHIDv2 a tree hash)

I guess https://grafana.softwareheritage.org/d/d3l2oqXWz/s3-object-copy?orgId=1 is almost an answer to this task

LGTM (but see my comment)

Same comment as in D6712

It would really nice to have a better explanation of what this flag is added for and why. Why do we add complexity in the code for this? I know there are good reasons for that, but I cannot see them just reading the code or the commit message.

There is a small typo in the commit message (adn instead of and)

probably won't be used

rebase

rebase

typo and small improvement in the test

In D6692#174126, @olasd wrote:

You seem to have dropped the CONTENT_BYTES_METRIC ?

Rebase on D6724 and adapt statsd tests to match new statsd probes

Add tests for expected statsd reports during a content replay session

Add a docstring in statsd fixture and update copyright dates in pytest_plugin.py

fix and swap args of 'assert' statements

In D6692#174129, @olasd wrote:

Could you make sure that this dashboard https://grafana.softwareheritage.org/d/d3l2oqXWz/s3-object-copy?orgId=1 is not affected (or that its functionality can be replaced easily?)

In D6692#174126, @olasd wrote:

You seem to have dropped the CONTENT_BYTES_METRIC ?

sorry I thought I had accepted it already :-)

In D6697#174282, @aeviso wrote:

When I did so with other tests your claim was that they were too difficult to follow and that tests should be as explicit as possible. These ones have a declarative function name for each case. What's the criteria after all?

Fine for me; these tests could be written as parametrized tests (https://docs.pytest.org/en/6.2.x/parametrize.html#parametrize-basics) but not a big deal.

Looks overall ok to me, but I miss a few "why?" here:

• the "why stop writing this file" should be in the commit message,
• why the need for SortOutputHandler attributes to become final?