@Robie - actually while I agree this is "the usual way" we have in many cases done it exactly as proposed (=> One bug, many patches - as long as it is thematically or feature wise one thing). Look for example at the qemu or libvirt changelog which always seems to come in a barrage of patches per feature/context.
All the patches here are about one problem, the incomplete support/tolerance for openssl 3.
Some patches help directly, some other patches are paving the way.
Gladly the patch descriptions are quite good describing rather exactly what they change - I feel it would be burdensome and not very helpful to copy and paste the very same into 7 bugs.
And in addition the reporter is not a random person, but an active upstream maintainer that directly hand picked us what we'd need.
^^ we could note that in the [Other Info] section BTW
I'd suggest a middle ground to avoid letting this case drown and stall in process.
How about deriving several individual testcases out of the patches?
Obvisouly not those that just restructure things - but each functional change/help could become a testcase. But on just one bug with one impact/reasoning/regression would make it more doable.
In any case I agree we will need a good SRU bug, but as mentioned would like to suggest we avoid proliferation by doing it in just the one bug we have.
@Robie - actually while I agree this is "the usual way" we have in many cases done it exactly as proposed (=> One bug, many patches - as long as it is thematically or feature wise one thing). Look for example at the qemu or libvirt changelog which always seems to come in a barrage of patches per feature/context.
All the patches here are about one problem, the incomplete support/tolerance for openssl 3.
Some patches help directly, some other patches are paving the way.
Gladly the patch descriptions are quite good describing rather exactly what they change - I feel it would be burdensome and not very helpful to copy and paste the very same into 7 bugs.
And in addition the reporter is not a random person, but an active upstream maintainer that directly hand picked us what we'd need.
^^ we could note that in the [Other Info] section BTW
I'd suggest a middle ground to avoid letting this case drown and stall in process.
How about deriving several individual testcases out of the patches? reasoning/ regression would make it more doable.
Obvisouly not those that just restructure things - but each functional change/help could become a testcase. But on just one bug with one impact/
In any case I agree we will need a good SRU bug, but as mentioned would like to suggest we avoid proliferation by doing it in just the one bug we have.