Jeff King <peff@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx/ > > 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.
