<div dir="ltr"><div dir="ltr">On Tue, 3 Nov 2020 at 07:40, Christian Kühnel <<a href="mailto:kuhnel@google.com">kuhnel@google.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>1) How should pre-merge testing behave differently on tier 1 vs. 2 projects? </div><div>Do we want the builds/tests to pass on broken tier 2 projects?</div></div></blockquote><div><br></div><div>Hi Christian,</div><div><br></div><div>My view is that we shouldn't change how we test, either pre merge or post merge. If we have official tests for something already, those must pass.</div><div><br></div><div>The idea of tiers is to reduce the burden of maintenance of sections of the code for both the sub-community that cares about it and the rest of the community that doesn't.</div><div><br></div><div>So, whatever we already have a pre-merge test for, is IMO tier 1. If they are causing grief and are not seen to be core components by the large LLVM community, then as we "demote" them to tier 2, we also remove them from the noisy testing (on both pre/post merge).</div><div><br></div><div>Tier 2 testing is the responsibility of the sub-community that cares about it. If they want pre-merge tests for those, they're responsible for making sure the fixes are proposed as soon as possible for the patches in flight. None of those pre-commit tests should warn the rest of the community, or it would get hard to know which bot results we should "respect", especially for newcomers.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>2) How can we automatically detect the tiers of the projects in the pre-merge build scripts? If we want to treat them differently we somehow need to be able to distinguish these in the repo.</div></div></blockquote><div><br></div><div>It should be very simple to do that, but my second take had the mistake of listing projects by name. Others have suggested we don't do that and let the boundaries be more subtle. I very much like that.</div><div><br></div><div>The idea is that there are concepts of tiers, and what goes in/out will change with time, depending on how big a sub-community a particular piece of code has, or on its experimental status, or if/when incubator projects move into the monorepo. </div><div><br></div><div>Initially, everything outside of the mono-repo is tier 2, which matches the incubator policy quite well. Inside the monorepo, there are a few rules of what's tier 2 (experimental, non-CMake build systems, editor/tools config, non-essential scripts), with everything else in tier 1.</div><div><br></div><div>With the requirement of "being tested with a noisy bot" in tier 1, everything that is already noisy-tested now is in tier 1. If we want to demote something, we need to be explicit about it and allow the creation of a sub-community to form.</div><div><br></div><div>Makes sense?</div><div><br></div><div>cheers,</div><div>--renato</div></div></div>