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