Thanks for the investigation @olasd.

In D1460#32446, @seirl wrote:

Would this be another use case of the node type relationship graph? Or rather, its transitive closure (and the transitive closure of its transposition for the "backwards" case)? It would allow us to express that /release/revision?direction=forwards is doable, but /release/snapshot?direction=forwards isn't, and throw the appropriate errors.

Oh, BTW, we should look at GraphQL for inspiration for this API. I'm not entirely sure it's worth it/useful for visits, but we should at least check.

Good first iteration! I've proposed various ways to make this more general, and I'm very open to discuss them.

This is now done, aside from a minor issue noted below:

softwareheritage-indexer=# select count(*) from revision_intrinsic_metadata where metadata = '{"@context": "https://doi.org/10.5063/schema/codemeta-2.0"}'::jsonb;
 count 
-------
     0
(1 row)

I don't think it's a good idea to move specs from the specific components they specify to a different repository (swh-docs), because that will just increase the chances (which are already quite high) that they will get out of sync.

In D1430#31493, @anlambert wrote:

I knew about the manual landing from us but I am not a big fan of all this noise added to the commit message by arc.
Based on my understanding, if the original commit author is able to push after we accept a diff, this noise will not
be present. Anyway, that's not a blocker to integrate changes so I will also proceed like this in the future.

In D1430#31490, @anlambert wrote:

Third: everyone else: once a change is accepted, you can land it yourself by doing first arc diff D1430 and then arc land

I think you mean arc patch D1430 then arc land

@mcv21: first, apologies for the conflicting communication. We don't have a lot of external contributors (yet), so our processes are not very oiled on that front (yet).

In T1683#31093, @moranegg wrote:

The problem with having it in the docs, is that specs of higher level (like metadata workflow) must be in a specific repository, or can I have a specs folder in swh-environment?

In T1685#31076, @anlambert wrote:

@zack, I tried to handle that task but I do not have access to domains configuration from the Gandi interface.

In D1430#31457, @mcv21 wrote:

[I think I can't merge this myself]

In T1683#31054, @moranegg wrote:

I need this decision for different specs, for example:

• Legacy software deposit
• Sparse / Metadata deposit (now in docs)
• Metadata workflow- How do we dill with software metadata (T1344)

I think we need to have a conversation about how we decide to add support for rendering specific file formats in the webapp.

@anlambert: are you proposing to remove it from everywhere or only from www.s.o ?

As an addendum to this: it should still be possible to provide an XML file with metadata for all but the simplest cases. What we want to optimize for is the case in which only the mandatory metadata are available and, in that case, offer a CLI alternative instead.

For file paths it would be nice to also support steps that use usual file/dir names foo/bar/baz, as a more readable alternative to number-based steps.

In T808#30140, @nahimilega wrote:

Now the problem is base url and the api token for each phabricator is different so I am not able to understand how to deal with this?
Can anyone please help me?

This is intended, because there is no guarantee that the Git repository accessible via an URL with a trailing slash will be the same of the one accessible at the same URL without the trailing slash. Same argument goes for all other examples you mention.

That is by design (although, admittedly, not really nice). More than "fixing" this specific issue, we might consider revamping/uniforming the general way of presenting sub-sites. But that is not gonna be just a fire-and-forget logo fix.

To clarify: "assignment" of tasks to specific people is something only us, Software Heritage maintainers, do. Hence I'm de-assigning the issue from @01shobitha.

I've nitpicked only about section naming/intro and some style, the rest LGTM.

• swh-weekly-report: new helper to write weekly reports
• swh-weekly-report: split generic code to swhphab.py
• swh-weekly-report: further refactoring/clean-up against swhphab.py
• swhphab.py: do not crash when printing summary of repo-less diffs
• swhphab.py: include status when printing task summaries
• swh-weekly-report: filter on committer date
• swh-weekly-report: preserve iterators and port to current Phabricator
• swh-monthly-report: helper script to draft monthly activity team reports
• swh-monthly-report: filter on committer date

• swh-weekly-report: preserve iterators and port to current Phabricator