From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH v2 1/3] ident: stop assuming that `gw_gecos` is writable
Date: Fri, 07 Mar 2025 10:20:57 -0800 [thread overview]
Message-ID: <xmqqjz90em7q.fsf@gitster.g> (raw)
In-Reply-To: <Z8rEIffQeVCjd_U8@pks.im> (Patrick Steinhardt's message of "Fri, 7 Mar 2025 11:02:09 +0100")
Patrick Steinhardt <ps@pks.im> writes:
> I think it would be a bit sad to disable those jobs. They build and pass
> the test suite alright in Git itself, even though they fail downstream
> in Git for Windows. They help me quite a bit to ensure that I don't
> regress anything that already is working while I'm iterating on the
> current set of features. So in the end, I view them more as testing more
> variants of Windows than replacing what we currently have, similar to
> how we test Git on different Linux distributions.
Hmph, but compared to Linux or macOS platforms, do developers on
Windows (and users of Git on Windows, including but not limited to
users of Git-for-windows) benefit from having the code base to be
tested on "more variants of Windows", or would it be more noise that
they need to go visit the failing CI and spend time to triage if the
breakage is something they should worry about?
The above is more or less a rhetorical question. I think by now
everybody knows I do not like monoculture, and if we had infinite
engineering resources, I would think it would be healthy to have
more than one prominent and competing Windows port of Git (no, I
know about Cygwin, but I hear that the platform is POSIXy enough, so
I do not exactly consider Git running on Cygwin qualifies as "a
Windows port"). But we do not seem to live in such a world.
> I have said before that I'm very willing to help to figure out any
> issues, regardless of which platform, and I stand by that
> statement -- if you see anything that is broken in this context
> and report the issue to me I'll jump on it immediately.
It's ultimately up to Windows folks to take you up on the offer.
>> > Nevertheless, there is currently this huge push, including breaking
>> > changes after -rc1 and all, for switching to Meson. Therefore, we need
>> > to make it work, somehow, even in Git for Windows' SDK, hence this
>> > patch, at this point in time.
>> ...
> That's completely fair. The CI job we have isn't meant to verify that we
> have a G4W-compatible distribution falling out of it, it merely verifies
> that we can build and pass tests in such a "standalone" (that is,
> without the SDK) configuration. We might eventually want to introduce
> another job that _does_ use the SDK with Meson, as well, but I didn't
> yet see a need for that until now.
Knowing that it is the most widely used platform, I naturally and
naïvely was expecting and hoping that there are folks other than
Dscho who have enough bandwidth and inclination to help in this
area, but so far, having a set of jobs in CI that use a toolchain
that is different from what G4W uses (as expected) did not quite
help X-<. Nobody noticed it until the last minute.
Which made me say that we do not seem to live in such a world, which
in turn makes me accept that putting all Windows eggs in a single
basket and watch it closely may be a reasonable alternative when it
comes to Windows [*], than hoping that diverse set of different
builds eventually help flourishing Windows developer community.
I dunno.
[Footnote]
* Yes, I admit that it may be another way to say that I do not care
the particular platform deeply enough.
next prev parent reply other threads:[~2025-03-07 18:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-27 15:44 [PATCH 0/2] Hot fixes from Git for Windows v2.49.0-rc0 Johannes Schindelin via GitGitGadget
2025-02-27 15:44 ` [PATCH 1/2] ident: stop assuming that `gw_gecos` is writable Johannes Schindelin via GitGitGadget
2025-02-27 21:15 ` Junio C Hamano
2025-02-27 15:44 ` [PATCH 2/2] meson: fix sorting Johannes Schindelin via GitGitGadget
2025-02-28 7:58 ` Patrick Steinhardt
2025-03-06 10:26 ` [PATCH v2 0/3] Hot fixes from Git for Windows v2.49.0-rc0 Johannes Schindelin via GitGitGadget
2025-03-06 10:26 ` [PATCH v2 1/3] ident: stop assuming that `gw_gecos` is writable Johannes Schindelin via GitGitGadget
2025-03-06 10:50 ` Patrick Steinhardt
2025-03-06 12:26 ` Johannes Schindelin
2025-03-06 16:33 ` Junio C Hamano
2025-03-07 10:02 ` Patrick Steinhardt
2025-03-07 18:20 ` Junio C Hamano [this message]
2025-03-06 10:26 ` [PATCH v2 2/3] meson: fix sorting Johannes Schindelin via GitGitGadget
2025-03-06 10:26 ` [PATCH v2 3/3] cmake: generalize the handling of the `CLAR_TEST_OBJS` list Johannes Schindelin via GitGitGadget
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=xmqqjz90em7q.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=johannes.schindelin@gmx.de \
--cc=ps@pks.im \
/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).