From: rsbecker@nexbridge.com Date: Fri, 31 Oct 2025 14:09:56 GMT Subject: RE: [BUGS] Git v2.51.2 on NonStop5 Message-ID: <010001dc4a70$0c7d67d0$25783770$@nexbridge.com> In-Reply-To: <009f01dc49e6$98c5ae30$ca510a90$@nexbridge.com> On October 30, 2025 5:46 PM, I wrote: >To: 'Kristoffer Haugsbakk' ; 'Junio C Hamano' > >Cc: git@vger.kernel.org >Subject: RE: [BUGS] Git v2.51.2 on NonStop5 > >On October 30, 2025 4:26 PM, Kristoffer Haugsbakk wrote: >>On Thu, Oct 30, 2025, at 20:42, Junio C Hamano wrote: >>> "Kristoffer Haugsbakk" 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. The current CI/CD run passed with only t9001 failing as expected. I am wondering whether we could add a switch like SENDMAIL=NoThanks. There is an object called sendmail on the box I am on, but it is not a compliant port - someone tried this decades ago.