From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
phillip.wood@dunelm.org.uk, git@vger.kernel.org,
"Phillip Wood" <phillip.wood123@gmail.com>,
"Johannes Schindelin" <johannes.schindelin@gmx.de>
Subject: Re: [PATCH] test-lib.sh: discover "git" in subdirs of "contrib/buildsystems/out"
Date: Sat, 03 Dec 2022 10:12:15 +0900 [thread overview]
Message-ID: <xmqqv8mtthn4.fsf@gitster.g> (raw)
In-Reply-To: <Y4qF3iHW2s+I0yNe@coredump.intra.peff.net> (Jeff King's message of "Fri, 2 Dec 2022 18:10:22 -0500")
Jeff King <peff@peff.net> writes:
> I have similar feelings to you here. Back when cmake support was
> introduced, I explicitly wanted it to be something for people who cared
> about it, but that wouldn't bother people who didn't use it:
>
> https://lore.kernel.org/git/20200427200852.GC1728884@coredump.intra.peff.net/
>
> I stand by that sentiment, but it seems to have crept up as a required
> thing to deal with, and that is mostly because of CI. Using cmake in CI
> is good for telling developers when a change they make has broken cmake.
> But it also makes cmake their problem, and not the folks interested in
> cmake.
>
> Now maybe attitudes have changed, and I am out of date, and cmake
> support is considered mature and really important (or maybe nobody even
> agreed with me back then ;) ). But if not, should we consider softening
> the CI output so that cmake failures aren't "real" failures? That seems
> drastic and mean, and I don't like it. But it's the root of the issue,
> IMHO.
It makes the two of us (or three couning Ævar?).
> - I'd actually put the leak-checking CI in the same boat. It's a good
> goal, and one I hope we work towards. But it feels like the current
> state is not very mature, and people often end up wrestling with CI
> to deal with failures that they didn't even introduce (e.g., adding
> a new test that happens to run a Git program that has an existing
> leak, and now you are on the hook for figuring out why the existing
> "passes leaks" annotation is wrong).
Hear, hear.
> I'm not necessarily proposing to drop the leaks CI job here. I'm mostly
> philosophizing about the greater problem. In the early days of Git, the
> cross-platform testing philosophy was: somebody who cares will test on
> that platform and write a patch. If they don't, how important could it
> be? With CI that happens automatically and it becomes everybody's
> problem, which is a blessing and a curse.
True.
next prev parent reply other threads:[~2022-12-03 1:14 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-29 9:40 What's cooking in git.git (Nov 2022, #07; Tue, 29) Junio C Hamano
2022-11-29 18:59 ` ab/remove--super-prefix and -rc0 (was What's cooking in git.git (Nov 2022, #07; Tue, 29)) Glen Choo
2022-11-30 3:43 ` Junio C Hamano
2022-11-30 18:14 ` Glen Choo
2022-11-30 19:43 ` Ævar Arnfjörð Bjarmason
2022-12-01 5:20 ` Junio C Hamano
2022-12-01 17:44 ` Glen Choo
2022-12-01 21:26 ` Junio C Hamano
2022-11-29 19:08 ` What's cooking in git.git (Nov 2022, #07; Tue, 29) Glen Choo
2022-11-30 3:45 ` Junio C Hamano
2022-11-30 18:08 ` Glen Choo
2022-11-29 21:16 ` ds/bundle-uri-4 (was Re: What's cooking in git.git (Nov 2022, #07; Tue, 29)) Derrick Stolee
2022-12-01 15:06 ` Derrick Stolee
2022-12-02 0:25 ` Junio C Hamano
2022-11-30 9:57 ` ab/cmake-nix-and-ci " Phillip Wood
2022-11-30 10:16 ` Ævar Arnfjörð Bjarmason
2022-12-01 14:23 ` Phillip Wood
2022-12-01 16:39 ` [PATCH] test-lib.sh: discover "git" in subdirs of "contrib/buildsystems/out" Ævar Arnfjörð Bjarmason
2022-12-01 16:48 ` Phillip Wood
2022-12-01 17:13 ` Ævar Arnfjörð Bjarmason
2022-12-01 23:00 ` Junio C Hamano
2022-12-02 15:14 ` Phillip Wood
2022-12-02 16:40 ` Ævar Arnfjörð Bjarmason
2022-12-02 23:10 ` Jeff King
2022-12-03 1:12 ` Junio C Hamano [this message]
2022-12-03 1:41 ` Ævar Arnfjörð Bjarmason
2022-12-05 9:15 ` Jeff King
2022-12-05 23:34 ` Taylor Blau
2022-12-05 23:46 ` Ævar Arnfjörð Bjarmason
2022-12-06 0:35 ` Taylor Blau
2022-12-06 1:36 ` Jeff King
2022-12-06 1:43 ` Ævar Arnfjörð Bjarmason
2022-12-06 2:05 ` Jeff King
2022-12-06 2:19 ` Ævar Arnfjörð Bjarmason
2022-12-06 3:52 ` Junio C Hamano
2022-12-06 9:54 ` Phillip Wood
2022-12-06 10:57 ` Ævar Arnfjörð Bjarmason
2022-12-08 9:29 ` ab/cmake-nix-and-ci, was " Johannes Schindelin
2022-12-08 11:34 ` Ævar Arnfjörð Bjarmason
2022-12-09 3:48 ` Junio C Hamano
2022-12-09 13:55 ` Ævar Arnfjörð Bjarmason
2022-12-07 1:00 ` Taylor Blau
2022-11-30 10:02 ` What's cooking in git.git (Nov 2022, #07; Tue, 29) Phillip Wood
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqv8mtthn4.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=johannes.schindelin@gmx.de \
--cc=peff@peff.net \
--cc=phillip.wood123@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).