Can you clarify the scope of this task?

I don't understand which entries should be updated/dropped from its description.

Also, it's a wiki, can't we just fix the entries? :-)

I suggested this task instead of editing because I wasn't sure about item no° 3 (Debian).
And I didn't know if entries should be dropped or do we want to keep all items in the list and have a checkbox when we get to them.

Also, there where coverage updates recently visible with T1251 and I thought that the suggestion box might be affected with the changes.

I can mark this task invalid though.

My point was just that you didn't list here the entries that you think have to be updated, so it wasn't actionable.
It would be great if you can update the task description with all the entries that you think deserve an update (even if you've doubts about them).

Debian derivatives (that is, distributions that are forks of Debian, not Debian itself) are not being archived.

Automating the addition of distributions from the Debian derivatives census to Software Heritage would probably be a good topic for an internship, e.g. a Google Summer of Code/Outreachy project.

In T1262#23681, @olasd wrote:

Automating the addition of distributions from the Debian derivatives census to Software Heritage would probably be a good topic for an internship, e.g. a Google Summer of Code/Outreachy project.

That's a very good idea, which I'll be happy to draft as a proper internship proposal. Before doing so, however, can you confirm that, scheduling wise, tracking something like ~100 additional derivatives wouldn't be a problem for us in terms of load?

In T1262#23695, @zack wrote:

That's a very good idea, which I'll be happy to draft as a proper internship proposal. Before doing so, however, can you confirm that, scheduling wise, tracking something like ~100 additional derivatives wouldn't be a problem for us in terms of load?

I replied f2f, but no, I don't expect that would be a problem. We may have to implement cleanup of leftover data in the lister/loader Debian internal database.

If polling of this many origins becomes a problem, we can poll these origins less often than we poll Debian itself as well.

the internship topic on this is now available here: https://wiki.softwareheritage.org/wiki/Ingest_all_Debian_derivatives_(internship)