https://docs.softwareheritage.org/devel/contributing/tutorial-docs-contribution.html#doc-contribution

Complete proposal for the above solution:

Complete proposal to implement the above solution:

Possible solution: store them as an ascii string instead of an integer.

Possible solution: store a rank along with each directory entry, but ignore it unless we are reconstructing a git object or computing a SWHID (v1?)

In T1805#70880, @douardda wrote:

• pagination comes from proper usage of links https://swagger.io/docs/specification/links/
• batches comes from proper usage of parameter serialization https://swagger.io/docs/specification/serialization/

it's true these do not come "for free" but I still have the impression there is an "Open API way" of handling these and we should stick to them.

In T1805#45984, @vlorentz wrote:

Items 5, 6, 7 aka pagination, auth and batches - I believe these come naturally with item 4 (specification wise)

They don't. OpenAPI is a specification to describe APIs, and it contains absolutely nothing about pagination or batches.

The computation of those metrics will be executed in production on a regular basis, probably each day, to keep them up to date.

Improve the readability of the graphs

In T3127#67581, @anlambert wrote:

    I am a bit puzzled by the numbers shown: eeally we have only 200k origins for GitLab.com.?

Indeed there is something weird here as we have more than one million gitlab.com origins in database.

softwareheritage=> select count(*) from origin where url like 'https://gitlab.com/%';
  count  
---------
 1023499
(1 row)

Looks like something was missed when computing lister metrics from scheduler database, this needs further investigations.

Indeed, please do look into this, thanks.

Thanks for these details: this count is missing the 800k git origins: @ardumont and @olasd should be able to tell you how to find them

In T3127#67581, @anlambert wrote:

I am a bit puzzled by the numbers shown: eeally we have only 200k origins for GitLab.com.?

Indeed there is something weird here as we have more than one million gitlab.com origins in database.

softwareheritage=> select count(*) from origin where url like 'https://gitlab.com/%';
  count  
---------
 1023499
(1 row)

Looks like something was missed when computing lister metrics from scheduler database, this needs further investigations.

I am a bit puzzled by the numbers shown: eeally we have only 200k origins for GitLab.com.?

I am a bit puzzled by the numbers shown: eeally we have only 200k origins for GitLab.com.?
And we know we had some 1.5m origins for Google code, why only 700k shown here?

Instead, we could split the coverage widget into two tabs

• one giving a high level overview of the archived origins, similar to what we have now with logos and counters
• one giving the details of all forges we archived so far, displayed in a table as you suggested with relevant metrics and links to search origins for a given forge

I think we could also get an accurate count of deposit origins (HAL, IPOL) using swh-deposit API

Only one nit about the display. Using modal windows/popover will mean that there will be no easy way to have, as a user, the full list: one will have to click on each logo one by one, which could be quite annoying. Would it be possible to have a page with a rendering of the table above? (not sure if we want all columns, but at least the last update time and the number of origins per forge instance looks relevant and interesting to me). It coule be either in addition of what you propose (e.g., as a "coverage details" link, leading to the full page), or as a replacement of it (e.g., by making each forge icon just a link to the relevant anchor within the table on the "coverage details" page).

Thanks for this update, great work!

Some reports of what have been done so far and some future directions regarding the display of those data in swh-web.