From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>,
git@vger.kernel.org,
"brian m. carlson" <sandals@crustytoothpaste.net>
Subject: Re: [PATCH] ci: bump debian-11 job to debian-12
Date: Thu, 8 Oct 2026 08:15:26 +0200 [thread overview]
Message-ID: <asc0_sjw8beWy2y5@pks.im> (raw)
In-Reply-To: <xmqqzewp5jhi.fsf@gitster.g>
On Wed, Oct 07, 2026 at 01:44:09PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > BTW, I noticed that the linux32 build is using ubuntu 20.04, which has
> > been out of LTS for a year. But bumping isn't really an option; they
> > dropped i386 platform support, and so has Debian.
> >
> > I'm mostly inclined to leave it unless/until it starts creating
> > headaches. To some degree, if we cannot even find an image to test
> > again, it might not be an important enough platform to care about. But I
> > can also imagine there is a long tail of oddball 32-bit platforms that
> > Git does run on (like small ARM chips), and it's nice to at least have
> > some coverage. Possibly there's an ARM image we could use (looks like
> > armhf?).
> >
> > We also seem to use 20.04 for linux-TEST-vars. On the surface there's no
> > reason it couldn't be using ubuntu-latest, though I think this may be
> > one of those cases where it's doing double duty as "test exotic configs"
> > and "test on an older platform". But might be worth bumping to the
> > oldest in-scope LTS.
> >
> > All out of scope for this patch, and mostly I'm inclined to ignore it
> > for now until we hit problems (and then decide if it's worth
> > accommodating or if old systems are too old).
>
> I am getting annoyed enough to see that the lack of 20.04 is finally
> giving failures more often than it used to. And am planning to
> suggest to:
>
> * drop linux32 job
>
> * update linux-TEST-vars to run with ubuntu:rolling like everybody
> else with the default version of gcc
>
> I personally do not see much value in the test-vars job in that
> enabling all exotic configs all at once would not match use patterns
> of any real world users, which may likely to enable only some but
> not all of them, and for that reason am also tempted to propose to
> just remove it at the same time as we remove linux32 job.
I think it'd be great to continue exercising i386, and Debian still has
supported images for that.
Ialso think that we should keep the TEST-vars job. It has catched
regressions several times for me in the past. Sure, the combination of
flags in typically not exercised. But I think that by itself is not a
good enough argument to drop this entirely.
But, oh well, you probably just want to snipe somebody into doing this.
So fine, I'll bite and will send patches later today.
Patrick
next prev parent reply other threads:[~2026-10-08 6:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-05 13:58 [PATCH] ci: bump debian-11 job to debian-12 Jeff King
2026-09-05 16:32 ` Junio C Hamano
2026-09-06 15:11 ` Jeff King
2026-09-07 6:03 ` Patrick Steinhardt
2026-10-07 20:44 ` Junio C Hamano
2026-10-08 6:15 ` Patrick Steinhardt [this message]
2026-09-07 6:03 ` Patrick Steinhardt
2026-09-11 2:19 ` Jeff King
2026-09-11 5:09 ` Patrick Steinhardt
2026-09-11 15:42 ` Junio C Hamano
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=asc0_sjw8beWy2y5@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.net \
/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