RE: [BUGS] Git v2.51.2 on NonStop5
- From
rsbecker@nexbridge.com <rsbecker@nexbridge.com>
- Date
- Oct 31, 2025, 01:02 UTC
- Message-ID
- <00c401dc4a02$14ae4eb0$3e0aec10$@nexbridge.com>
- In-Reply-To
- <aQPnDrsKLsLpaxgI@szeder.dev>
On October 30, 2025 6:31 PM, SZEDER Gábor wrote:
Show 45 quoted lines
>On Thu, Oct 30, 2025 at 05:46:01PM -0400, rsbecker@nexbridge.com wrote: >> On October 30, 2025 4:26 PM, Kristoffer Haugsbakk wrote: >> >On Thu, Oct 30, 2025, at 20:42, Junio C Hamano wrote: >> >> "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes: >> >> >> >>> On Tue, Oct 28, 2025, at 18:40, rsbecker@nexbridge.com wrote: >> >>>>[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' >> >> 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.