Add machine readable description of platforms

[hasheddan]

What would you like to be added:

A machine-readable file describing the platforms (OS / architecture) that each binary is expected to be released for (xref kubernetes/sig-release#1360).

Why is this needed:

This description will allow krel to perform checks on produced artifacts and make sure that the artifacts that are intended to be released actually are being released.

/assign

[hasheddan]

@justaugustus @saschagrunert thinking about this a little more, I wonder if it may make sense for this to live in k/k. Krel theoretically should be able to run a release for any project, so it seems the project itself should indicate the artifacts that it intends to be released. This could be a standard that we define for "krel-releasable" projects, in which case maybe we add that standard in this repo and then add an implementation in k/k. Thoughts?

[hasheddan]

@dims in case you have any thoughts on this as well :)

[hasheddan]

This could also be related to #1819 if we want to have a formal specification.

[dims]

@hasheddan it would make sense to reach out to @swinslow from LF to have a chat as it looks like there is scanning to SPDX that's being done:
https://github.com/lfscanning/spdx-cncf/tree/master/kubernetes/2020-02

Also related:
cncf/foundation#6

The license exceptions granted by CNCF for non-standard licenses are also in SPDX:
https://github.com/cncf/foundation/blob/master/license-exceptions/README.md

[hasheddan]

Thanks @dims! This looks pretty important in regards to the BOM effort, but I am not sure it directly relates the list of supported platforms that we intend to release

[saschagrunert]

Krel theoretically should be able to run a release for any project,

krel stage/release is tightly scoped to Kubernetes, so it seems fine to me to stick to k/release. I can imagine that we have an API for checking binaries of different formats (like elf) against a set of criterias (like ABI or ISA). This could be re-used by other projects, too.

[dims]

whoops! sorry my head was still in the BOM :) @hasheddan

[hasheddan]

krel stage/release is tightly scoped to Kubernetes, so it seems fine to me to stick to k/release.

@saschagrunert this is definitely true today, but some of the original discussion when krel was started was around moving towards more generally applicable tooling, which I think could influence this decision if we still have that goal.

[saschagrunert]

@hasheddan I see your point. From a usability perspective, would it be better if the definitions live in k/k? Let's say we add/remove a binary, then it probably would make more sense for developers to modify the definition in k/k.

On the other hand: Let's assume that SIG Release owns the definitions. It's easier for us to change it in k/release rather than modifying k/k which might lead into a release blocker.