Re: What's cooking in git.git (Jan 2022, #03; Thu, 13)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Elijah Newren <newren@xxxxxxxxx> 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:
> https://lore.kernel.org/git/pull.1192.git.git.1642176433017.gitgitgadget@xxxxxxxxx/
>
> 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.

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?

An obvious alternative, based on the same attitude, is to rip out
the whole fragile leak-checker thing from the CI.  I've mentioned
an ideal alternative (disregarding feasibility) already elsewhere
so I won't repeat it.

Thanks.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux