Re: [PATCH] test-lib.sh: discover "git" in subdirs of "contrib/buildsystems/out"

> 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.

>   - 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).

> 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.