git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <rsbecker@nexbridge.com>
To: "'Kristoffer Haugsbakk'" <kristofferhaugsbakk@fastmail.com>,
	<git@vger.kernel.org>
Subject: RE: [BUGS] Git v2.51.2 on NonStop
Date: Thu, 30 Oct 2025 12:02:55 -0400	[thread overview]
Message-ID: <007501dc49b6$aacd9eb0$0068dc10$@nexbridge.com> (raw)
In-Reply-To: <729f9bbf-b75b-4161-b8aa-505ff906bb8a@app.fastmail.com>

On October 30, 2025 11:15 AM, Kristoffer Haugsbakk wrote:
>On Tue, Oct 28, 2025, at 18:40, rsbecker@nexbridge.com wrote:
>> I have found new defects on 2.51.2 that were not present in 2.51.1
>> when building with OpenSSL 3.5 (probably unrelated).
>>
>> Many failures in t7900 resulting from the use of test_subcommand ! as
>> seen below. This is run in bash 5.0.18:
>>
>>[snip]
>
>Would it make sense for maintenance releases to have a small release
candidate pre-
>release?  Both of these maintenance releases have had issues.

Interesting question. I would personally prefer that maintenance releases
would be
fixes only, rather than new functionality or introduction of new
dependencies or
constructs that might break the main release. If there is something
significant done,
it should be in a main release, with a release candidate. I think we should
be cutting
down what is in maintenance releases so that release candidates are not
required.

Obviously, if there is a CVE and we need a maintenance release to fix it,
and the CVE
has breaking changes, we have an issue - and if significant enough, then
yes, a
release candidate should be done.

Just my opinion,
Randall


  reply	other threads:[~2025-10-30 16:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-27 15:56 [ANNOUNCE] Git v2.51.2 Junio C Hamano
2025-10-28 17:40 ` [BUGS] Git v2.51.2 on NonStop rsbecker
2025-10-29 22:28   ` SZEDER Gábor
2025-10-29 22:41     ` rsbecker
2025-10-29 23:18       ` SZEDER Gábor
2025-10-30  0:24         ` rsbecker
2025-10-30  2:53           ` Jeff King
2025-10-30 13:52           ` D. Ben Knoble
2025-10-30 14:59             ` rsbecker
2025-10-30 21:23             ` brian m. carlson
2025-10-30 15:15   ` Kristoffer Haugsbakk
2025-10-30 16:02     ` rsbecker [this message]
2025-10-30 19:42     ` Junio C Hamano
2025-10-30 20:25       ` Kristoffer Haugsbakk
2025-10-30 21:46         ` [BUGS] Git v2.51.2 on NonStop5 rsbecker
2025-10-30 22:30           ` SZEDER Gábor
2025-10-31  1:02             ` rsbecker
2025-10-31 14:09           ` rsbecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='007501dc49b6$aacd9eb0$0068dc10$@nexbridge.com' \
    --to=rsbecker@nexbridge.com \
    --cc=git@vger.kernel.org \
    --cc=kristofferhaugsbakk@fastmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).