Entering freeze for libvirt-10.8.0
I have just tagged v10.8.0-rc1 in the repository and pushed signed tarballs to https://download.libvirt.org/ Please give the release candidate some testing and in case you find a serious issue which should have a fix in the upcoming release, feel free to reply to this thread to make sure the issue is more visible. If you have not done so yet, please update NEWS.rst to document any significant change you made since the last release. Thanks, Jirka
I have just tagged v10.8.0-rc2 in the repository and pushed signed tarballs to https://download.libvirt.org/ Please give the release candidate some testing and in case you find a serious issue which should have a fix in the upcoming release, feel free to reply to this thread to make sure the issue is more visible. If you have not done so yet, please update NEWS.rst to document any significant change you made since the last release. Thanks, Jirka
On 9/27/24 11:28 AM, Jiri Denemark wrote:
Please give the release candidate some testing and in case you find a serious issue which should have a fix in the upcoming release, feel free to reply to this thread to make sure the issue is more visible.
Last night I discovered a regression caused by my commit a37bd2a15b8f2e7aa09519c86fe1ba1e59ce113f pushed a few weeks ago. I have a very simple patch that eliminates the regression, but doesn't fix the larger problem - that is going to require much more thinking than is available in this time frame. I'll be posting the patch shortly (while simultaneously running it through CI and doing more testing). The alternatives to this would be: 1) revert the earlier patch (but I haven't checked yet if this is going to conflict with / functionally break the other patches in that series, or 2) leave this regression in the release
On 9/30/24 9:40 AM, Laine Stump wrote:
On 9/27/24 11:28 AM, Jiri Denemark wrote:
Please give the release candidate some testing and in case you find a serious issue which should have a fix in the upcoming release, feel free to reply to this thread to make sure the issue is more visible.
Last night I discovered a regression caused by my commit a37bd2a15b8f2e7aa09519c86fe1ba1e59ce113f pushed a few weeks ago. I have a very simple patch that eliminates the regression, but doesn't fix the larger problem - that is going to require much more thinking than is available in this time frame.
I'll be posting the patch shortly (while simultaneously running it through CI and doing more testing). The alternatives to this would be:
FYI, the patch has been posted, gitlab CI has passed, and I've tested that both the original bug is still fixed, and the regression is also fixed. (there is still a corner case that doesn't work, but that also didn't work prior to any of these patches). If anyone agrees that this is safe enough to push and it's already past 10PM EST on Monday, please add the Reviewed-by: and push it for me, as I probably won't be awake before jdenemar cuts the release.
1) revert the earlier patch (but I haven't checked yet if this is going to conflict with / functionally break the other patches in that series, or
I tried this and while "git revert" does work with only a trivial merge conflict, the revert is a much bigger change than the new patch I posted, and hasn't been tested.
2) leave this regression in the release
I think if the new patch I posted isn't pushed before release, then (2) is the safest course of action.
participants (3)
-
Jiri Denemark -
Laine Stump -
Laine Stump