git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	phillip.wood@dunelm.org.uk, "Jeff King" <peff@peff.net>,
	"Taylor Blau" <me@ttaylorr.com>,
	git@vger.kernel.org, "Phillip Wood" <phillip.wood123@gmail.com>
Subject: Re: ab/cmake-nix-and-ci, was Re: [PATCH] test-lib.sh: discover "git" in subdirs of "contrib/buildsystems/out"
Date: Fri, 09 Dec 2022 12:48:14 +0900	[thread overview]
Message-ID: <xmqqk0311blt.fsf@gitster.g> (raw)
In-Reply-To: <oq7p2776-po8p-r9s0-82o2-o77so874n419@tzk.qr> (Johannes Schindelin's message of "Thu, 8 Dec 2022 10:29:17 +0100 (CET)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Junio, maybe you could clarify your take on this? As project lead, it is
> your decision to define how Git uses Continuous Builds, and how the
> project handles failed CI runs.

I have pretty much been with what Peff and Taylor said in the thread
already ever since we added CMake support to help Windows/VS folks.
I agree with you that we do not need to run it for Linux or macOS,
and if the promised/hoped-for benefit, i.e. that running them on
non-Windows build would uncover issues that are common across the
platform and help Windows, is not something that is likely to
materialize, I'd prefer to see our resources (CI time and developer
attention) not spent on that.

I do not think "how the project handles filed CI runs" is a very big
issue.  I often ignore partial failures (e.g. "winVS(n) test job
triggered rate limit") and the only annoyance I feel is that such a
temporary failure contribute one more message to my trash mailbox,
and I can learn to do the same for a test that marked as failed due
to linux-cmake-ctest job.  I expect that regular contributors are
doing the same pretty much.

How blocking is a CI failure for drive-by contributors who use GGG?
While I do not necessarily value drive-by contributions as much as
you do, if such "an unimportant failure we can ignore" discourages
those coming from GGG route, that would be unfortunate, exactly
because they may not have contributed anything to the failures.
This is not just cmake-ctest, but the leak checking job where a new
use of a tool that is known to be leaky in a test can turn a test
that has been passing to fail.  If we can mark failures in selected
jobs as non-blocking, we definitely should do so.

Between keeping and marking linux-cmake-ctest as non-blocking, and
removing it altogether, I am inclined to say that I'd favor the
latter for the reasons I explained earlier in this message.  But to
help casual contributors coming via GGG, we would anyway need to (1)
allow submitting even with failing tests, and (2) tell them that it
is OK to do so.  Which means it is not the end of the world, from
the point of view of helping casual developers, if we had kept these
brittle CI jobs like linux-cmake-ctest and linux-leaks.


  parent reply	other threads:[~2022-12-09  3:48 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
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 [this message]
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

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

  git send-email \
    --in-reply-to=xmqqk0311blt.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    --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.
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).