Add project metadata to .asf.yaml for ATR sync

[ppkarwasz]

Populate the project.metadata block so the asfyaml "project" feature syncs the values to the Apache Trusted Releases (ATR) platform.

The purpose of this PR is to test if the data introduced here is being synced by ATR.

[garydgregory]

Aren't you already running this experiment in Log4j repos?

[ppkarwasz]

With Log4j I have tested making a release with ATR.

This PR only changes the metadata for the project on https://release-test.apache.org/ . Since ATR has a REST API, we can use it to display on https://security.apache.org/projects/ the security data projects advertise themselves.

[garydgregory]

But there is nothing on https://release-test.apache.org/ and https://security.apache.org/projects/ has good links already. I'd rather let someone else clutter up their repo with this giant thing that's work in progress.

[ecki]

What bout the doap.rdf files maintained for the projects?

https://github.com/apache/comdev-projects/blob/ddbf0ed0084b30e3638f615c5467a1c0291c135c/data/projects.xml#L145

[ppkarwasz]

But there is nothing on https://release-test.apache.org/ and https://security.apache.org/projects/ has good links already.

Exactly, currently the “Metadata“ tab of the project contains information imported from the DOAP file, while the newly added “Security” tab is empty. If we merge this PR, the data from .asf.yaml should get exported there.

The data on security.apache.org is updated manually. Right now it is up-to-date for Commons, but updating it does not scale. This is why I would prefer project to export it to ATR and we import it from there.

What bout the doap.rdf files maintained for the projects?

I don't know what plans does ATR reserve to DOAP, but there is a big apache/tooling-trusted-releases#444 tracking issue to reimplement projects.apache.org in terms of ATR. At that point I imagine that ATR could generate DOAP files on the fly, instead of consuming them, so projects that don't want to maintain them can still keep backward compatibility.

[ecki]

I don't know what plans does ATR reserve to DOAP, but there is a big apache/tooling-trusted-releases#444 tracking issue to reimplement projects.apache.org in terms of ATR. At that point I imagine that ATR could generate DOAP files on the fly, instead of consuming them, so projects that don't want to maintain them can still keep backward compatibility.

Ok, but we should only maintain one of two, and asf should have a stance on which is used (and we need to fix the links for the doap files for Commons)

[ppkarwasz]

If I know the ASF, it won't have a stance: it will just offer both paths (DOAP authoritative or ATR authoritative and DOAP generated) and let projects choose.

I can gather more info about the future of DOAP and open a ML thread.