All of
 help / color / mirror / Atom feed
From: Elijah Newren <>
To: Junio C Hamano <>
Cc: "Ævar Arnfjörð Bjarmason" <>,
	"Git Mailing List" <>
Subject: Re: What's cooking in git.git (Jan 2022, #03; Thu, 13)
Date: Fri, 14 Jan 2022 13:49:11 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <xmqqmtjyaylt.fsf@gitster.g>

On Fri, Jan 14, 2022 at 11:47 AM Junio C Hamano <> wrote:
> Elijah Newren <> writes:
> > It's apparently the latter, because there have been no test script
> > changes in the relevant tests.
> >
> >> Somebody with too much time on their hand should go in and check to
> >> help, before CI testing on 'seen' becomes useful again.
> >
> > This "fixes" seen:
> >
> >
> > I briefly looked at a couple leak traces and thought they looked ref
> > related, but I don't have time to go hunt down memory leaks right now.
> > I figure this thread has reported them, so let's just get "seen" back
> > to green.
> If it were "we added a use of known-to-leak command in an otherwise
> clean test, without adding a new leak", I would wholeheartedly
> support such a change, but if it is the other way around, it may
> make sense to leave it broken as an incentive for people who care
> about leaks to go in and fix them up.

Perhaps.  Waiting can make sense up to a point.

> If we toggle it off any time leak-checker CI job starts complaining
> on a test script, the leak-checker CI job serves no useful purpose,
> no?

Folks who use PRs for the purpose of getting the cross-platform CI
testing before submitting to the list can still get early notification
of potential leaks in their own series, due to the remaining tests
being marked as leak-free.  They can then fix up their series before
submitting them to the list.  That seems like a useful purpose to me.

Further, these CI jobs did notify us of an issue in someone else's
patches (we don't yet know whose), and we were able to report it much
like any other bug report.  That gives people a heads up and allows
them to take action on it.  (And if they do so, they can remark the
test as leak-free.)  That also seems like a useful purpose to me.

In contrast, if we leave the leak-checker failing and the failing job
spreads to next and master, then we'll just end up training everyone
to ignore it -- both for their own PRs and in general.  To me, that's
what making the leak-checker serve no useful purpose would look like.

  reply	other threads:[~2022-01-14 21:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-14  0:48 What's cooking in git.git (Jan 2022, #03; Thu, 13) Junio C Hamano
2022-01-14  4:18 ` Junio C Hamano
2022-01-14 16:27   ` Elijah Newren
2022-01-14 19:47     ` Junio C Hamano
2022-01-14 21:49       ` Elijah Newren [this message]
2022-01-14 22:03         ` Junio C Hamano
2022-01-14 22:18           ` Junio C Hamano
2022-01-14 18:12   ` Ævar Arnfjörð Bjarmason
2022-01-17  7:18     ` Patrick Steinhardt
2022-01-14 15:44 ` Mistakes in the stalled category? (Was: Re: What's cooking in git.git (Jan 2022, #03; Thu, 13)) Elijah Newren
2022-01-14 23:32   ` Mistakes in the stalled category? Junio C Hamano
2022-01-14 23:49   ` Junio C Hamano
2022-01-15 19:38     ` Junio C Hamano
2022-01-18 16:11       ` Derrick Stolee
2022-01-14 15:54 ` en/present-despite-skipped & en/remerge-diff (Was: Re: What's cooking in git.git (Jan 2022, #03; Thu, 13)) Elijah Newren
2022-01-14 19:39 ` tb/midx-bitmap-corruption-fix (was: " Taylor Blau
2022-01-15 16:45 ` What's cooking in git.git (Jan 2022, #03; Thu, 13) David Aguilar
2022-01-15 19:15   ` Junio C Hamano
2022-01-16  2:15     ` David Aguilar

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:

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

  git send-email \ \ \ \ \ \

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.