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.
