On October 30, 2025 6:31 PM, SZEDER Gábor wrote:

On Thu, Oct 30, 2025 at 05:46:01PM -0400, rsbecker@nexbridge.com wrote:

quoted

On October 30, 2025 4:26 PM, Kristoffer Haugsbakk wrote:

quoted

On Thu, Oct 30, 2025, at 20:42, Junio C Hamano wrote:

quoted

"Kristoffer Haugsbakk" [off-list ref] writes:

quoted

On Tue, Oct 28, 2025, at 18:40, rsbecker@nexbridge.com wrote:

quoted

[snip]

Would it make sense for maintenance releases to have a small
release candidate pre-release?  Both of these maintenance releases
have had issues.

Well, that is usually called "the tip of 'master'".  Has NonStop
been having issues with the tip of 'master'?  For how long?  Why
haven't we heard about it at all?  After things are merged there
(which requires them to be cooking in 'next'---oh, has NonStop been
having issues with 'next'?  For how long?), only fixes are chosen and merged to

'maint'

quoted

quoted

quoted

to be the next maintenance release.
...
I doubt any pre-release on 'maint' has much value in that anybody
who are not testing the tip of 'master' would not be testing it either.

You are probably 99.9% likely to be correct.

We tried setting up a CI/CD process for git on NonStop. The problem is
that we use Jenkins, which gets triggered each time a change is made on a branch.
The actual difficulty is that a single run takes more than a day. Once
the committer adds each commit to a branch, we end up with a queue
that is
2-3 weeks long, so end up not running a continuous process. Instead,
we run about 1 a week, which should catch things. The difficulty is
with the latest release is that 2.25.2 came out before our cycle and
the breaks were in there because of changes to one test that just did
not end up dequeuing in time. NonStop is building and testing fine now
after Peff's suggestion on SHELL_PATH, but that was only apparent at
2.52.2. 2.51.1 did not have this issue with our inadvertent use of ksh to run each

test script.

Neither the test library nor t7900 changed in the last two maintenance
releases:

 $ git rev-list --count v2.51.0..v2.51.2 -- t/test-lib.sh t/test-lib-functions.sh
t/t7900-maintenance.sh
 0

Honestly, I do not know. I am just reporting my experience from my own
CI/CD system. All builds are from scratch. Given that I am now using bash,
the situation is resolved as far as I am concerned. If the team wants me to
try to do a bisect, I can, but it will take weeks to do this based on how long
the compile/test cycles are.