Yes please :-)

In T2619#49514, @olasd wrote:

More historical data:

• https://web.archive.org/web/*/https://archive.softwareheritage.org/api/1/stat/counters/ (live point data)
• https://web.archive.org/web/*/https://www.softwareheritage.org/stat-counters.json (cached copy of the counter on the website)
• https://web.archive.org/web/*/https://archive.softwareheritage.org/stat_counters/ (one year of counters at each scrape)

There is a full section on citation in the ICMS 2020 paper, see https://dx.doi.org/10.1007/978-3-030-52200-1_36
The conceptual framework (data model, representation etc.) discussed in https://gitlab.inria.fr/gt-sw-citation/bibtex-sw-entry/-/blob/master/README.md and the biblatex-software documentation in https://gitlab.inria.fr/gt-sw-citation/bibtex-sw-entry/-/blob/master/biblatex/software-biblatex.pdf are of general interest.

No objections on my side.

Thank you @samplet for sharing this great work: I am really looking forward to see you and @vlorentz compare notes and see whether we can archive the three extra files you produce as extrinsic metadata in the SWH archive!

Nice to see that this is becoming doable. I'm adding T2219 as a prerequisite to this task.

This is an important feature: it has been dormant for a while, but we need to actually start implementing it.

In T2344#43031, @moranegg wrote:

Great news !!

Does this mean we need to be SWORD 3 compatible?

This is now published in CTAN (biblatex-software)

I cannot reproduce this anymore either!
Closing this for now.

May be related to T2406

This seems to be related to T2465 too

Filtering is broken in the admin interface for deposits.

In T2430#45767, @zimoun wrote:

• if you still have that tarball at hand, then it can be ingested in SWH, and we keep the correspondence between SWHID and SHA256; in principle, you need to trust us, but one can foresee having external parties checking that the correspondence is real while the tarball is still there, and adding their observation to the chain of trust means you need to trust us less and less

By we keep the correspondence between SWHID and SHA256 you mean you on the SWH side?

In T2430#45764, @civodul wrote:

@rdicosmo The discussion of the "source of trust" is an important one, and it's interesting to see how we can address it going forward.

The proposal of a correspondence table, as I wrote on swh-devel, leaves open the question of today's and yesterday's software, assuming SWHIDs become the de facto standard tomorrow. How can I check the integrity of code fetched from SWH if all I have is its tarball's SHA256 from its release announcement? How can I check its authenticity if all I have is an OpenPGP signature computed over a tarball?

Clean and elegant, LGTM

It works!

The impression I get from playing with the interface is that at some moment the browser decides to "wrap" some of the components of the page in the source code view, that leads to the unwanted behaviour.
When we'll come to this, it might be interesting to compare with the behaviour of similar web front ends (GitHub, BitBucket, GitLab) that seem to handle this corner case seamlessly.

Better. but not yet there... if you play with Ctrl+ Ctrl- a bit you'll see that the source code pane still ends up having a size controlled by the central part of the top bar that show the path

Mailchimp is closed source (*sigh*) but is well accepted and has interesting features, so we'll not move away unless there are strong reasons.
Ack for the PDF way, as it seems the HTML one is too fragile/cumbersome.

In T2456#45525, @anlambert wrote:

For the record, the same kind of rendering is obtained when browsing Github and playing with the browser zoom.

After some other tests, it seems this mostly happens with Chrome: you can trigger the behaviour by playing with Ctrl + and Ctrl -
Firefox seems much more resilient.

To reproduce, enlarge the browser window: if the browser width is small enough, the source code pane wraps below and uses all the available space.
In my case, I'm using a full screen on a 2560 pixel display

In T2456#45520, @anlambert wrote:

Fortunately, this is already the case.

I can not reproduce locally. I think this is due to your browser cache.

Is refreshing the page with Ctrl+F5 fixes the display ?

In T2451#45441, @anlambert wrote:

A bare bone process may be something like this:

• every time a newsletter is sent Marla does the following
  • get the HTML of the newsletter from Mailchimp
  • use it to create a new page on the SWH website
  • add a link to this new page at the bottom of the newsletter page on SWH (in all three languages)

This way the subscription page is also the archive page and may attract more traffic.

Any comments/improvements on this?

This sounds quite complicated and cumbersome to do ... We need a process that requires less copy / paste operations.

Possible solutions are:

• We create the newsletter for each supported languages and send it directly from WordPress through the Newsletter plugin.

• We keep using mailchimp to create the newsletter and print each mail to a PDF file. This works really well when using Chromium browser, see
  Welcome to the Software Heritage Newsletter!.pdf3 MBDownload
  as an example. Apart the top mailchimp bar to remove, the PDF rendering looks great. We can then upload the PDF to our main site and offers a link to it in the Newsletter page. This way the only thing to maintain will be an archive table in the Newsletter page containing link to pdf files.

In T2451#45438, @anlambert wrote:

Just follow these instructions and copy / paste the HTML code at the bottom of the Newsletter page.

Le mar. 9 juin 2020 à 16:18, anlambert (Antoine Lambert) <
forge@softwareheritage.org> a écrit :

Is there a way to improve the regex in https://github.com/inveniosoftware/idutils/pull/60 to allow qualifiers to come in any order instead of the canonical one?

An important issue indeed :-)

A quick comment on the code above: it seems to depend on the use of sha1_git parameters passed in the urls used for browsing.
While this is perfectly ok for today, we need a way to be future proof, when different versions of SWHIDs will come in, using different hashing algorithms.
Since we commit to maintain forever the resolution of previous versions of identifiers, the navigation in the webapp will need to be able to accomodate multiple hashing algorithm at the same time, and we need to plan to structure the code accordingly.

Adding a last comment after a last reread

We decided to answer IPOL's question in a conservative way, by using the current metadata.xml approach, without introducing roles for authors, nor the JSON-LD format.

I removed the following sentence, that will be confusing for Jose Luis (and btw, here the external library is included so it is technically not a sparse deposit either :-))

This might be a good example for the sparse deposit use case (even if in this specific case, the deposit will include the libraries).

In D3162#76908, @ardumont wrote:

Adapt implementation according to review

In D3154#76897, @vlorentz wrote:

I applied most of your comments,

Great!

except:

For the snapshot key in the dictionary, use the snapshot core SWHID, not the visit integer (that is an internal implementation detail)

because I don't understand it.

Notice also that if/when we introduce new versions of SWHIDs with other
hashing algorithms, we need to maintain backward compatibility.
Metadata introduced with a given context must not be "migrated" to the new
SWHIDs, but "duplicated" for the new SWHIDs.
Better think right now of a schema that allows to "share" metadata payloads
among multiple versions of SWHIDs without actually copying them over.

Great, thanks. Dont think you need a test on a function as basic as this :-)

It would be better to make the code robust w.r.t. future potential changes in qualifier order.
Suggested pseudo-code attached (to be checked :-))

Thanks for sharing this: we're definitely going forward!
Comments are in the text, but overall:

• agree that we need a way to store and retrieve metadata that is contextless (or... valid in all contexts)
• for the context, we need to use the SHWIDs themselves, not the sha1_git that is bound to version 1 of SWHIDS

I would say go... HAL identifiers may be updated (not a big deal for them to update them) or may not be updated, but as you say they will be resolvable, so better have a uniform status of all deposits.

I agree: the links in the current UI presentation are sometimes confusing.
We need to think this a bit over to get all the functionalities we want into a clean UI:

A generic way to address this feature is by adding "exclusion" criteria to the existing "inclusion" criteria.

Indeed! Getting the swh:rev and swh:snp for the swh:dir for the deposit
should not be that complicated navigating the Merkle tree upwards, though,
as we expect little deduplication there, but we'll need to see..

• Do we migrate the old deposit values to the new ones? (sounds reasonable to do so)

Once this is ready, check with HAL that everything works in software deposits (see https://gitlab.ccsd.cnrs.fr/ccsd/hal/-/issues/264)

Is this task still open? Likewise for T1711 T1712 and T1872

Is this now done? If that's the case this ticked should be closed.

Now that we have access to CCSD's gitlab, this issue must move there.

@ardumont , @moranegg : may you check that everything is now ok? We should close this task it that's the case :-)

Thanks for diving into this.