Hi Evgeny, Thanks for driving this forward!
First of all: Have we decided if 1.15 should be an LTS or a regular release? I think it was suggested somewhere that it should be a non-LTS release in case we find some major issues with the non-pristine code where we need a new minor release. I agree with your assessment that r1931549 and r1931570 are critical for the release. I'll try to find some time during the weekend to review ..549. I'd be happy if someone else could review ..570 (it is my code/nomination). Thoughts below on the rest! Den fre 30 jan. 2026 kl 13:37 skrev Evgeny Kotkov via dev < [email protected]>: > Evgeny Kotkov <[email protected]> writes: > > > With [3] resolved, I went ahead and created the 1.15.x release branch. > > A small status update on the release: > > - In r1931332, I drafted the initial changelog for 1.15.0. > > - We have several pending backport nominations in branches/1.15.x/STATUS: > > * r1931549 > Use bytewise content comparison in the "is the file modified?" working > copy > checks if we have the pristine file content. > > * r1931570 > Forward the allow_unver_obstructions argument from the deprecated > function. > > * r1930973 > Fix test failures of JavaHL with Java 25 on Windows due to that > deleting a > file with readonly flag on Windows fails since Java 25. > > * r1931176 > Update checks for SERF 1.4.0 to check for SERF 1.5.0. > I have voted for this in r1931614. > > * r1931265 > Newest OpenSSL/httpd does not like server certificates with tiny keys. > > * r1931266 > In Python 3, hashlib input data must be byte strings, not Unicode. > > * r1931298, r1931552 > Update an omission in a docstring. > I think we should approve it even though it only has two +1 for the full backport. r...552 is only formatting and the whole backport is only documentation. However maybe Nathan could upgrade his vote... > > * r1931334, r1931337, r1931359, r1931369, r1931373 > Remove a potentially data-truncating typecast in our adler32 > implementation > > I think it would be nice to have all of them merged before we roll RC1, but > at the same time only the first two (r1931549 and r1931570) seem to look > like > strict blockers for RC1. > > So once those are merged, I'll start looking towards rolling an RC1 build. > > > Thanks, > Evgeny Kotkov >
