[SKIP SOF-TEST] [TEST] [stable-v2.2] try pointing oss-fuzz at some older branch #7699
Conversation
See thesofproject#7675 why. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
|
@jonathanmetzman, @andyross, @cujomalainey : is there a way to use some older branch of oss-fuzz? Or is only the In this test PR I semi-randomly picked the existing branch https://github.com/google/oss-fuzz/commits/links. It's old enough for the purpose of this test. In https://github.com/thesofproject/sof/actions/runs/5101622354/jobs/9170621114?pr=7699 The Thanks in advance! |
|
@marc-hb I think that is a github-actions question I still don't see the benefit here. This branch and IPC3 are mostly stable/archived. Hence anything we fuzz on main we should be able to cherry-pick down. Nothing new should be landing on this branch so I don't see the benefit of continued fuzzing past support on main. |
|
Thanks @cujomalainey.
But main is likely to become IPC type 4 only while stable-v2.2 is IPC type 3 only. Then cherry-picking won't work; too different.
Fair enough! Could you please copy your last comment in a commit message, delete PS: I'm still curious whether oss-fuzz branches can be used or not. A similar situation could happen in other projects; any project can branch. |
This is a partial fix for thesofproject#7709; doc updates still to be done. Quoting @cujomalainey in - thesofproject#7699 > I still don't see the benefit here. This branch and IPC3 are mostly > stable/archived. Hence anything we fuzz on main we should be able to > cherry-pick down. Nothing new should be landing on this branch so I > don't see the benefit of continued fuzzing past support on main. Quoting @andyross in - thesofproject#7675 > I guess my gut says that fuzzing is a technique for validation of > new code. It has minimal (but sure, not zero) value on maintenance > branches that are expected to be protocol-compatible in perpetuity. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
|
stable-v2.2 removal submitted in |
This is a partial fix for #7709; doc updates still to be done. Quoting @cujomalainey in - #7699 > I still don't see the benefit here. This branch and IPC3 are mostly > stable/archived. Hence anything we fuzz on main we should be able to > cherry-pick down. Nothing new should be landing on this branch so I > don't see the benefit of continued fuzzing past support on main. Quoting @andyross in - #7675 > I guess my gut says that fuzzing is a technique for validation of > new code. It has minimal (but sure, not zero) value on maintenance > branches that are expected to be protocol-compatible in perpetuity. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This is a partial fix for thesofproject#7709; doc updates still to be done. Quoting @cujomalainey in - thesofproject#7699 > I still don't see the benefit here. This branch and IPC3 are mostly > stable/archived. Hence anything we fuzz on main we should be able to > cherry-pick down. Nothing new should be landing on this branch so I > don't see the benefit of continued fuzzing past support on main. Quoting @andyross in - thesofproject#7675 > I guess my gut says that fuzzing is a technique for validation of > new code. It has minimal (but sure, not zero) value on maintenance > branches that are expected to be protocol-compatible in perpetuity. Signed-off-by: Marc Herbert <marc.herbert@intel.com> (cherry picked from commit 3ddd15c)
This is a partial fix for #7709; doc updates still to be done. Quoting @cujomalainey in - #7699 > I still don't see the benefit here. This branch and IPC3 are mostly > stable/archived. Hence anything we fuzz on main we should be able to > cherry-pick down. Nothing new should be landing on this branch so I > don't see the benefit of continued fuzzing past support on main. Quoting @andyross in - #7675 > I guess my gut says that fuzzing is a technique for validation of > new code. It has minimal (but sure, not zero) value on maintenance > branches that are expected to be protocol-compatible in perpetuity. Signed-off-by: Marc Herbert <marc.herbert@intel.com> (cherry picked from commit 3ddd15c)
2 participants
For context: