In D5213#132637, @KShivendu wrote:

In my opinion, the textual output doesn't print anything other than the directory structure so instead of removing the whole root path we can just put the directory name (it looks better).
[...]
But the ndjson output must be stripped.

In T3111#60314, @anlambert wrote:

Done ! Hopefully teachpress (WP plugin to display publications list) has a bibtex import that works like a charm.

Thanks, this fix looks good.

@vlorentz: can you have a look at this? it's related to the recent changes around the CoreSWHID class, maybe just a release of swh-scanner is missing

please keep the file sorted alphabetically

please keep the file sorted alphabetically

LGTM too. I've also tried it locally, and it worked just fine, both interactively and when running the test suite.

@KShivendu it sounds like you haven't installed the various swh-* modules with pip -e. Did you follow the developer setup tutorial? Steps in there should take care of that.

In D5107#128987, @vlorentz wrote:

@zack added to D5081: https://forge.softwareheritage.org/D5081?vs=18237&id=18239#toc

if that's fine with you, I'll do the same here

I've only added a nitpicky comment about docstrings.

Thanks for this summary/status, very useful. Regarding goals, I think we want to have a read goal also about time to first bite, which is a performance metric which is particularly bad in the current filesystem-based object storage. Not sure what would be a reasonable goal though. Poke @olasd: any idea about a good target for this?

I'm not approving it (and only resigning as reviewer instead) just to allow others to have a look, given it's something quite foundational in the data model.

followed sequence of:

Size of SHA256, SWHID, Content
SHA256
SWHID
Content

The object storage is a collection of RBD images containing a sequence of objects (SHA256 + SWHID + content).

(I've finally caught up with the backlog in this task, sorry I'm late to the party.)

(thanks for this!)

I'm requesting changes as the idea of hexlifying URLs behind the "swh:1:ori:" prefix is still being discussed (on the swh-devel list) and, for now, I'm against that specific part of the proposal.

Awesome!, thanks.

In T2912#58062, @rdicosmo wrote:

Thanks @vsellier, that seems quite ok indeed. The only question left is to know if the estimator implemented is monotonic (i.e. we will never have negative bumps in the graph :-))

In T3008#58039, @olasd wrote:

I've written a basic documentation page : https://wiki.softwareheritage.org/wiki/HedgeDoc

@zack, do you see anything else you would like to have documented?

for context: this change is only going to be committed in a separate branch that we're using for experiments with swh-scanner, hence the testing requirements are different/lower than for master

ah, yes, of course, sorry I didn't notice this either in the previous diff :-)

Why do we still have tests that check error messages meant for human consumption, again? :-)
If the difference in how they fail is meaningful (which I don't know), they should raise different exceptions and we should just check their types.

looks great, thanks !