Renato Golin via llvm-dev
2020-Nov-02 23:49 UTC
[llvm-dev] Policy on support tiers, take 2
Right, that's a good split, I think. Only monorepo, minus experimental, unsupported build systems and helper files. I'll send another update tomorrow morning. Thanks everyone! On Mon, 2 Nov 2020, 20:38 Mehdi AMINI via llvm-dev, <llvm-dev at lists.llvm.org> wrote:> Hi, > > Nice proposal Renato! I'm very supportive of the direction in general. > > I share the sentiment of Eric and Geoffrey in general though. > In particular, it wasn't clear to me that something like flang for example > would be tier 2, I told the flang maintainer to feel free to revert my > patches when I break their bot for example. I assumed that every subproject > in the monorepo was supported as long as they have public bots. The only > explicit unsupported things are the experimental LLVM backends I believe? > > Thanks for iterating on this! :) > > Cheers, > > -- > Mehdi > > On Mon, Nov 2, 2020 at 12:33 PM Eric Christopher via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I think I'd work at a little higher level on the things. Explicit lists >> are hard to maintain and, in general, I think we're looking at guidelines >> rather than hard lists. >> >> -eric >> >> On Mon, Nov 2, 2020 at 3:27 PM Geoffrey Martin-Noble <gcmn at google.com> >> wrote: >> >>> I'm not super familiar with all the various subprojects, but I'd be a >>> little hesitant to put e.g. libc and flang in the same category as vim >>> bindings or the gn build :-D I think I've had failing pre-merge checks from >>> both flang and polly before, so at least in practice they don't seem to be >>> following the guidelines you mention here. I don't know whether this means >>> that they should just be moved up to tier 1, or whether they are actually >>> less-supported than some of the more established projects. If their current >>> behavior should change, then that seems like a bigger discussion. >>> >>> I also think it might be better to make this focus specifically on the >>> monorepo. Incubator projects already have a clear policy and a lot of the >>> fine points here only make sense in the context of the monorepo. e.g. bots >>> with blamelists targeting only a subcommunity doesn't make much sense for a >>> separate repo. If you committed the the mlir-npcomp repo I think you should >>> get notified if you broke something :-D >>> >>> Apologies if the below falls into the category of "writing", but here >>> are some additional thoughts: >>> >>> I also think that the distinction we previously had with tier 2 vs tier >>> 3 was useful in terms of differentiating things that need quite a bit of >>> promised support to be allowed in the monorepo because they're bigger, more >>> complicated, and require constant maintenance (e.g build systems) vs things >>> that can be checked in without much discussion because they are small, >>> simple, and degrade gracefully (e.g. editor bindings). Maybe separate tiers >>> isn't the right way to do that, but I think we should make that distinction >>> clear. Like if someone wants to check in bindings for their editor of >>> choice, a simple patch seems appropriate, whereas if someone >>> (hypothetically ;-P) wants to propose a secondary build system it should at >>> least be discussed on the mailing list. Maybe we can just include language >>> in the description of tier 2, like: >>> >>> When adding components intending for tier 2 status, the level of >>> discussion and support commitment required is proportional to the size and >>> complexity of the component. For example: >>> 1. editor bindings can be just be added as a patch following the normal >>> review process >>> 2. more complex components like a secondary build system should start as >>> an RFC that details how this component will be supported >>> 3. Experimental backends have an entire section on their introduction >>> (link) >>> >>> On Mon, Nov 2, 2020 at 11:58 AM Renato Golin <rengolin at gmail.com> wrote: >>> >>>> Ok, so after some feedback, here's an updated version. Separate thread >>>> as the previous got split. >>>> >>>> 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. >>>> >>>> I have joined tiers 2 and 3 and made explicit the three criteria they >>>> fit into, with the requirements more formally explained. >>>> >>>> Please review the sub-project lists on the two tiers, I'm not so sure >>>> about them. >>>> >>>> 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). >>>> >>>> Here it goes: >>>> >>>> *** Tier 1: the core compiler, officially supported by the community. >>>> >>>> Rationale: >>>> * Common code that supports most projects, upstream and downstream >>>> forks and forms the toolchain itself. >>>> * Includes everything we release on all architectures and OSs we have >>>> releases on. >>>> >>>> What: >>>> * LLVM itself, clang/tools, compiler-rt, libcxx/abi/unwind, lld, lldb, >>>> openmp, mlir. >>>> * Basically everything inside the mono-repo that is not in tier 2. >>>> * Builds on all first class citizen combinations of targets x OSs >>>> (incl. test-suite). >>>> * The CMake build infrastructure and release scripts. >>>> * Phabricator & Buildbot infrastructure. >>>> * The test-suite repository. >>>> >>>> Requirements: >>>> * Follow all core development policies on code quality, reviews, >>>> reverts, etc. >>>> * Noisy green buildbots, emailing all developers. >>>> * Most not be broken by changes in tier 2 (ex. if they require tier 1 >>>> changes). >>>> * Bitrot will downgrade areas to tier 2 or be removed, depending if a >>>> sub-community picks up support and has a timeline to fix. >>>> >>>> *** Tier 2: side projects that integrate with the compiler and that >>>> *should* work at all times. >>>> >>>> Rationale: >>>> * Code that is making its way into LLVM core (tier 1) via >>>> experimental/incubator roadmaps, or; >>>> * Code that isn't meant to be in LLVM core, but has a sub-community >>>> that maintains it long term, or; >>>> * Code that is making its way out of LLVM core (legacy) and that is a >>>> strong candidate for removal. >>>> >>>> What: >>>> * Experimental targets/options. >>>> * Experimental mono-repo projects (flang, libc, libclc, parallel-libs, >>>> polly, beduginfo-tests?, pstl?) >>>> * Incubator projects (circt, mlir-npcomp, etc). >>>> * Legacy tools (lnt). >>>> * Alternative build systems (gn, bazel). >>>> * Tool support (gdb scripts, editor configuration, helper scripts). >>>> >>>> Requirements: >>>> * Follow all core development policies on code quality, reviews, >>>> reverts, etc. >>>> * Infrastructure that only notify its sub-community. >>>> * Most not break tier 1, promptly reverting if it does, with >>>> discussions to be done offline before reapply. >>>> * Leaner policy on bots being red for longer, as long as the >>>> sub-community has a roadmap to fix. >>>> * Leaner policy on bitrot, as long as it doesn't impact tier 1 or >>>> other tier 2 projects. >>>> * Should be easy to remove (either separate path, or clear impact in >>>> code). >>>> * Must have a document making clear status, level of support and, if >>>> applicable, roadmap into tier 1 / out of LLVM. >>>> >>>> >>>> cheers, >>>> --renato >>>> >>> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201102/62d06c53/attachment.html>
Eric Christopher via llvm-dev
2020-Nov-02 23:56 UTC
[llvm-dev] Policy on support tiers, take 2
Sounds good, thanks! :) -eric On Mon, Nov 2, 2020 at 6:49 PM Renato Golin <rengolin at gmail.com> wrote:> Right, that's a good split, I think. Only monorepo, minus experimental, > unsupported build systems and helper files. > > I'll send another update tomorrow morning. > > Thanks everyone! > > On Mon, 2 Nov 2020, 20:38 Mehdi AMINI via llvm-dev, < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> Nice proposal Renato! I'm very supportive of the direction in general. >> >> I share the sentiment of Eric and Geoffrey in general though. >> In particular, it wasn't clear to me that something like flang for >> example would be tier 2, I told the flang maintainer to feel free to revert >> my patches when I break their bot for example. I assumed that every >> subproject in the monorepo was supported as long as they have public bots. >> The only explicit unsupported things are the experimental LLVM backends I >> believe? >> >> Thanks for iterating on this! :) >> >> Cheers, >> >> -- >> Mehdi >> >> On Mon, Nov 2, 2020 at 12:33 PM Eric Christopher via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> I think I'd work at a little higher level on the things. Explicit lists >>> are hard to maintain and, in general, I think we're looking at guidelines >>> rather than hard lists. >>> >>> -eric >>> >>> On Mon, Nov 2, 2020 at 3:27 PM Geoffrey Martin-Noble <gcmn at google.com> >>> wrote: >>> >>>> I'm not super familiar with all the various subprojects, but I'd be a >>>> little hesitant to put e.g. libc and flang in the same category as vim >>>> bindings or the gn build :-D I think I've had failing pre-merge checks from >>>> both flang and polly before, so at least in practice they don't seem to be >>>> following the guidelines you mention here. I don't know whether this means >>>> that they should just be moved up to tier 1, or whether they are actually >>>> less-supported than some of the more established projects. If their current >>>> behavior should change, then that seems like a bigger discussion. >>>> >>>> I also think it might be better to make this focus specifically on the >>>> monorepo. Incubator projects already have a clear policy and a lot of the >>>> fine points here only make sense in the context of the monorepo. e.g. bots >>>> with blamelists targeting only a subcommunity doesn't make much sense for a >>>> separate repo. If you committed the the mlir-npcomp repo I think you should >>>> get notified if you broke something :-D >>>> >>>> Apologies if the below falls into the category of "writing", but here >>>> are some additional thoughts: >>>> >>>> I also think that the distinction we previously had with tier 2 vs tier >>>> 3 was useful in terms of differentiating things that need quite a bit of >>>> promised support to be allowed in the monorepo because they're bigger, more >>>> complicated, and require constant maintenance (e.g build systems) vs things >>>> that can be checked in without much discussion because they are small, >>>> simple, and degrade gracefully (e.g. editor bindings). Maybe separate tiers >>>> isn't the right way to do that, but I think we should make that distinction >>>> clear. Like if someone wants to check in bindings for their editor of >>>> choice, a simple patch seems appropriate, whereas if someone >>>> (hypothetically ;-P) wants to propose a secondary build system it should at >>>> least be discussed on the mailing list. Maybe we can just include language >>>> in the description of tier 2, like: >>>> >>>> When adding components intending for tier 2 status, the level of >>>> discussion and support commitment required is proportional to the size and >>>> complexity of the component. For example: >>>> 1. editor bindings can be just be added as a patch following the normal >>>> review process >>>> 2. more complex components like a secondary build system should start >>>> as an RFC that details how this component will be supported >>>> 3. Experimental backends have an entire section on their introduction >>>> (link) >>>> >>>> On Mon, Nov 2, 2020 at 11:58 AM Renato Golin <rengolin at gmail.com> >>>> wrote: >>>> >>>>> Ok, so after some feedback, here's an updated version. Separate thread >>>>> as the previous got split. >>>>> >>>>> 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. >>>>> >>>>> I have joined tiers 2 and 3 and made explicit the three criteria they >>>>> fit into, with the requirements more formally explained. >>>>> >>>>> Please review the sub-project lists on the two tiers, I'm not so sure >>>>> about them. >>>>> >>>>> 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). >>>>> >>>>> Here it goes: >>>>> >>>>> *** Tier 1: the core compiler, officially supported by the community. >>>>> >>>>> Rationale: >>>>> * Common code that supports most projects, upstream and downstream >>>>> forks and forms the toolchain itself. >>>>> * Includes everything we release on all architectures and OSs we have >>>>> releases on. >>>>> >>>>> What: >>>>> * LLVM itself, clang/tools, compiler-rt, libcxx/abi/unwind, lld, >>>>> lldb, openmp, mlir. >>>>> * Basically everything inside the mono-repo that is not in tier 2. >>>>> * Builds on all first class citizen combinations of targets x OSs >>>>> (incl. test-suite). >>>>> * The CMake build infrastructure and release scripts. >>>>> * Phabricator & Buildbot infrastructure. >>>>> * The test-suite repository. >>>>> >>>>> Requirements: >>>>> * Follow all core development policies on code quality, reviews, >>>>> reverts, etc. >>>>> * Noisy green buildbots, emailing all developers. >>>>> * Most not be broken by changes in tier 2 (ex. if they require tier 1 >>>>> changes). >>>>> * Bitrot will downgrade areas to tier 2 or be removed, depending if a >>>>> sub-community picks up support and has a timeline to fix. >>>>> >>>>> *** Tier 2: side projects that integrate with the compiler and that >>>>> *should* work at all times. >>>>> >>>>> Rationale: >>>>> * Code that is making its way into LLVM core (tier 1) via >>>>> experimental/incubator roadmaps, or; >>>>> * Code that isn't meant to be in LLVM core, but has a sub-community >>>>> that maintains it long term, or; >>>>> * Code that is making its way out of LLVM core (legacy) and that is a >>>>> strong candidate for removal. >>>>> >>>>> What: >>>>> * Experimental targets/options. >>>>> * Experimental mono-repo projects (flang, libc, libclc, >>>>> parallel-libs, polly, beduginfo-tests?, pstl?) >>>>> * Incubator projects (circt, mlir-npcomp, etc). >>>>> * Legacy tools (lnt). >>>>> * Alternative build systems (gn, bazel). >>>>> * Tool support (gdb scripts, editor configuration, helper scripts). >>>>> >>>>> Requirements: >>>>> * Follow all core development policies on code quality, reviews, >>>>> reverts, etc. >>>>> * Infrastructure that only notify its sub-community. >>>>> * Most not break tier 1, promptly reverting if it does, with >>>>> discussions to be done offline before reapply. >>>>> * Leaner policy on bots being red for longer, as long as the >>>>> sub-community has a roadmap to fix. >>>>> * Leaner policy on bitrot, as long as it doesn't impact tier 1 or >>>>> other tier 2 projects. >>>>> * Should be easy to remove (either separate path, or clear impact in >>>>> code). >>>>> * Must have a document making clear status, level of support and, if >>>>> applicable, roadmap into tier 1 / out of LLVM. >>>>> >>>>> >>>>> cheers, >>>>> --renato >>>>> >>>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201102/0c14b31c/attachment-0001.html>
Philip Reames via llvm-dev
2020-Nov-03 17:25 UTC
[llvm-dev] Policy on support tiers, take 2
Just want to chime in with support. I like the general direction and agree with the suggest tweaks mentioned so far in this thread. Philip On 11/2/2020 3:56 PM, Eric Christopher via llvm-dev wrote:> Sounds good, thanks! :) > > -eric > > On Mon, Nov 2, 2020 at 6:49 PM Renato Golin <rengolin at gmail.com > <mailto:rengolin at gmail.com>> wrote: > > Right, that's a good split, I think. Only monorepo, minus > experimental, unsupported build systems and helper files. > > I'll send another update tomorrow morning. > > Thanks everyone! > > On Mon, 2 Nov 2020, 20:38 Mehdi AMINI via llvm-dev, > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Hi, > > Nice proposal Renato! I'm very supportive of the direction in > general. > > I share the sentiment of Eric and Geoffrey in general though. > In particular, it wasn't clear to me that something like flang > for example would be tier 2, I told the flang maintainer to > feel free to revert my patches when I break their bot for > example. I assumed that every subproject in the monorepo was > supported as long as they have public bots. The only explicit > unsupported things are the experimental LLVM backends I believe? > > Thanks for iterating on this! :) > > Cheers, > > -- > Mehdi > > On Mon, Nov 2, 2020 at 12:33 PM Eric Christopher via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > I think I'd work at a little higher level on the things. > Explicit lists are hard to maintain and, in general, I > think we're looking at guidelines rather than hard lists. > > -eric > > On Mon, Nov 2, 2020 at 3:27 PM Geoffrey Martin-Noble > <gcmn at google.com <mailto:gcmn at google.com>> wrote: > > I'm not super familiar with all the various > subprojects, but I'd be a little hesitant to put e.g. > libc and flang in the same category as vim bindings or > the gn build :-D I think I've had failing pre-merge > checks from both flang and polly before, so at least > in practice they don't seem to be following the > guidelines you mention here. I don't know whether this > means that they should just be moved up to tier 1, or > whether they are actually less-supported than some of > the more established projects. If their current > behavior should change, then that seems like a bigger > discussion. > > I also think it might be better to make this focus > specifically on the monorepo. Incubator projects > already have a clear policy and a lot of the fine > points here only make sense in the context of the > monorepo. e.g. bots with blamelists targeting only a > subcommunity doesn't make much sense for a separate > repo. If you committed the the mlir-npcomp repo I > think you should get notified if you broke something :-D > > Apologies if the below falls into the category of > "writing", but here are some additional thoughts: > > I also think that the distinction we previously had > with tier 2 vs tier 3 was useful in terms of > differentiating things that need quite a bit of > promised support to be allowed in the monorepo because > they're bigger, more complicated, and require constant > maintenance (e.g build systems) vs things that can be > checked in without much discussion because they are > small, simple, and degrade gracefully (e.g. editor > bindings). Maybe separate tiers isn't the right way to > do that, but I think we should make that distinction > clear. Like if someone wants to check in bindings for > their editor of choice, a simple patch seems > appropriate, whereas if someone (hypothetically ;-P) > wants to propose a secondary build system it should at > least be discussed on the mailing list. Maybe we can > just include language in the description of tier 2, like: > > When adding components intending for tier 2 status, > the level of discussion and support commitment > required is proportional to the size and complexity of > the component. For example: > 1. editor bindings can be just be added as a patch > following the normal review process > 2. more complex components like a secondary build > system should start as an RFC that details how this > component will be supported > 3. Experimental backends have an entire section on > their introduction (link) > > On Mon, Nov 2, 2020 at 11:58 AM Renato Golin > <rengolin at gmail.com <mailto:rengolin at gmail.com>> wrote: > > Ok, so after some feedback, here's an updated > version. Separate thread as the previous got split. > > 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. > > I have joined tiers 2 and 3 and made explicit the > three criteria they fit into, with the > requirements more formally explained. > > Please review the sub-project lists on the two > tiers, I'm not so sure about them. > > 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). > > Here it goes: > > *** Tier 1: the core compiler, officially > supported by the community. > > Rationale: > * Common code that supports most projects, > upstream and downstream forks and forms the > toolchain itself. > * Includes everything we release on all > architectures and OSs we have releases on. > > What: > * LLVM itself, clang/tools, compiler-rt, > libcxx/abi/unwind, lld, lldb, openmp, mlir. > * Basically everything inside the mono-repo that > is not in tier 2. > * Builds on all first class citizen combinations > of targets x OSs (incl. test-suite). > * The CMake build infrastructure and release scripts. > * Phabricator & Buildbot infrastructure. > * The test-suite repository. > > Requirements: > * Follow all core development policies on code > quality, reviews, reverts, etc. > * Noisy green buildbots, emailing all developers. > * Most not be broken by changes in tier 2 (ex. if > they require tier 1 changes). > * Bitrot will downgrade areas to tier 2 or be > removed, depending if a sub-community picks up > support and has a timeline to fix. > > *** Tier 2: side projects that integrate with the > compiler and that *should* work at all times. > > Rationale: > * Code that is making its way into LLVM core > (tier 1) via experimental/incubator roadmaps, or; > * Code that isn't meant to be in LLVM core, but > has a sub-community that maintains it long term, or; > * Code that is making its way out of LLVM core > (legacy) and that is a strong candidate for removal. > > What: > * Experimental targets/options. > * Experimental mono-repo projects (flang, libc, > libclc, parallel-libs, polly, beduginfo-tests?, pstl?) > * Incubator projects (circt, mlir-npcomp, etc). > * Legacy tools (lnt). > * Alternative build systems (gn, bazel). > * Tool support (gdb scripts, editor > configuration, helper scripts). > > Requirements: > * Follow all core development policies on code > quality, reviews, reverts, etc. > * Infrastructure that only notify its sub-community. > * Most not break tier 1, promptly reverting if it > does, with discussions to be done offline before > reapply. > * Leaner policy on bots being red for longer, as > long as the sub-community has a roadmap to fix. > * Leaner policy on bitrot, as long as it doesn't > impact tier 1 or other tier 2 projects. > * Should be easy to remove (either separate path, > or clear impact in code). > * Must have a document making clear status, level > of support and, if applicable, roadmap into tier 1 > / out of LLVM. > > > cheers, > --renato > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201103/6e36cc30/attachment.html>