Hi All,

I'm sending this to oe-arch as it seems the best place to
mention/discuss it.

After reading an email about encouraging best practises when supporting
older software releases, it got me thinking about our LTS and spdx/sbom
support. We don't have create-spdx there and our official policy says
no feature backports or breaking changes.

If you understand LTS as "support" instead of "stable", there is a
compelling argument that we should be supporting people of older
releases to meet things like the new legislation around SBoMs. I think
the world is learning that difference and being more open to it too.

I discussed this with the YP TSC and we agreed we probably should
evaluate the options for adding create-spdx to dunfell. There are a lot
of questions about it and it is something a lot of users would like. I
think it would better reflect on the project to support it.

There is some risk to this. We need the bb.compress zstd code and some
changes to package.bbclass, specially:

https://git.yoctoproject.org/poky/commit/?id=7ec54b174304e940ec66f21ac512f7b50fa637b3

The class itself isn't problematic as it is standalone.

This doesn't mean any policy will change, it would be a one off
exception granted by the TSC for an initiative to support older
releases in a changing world.

I think Joshua said he'd be willing to have a look at what was needed,
I wanted to put the idea out there and say the TSC is open minded to
the idea assuming testing works out ok and so on. We need to look
carefully at the zstd requirement in particular. I believe our LTS
maintainer is open to the idea too if there is support from the
community in working out the details.

I guess I'm asking if there is that support? :)

Cheers,

Richard

Hi Richard

On Wednesday, 1 March 2023 23:33:22 NZDT Richard Purdie wrote:

After reading an email about encouraging best practises when supporting
older software releases, it got me thinking about our LTS and spdx/sbom
support. We don't have create-spdx there and our official policy says
no feature backports or breaking changes.

If you understand LTS as "support" instead of "stable", there is a
compelling argument that we should be supporting people of older
releases to meet things like the new legislation around SBoMs. I think
the world is learning that difference and being more open to it too.

I discussed this with the YP TSC and we agreed we probably should
evaluate the options for adding create-spdx to dunfell. There are a lot
of questions about it and it is something a lot of users would like. I
think it would better reflect on the project to support it.

There is some risk to this. We need the bb.compress zstd code and some
changes to package.bbclass, specially:

https://git.yoctoproject.org/poky/commit/?id=7ec54b174304e940ec66f21ac512f7b
50fa637b3

The class itself isn't problematic as it is standalone.

This doesn't mean any policy will change, it would be a one off
exception granted by the TSC for an initiative to support older
releases in a changing world.

I think Joshua said he'd be willing to have a look at what was needed,
I wanted to put the idea out there and say the TSC is open minded to
the idea assuming testing works out ok and so on. We need to look
carefully at the zstd requirement in particular. I believe our LTS
maintainer is open to the idea too if there is support from the
community in working out the details.

FWIW we have been running with this feature backported on top of dunfell for a
while and haven't noticed any ill effects. I can't recall at this stage what
changes were needed but if there were any I'd think they were minimal.

Assuming there are no objections to having this in dunfell, I'll tentatively
put up my (personal) hand to support it given that it seems to be fairly
straightforward. If desired I could send the patches we have.

Cheers
Paul

On Thu, Mar 2, 2023 at 6:31 PM Paul Eggleton
<bluelightning@...> wrote:

Hi Richard

On Wednesday, 1 March 2023 23:33:22 NZDT Richard Purdie wrote:

After reading an email about encouraging best practises when supporting
older software releases, it got me thinking about our LTS and spdx/sbom
support. We don't have create-spdx there and our official policy says
no feature backports or breaking changes.

If you understand LTS as "support" instead of "stable", there is a
compelling argument that we should be supporting people of older
releases to meet things like the new legislation around SBoMs. I think
the world is learning that difference and being more open to it too.

I discussed this with the YP TSC and we agreed we probably should
evaluate the options for adding create-spdx to dunfell. There are a lot
of questions about it and it is something a lot of users would like. I
think it would better reflect on the project to support it.

There is some risk to this. We need the bb.compress zstd code and some
changes to package.bbclass, specially:

https://git.yoctoproject.org/poky/commit/?id=7ec54b174304e940ec66f21ac512f7b
50fa637b3

The class itself isn't problematic as it is standalone.

This doesn't mean any policy will change, it would be a one off
exception granted by the TSC for an initiative to support older
releases in a changing world.

I think Joshua said he'd be willing to have a look at what was needed,
I wanted to put the idea out there and say the TSC is open minded to
the idea assuming testing works out ok and so on. We need to look
carefully at the zstd requirement in particular. I believe our LTS
maintainer is open to the idea too if there is support from the
community in working out the details.

FWIW we have been running with this feature backported on top of dunfell for a
while and haven't noticed any ill effects. I can't recall at this stage what
changes were needed but if there were any I'd think they were minimal.

Assuming there are no objections to having this in dunfell, I'll tentatively
put up my (personal) hand to support it given that it seems to be fairly
straightforward. If desired I could send the patches we have.

I think that would be fine, or maybe at least put them on a contib
branch somewhere so we can look them over?

Cheers
Paul