In T3890#78234, @vlorentz wrote:

Looks like we are going to keep the status quo in the short term, ie. a numeric offset for old objects, and offset_bytes for new objects without renaming.

@douardda @olasd agreed?

Looks like we are going to keep the status quo in the short term, ie. a numeric offset for old objects, and offset_bytes for new objects without renaming.

I agree

I've thought of mentioning here a couple of issues that I've seen come up again over the past few days:

I suggested Co-Authored-By because it is a de-facto standard in Git now thanks to GitHub, so we already have many revisions using this "format" (no releases as far as I know, though).

Then let's just go for it (insert here ref. to upcoming separate task :-)).

In T3887#77951, @zack wrote:

Do you foresee any issue in adding extra_headers to releases as well, other than "someone should do it"?

In T3887#77949, @olasd wrote:

Now that I've written it out loud, of course, Releases don't have extra_headers so the package loaders can't make use of this workaround/hack for now.

Now that I've written it out loud, of course, Releases don't have extra_headers so the package loaders can't make use of this workaround/hack for now.

From merged tasks, this would also be useful for some package loaders, e.g. npm, that support multiple authors in their packaging metadata.

Practically, we could be storing the metadata on additional authors *now* in the extra_headers field (make them a bunch of (b'author', b'XXX <yyy@zzz.ttt>') entries). Of course, that doesn't solve the question of presenting the information.

And same goes for production [1].

Triggered the migration (using a transaction as the dataset is not that huge) and all
went well.

So script is ok and landed.
I'll trigger it on staging first.

wip script [1]

I'm growing fond of this idea.
That should take less time to refactor it now that we improved the lister scaffolding and
that we mostly know what the perimeter of the nixguix loader is.

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)

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)

Maybe another data point for the discussion is that the nixguix loader currently only
shows 1 origin for guix and 1 for nixos [well nixpkgs really} in the coverage part [1].
Which is somewhat true... but... feels weird at the same time.

Not saying no.

In T3134#75077, @anlambert wrote:

SWHID v2 should also prevent the hash collision issues we are currently facing (some related to the SHAttered attack on SHA1), see T3775 and SWH-LOADER-GIT-JT.

SWHID v2 should also prevent the hash collision issues we are currently facing (some related to the SHAttered attack on SHA1), see T3775 and SWH-LOADER-GIT-JT.

We don't care anymore, this will be handled by T3753.

We decided to store manifests instead. T3594#74385

We decided to store manifests instead. T3594#74385

We decided to store manifests instead. T3594#74385

Copy of an email I sent today:

Copy of an email I sent on 2021-11-17: