review template with:

• @software for the software concept/project
• @softwareversion for a specific release
• @insoftware for a specific artifact in the software (e.g revision, directory, file)

A full deposit from HAL doesn't work.
It seems to be on HAL side, the deposits stay in partial status and aren't digested.
On HAL interface after moderation there is "Application Error".
I signalled this to Bruno and he said he's fixing it.

In D2216#52215, @vlorentz wrote:

In D2216#52210, @moranegg wrote:

follow the instructions of @vlorentz about L3 and we can continue the work on this tool :-)

This is already done, else you wouldn't be able to read the code :)

Thanks @scatenag for this !
follow the instructions of @vlorentz about L3 and we can continue the work on this tool :-)

Note that this doesn't solve the question of pulling release notes from e.g. GitHub release pages, which is something that would need to be done by some other component (T17 comes to mind).

review template with @software and @softwareversion entries

@anlambert thanks for the detailed explanation !

@vlorentz I think we can resolve this due to D1614?

At the moment the loader-tar is not adapted to receiving release objects.
@ardumont, Should we wait the refactoring of the loader-tar to successfully implement this feature for deposits?

• Fix typo

• Update specs: status image and other modifications

thanks !

Can you link to the list of metadata fields that resolves this ?

Here is the list of metadata we worked on for HAL specifications:
https://forge.softwareheritage.org/P183

• Update specs: ammend occurrences into branches

thanks @twitu for finding this location, if you see any other places dates are documented, feel free to comment here.

We have http://status.softwareheritage.org/ for this, but we are not using it.
I suggest we start using it and make it a habit of doing so, developing the needed integrations.

• Update specs with date mapping

@zack: Good idea to have only one glossary.

This is resolved with the following decision as I understand it:
specifications of a component should be in swh-<component>/docs/specs/.
specifications of a a transversal functionality should be in swh-docs/specs/.

Other comment, specs folder might be a better place to hold the file. we might have other specs in swh-docs:-)

Very nice output !

• Update specs and test scenarios in docs with D1617 comments

• Added release artifact in loading specification

From your comments, we can specify the following:
A deposit containing release metadata (softwareVersion, releaseNote) is a release software artifact.
The metadata that arrives with a deposit MUST use CodeMeta vocabulary (this should be reviewed following T1345).

Draft is done and was sent to Inria GT for feedback.