<div dir="ltr">Hi Renato,<div><br></div><div>Thank you for working on this! When looking at the topic from the pre-merge testing perspective 2 questions came to my mind:</div><div><br></div><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><br></div><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> <br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Best,<div>Christian</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 2, 2020 at 8:58 PM Renato Golin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<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">Ok, so after some feedback, here's an updated version. Separate thread as the previous got split.<div><br></div><div>People seem to agree on the overall terms, but there was confusion on the difference between tier 2 and 3 as well as clarification on what projects go where.</div><div><br></div><div>I have joined tiers 2 and 3 and made explicit the three criteria they fit into, with the requirements more formally explained.</div><div><br></div><div>Please review the sub-project lists on the two tiers, I'm not so sure about them. </div><div><br></div><div>Once we're happy with the "what", I'll send a review for a new doc so we can discuss the writing and format there (ignore it for now).</div><div><br></div><div>Here it goes:</div><div><br></div><div>*** Tier 1: the core compiler, officially supported by the community.<br><br>Rationale:<br> * Common code that supports most projects, upstream and downstream forks and forms the toolchain itself.<br> * Includes everything we release on all architectures and OSs we have releases on.<br><br>What:<br> * LLVM itself, clang/tools, compiler-rt, libcxx/abi/unwind, lld, lldb, openmp, mlir.<br> * Basically everything inside the mono-repo that is not in tier 2.<br> * Builds on all first class citizen combinations of targets x OSs (incl. test-suite).<br> * The CMake build infrastructure and release scripts.<br> * Phabricator & Buildbot infrastructure.<br> * The test-suite repository.<br><br>Requirements:<br> * Follow all core development policies on code quality, reviews, reverts, etc.<br> * Noisy green buildbots, emailing all developers.<br> * Most not be broken by changes in tier 2 (ex. if they require tier 1 changes).<br> * Bitrot will downgrade areas to tier 2 or be removed, depending if a sub-community picks up support and has a timeline to fix.<br><br>*** Tier 2: side projects that integrate with the compiler and that *should* work at all times.<br><br>Rationale:<br> * Code that is making its way into LLVM core (tier 1) via experimental/incubator roadmaps, or;<br> * Code that isn't meant to be in LLVM core, but has a sub-community that maintains it long term, or;<br> * Code that is making its way out of LLVM core (legacy) and that is a strong candidate for removal.<br><br>What:<br> * Experimental targets/options.<br> * Experimental mono-repo projects (flang, libc, libclc, parallel-libs, polly, beduginfo-tests?, pstl?)<br> * Incubator projects (circt, mlir-npcomp, etc).<br> * Legacy tools (lnt).<br> * Alternative build systems (gn, bazel).<br> * Tool support (gdb scripts, editor configuration, helper scripts).<br><br>Requirements:<br> * Follow all core development policies on code quality, reviews, reverts, etc.<br> * Infrastructure that only notify its sub-community.<br> * Most not break tier 1, promptly reverting if it does, with discussions to be done offline before reapply.<br> * Leaner policy on bots being red for longer, as long as the sub-community has a roadmap to fix.<br> * Leaner policy on bitrot, as long as it doesn't impact tier 1 or other tier 2 projects.<br> * Should be easy to remove (either separate path, or clear impact in code).<br> * Must have a document making clear status, level of support and, if applicable, roadmap into tier 1 / out of LLVM.<br></div><div><br></div><div><div><br></div><div>cheers,</div><div>--renato</div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>