<div dir="ltr"><div dir="ltr"></div><div class="gmail_quote">Hi Renato,</div><div class="gmail_quote"><br></div><div class="gmail_quote">Thx for clarifying this!</div><div class="gmail_quote"><br><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 class="gmail_quote"><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></div></blockquote><div><br></div><div>Just to be clear: If a patch modified something in <font face="monospace">/llvm</font> and causes a failing test (in <font face="monospace">ninja check-all</font>) in something Tier 2 (e.g. polly), this would count as a failed pre-merge test. Is that what you wanted to have?</div><div> </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 class="gmail_quote"><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.<br></div></div></div></blockquote><div><br></div><div>How would someone from a Tier 2 project find out that an in-flight patch breaks their Tier 2 project? How should they be notified? How long should the owner of the patch wait before they land it anyway?</div><div><br></div><div>At the moment pre-merge testing is only reporting results back to Phabricator. AFAIK there is no notification mechanism beyond that.</div><div> </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 class="gmail_quote"><div></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></div></blockquote><div><br></div><div>If you want people (and tools) to behave differently on tier 1 vs. tier 2 projects, it should be clear in which category something falls. I agree, the policy should be something generic and high-level so we don't have to change it all the time. However at any given time it should be clear on what the tiers are. If I look at a file in the monorepo, I would like to have an easy way to find out which tier it belongs to.</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 class="gmail_quote"><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.<br></div></div></div></blockquote><div><br></div><div>For pre-merge testing, we're only using CMake in the monorepo, so that already has a very narrow scope and excludes some tier 2 projects.</div><div>With "experimental" you mean code that matches a <font face="monospace">".*/experimental/.*" path regex?</font></div><div> </div><div><br></div><div>Best,</div><div>Christian</div></div></div>