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>
Renato Golin via llvm-dev
2020-Nov-04 13:45 UTC
[llvm-dev] Policy on support tiers, take 2
Thanks Philip! First draft at: https://reviews.llvm.org/D90761 Feel free to copy more people. cheers, --renato On Tue, 3 Nov 2020 at 17:25, Philip Reames <listmail at philipreames.com> wrote:> 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> 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 >>> >> > _______________________________________________ > LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://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/20201104/151de138/attachment.html>
Chris Tetreault via llvm-dev
2020-Nov-04 19:57 UTC
[llvm-dev] Policy on support tiers, take 2
I took a look and left some comments, but overall it’s looking good to me. I just wanted to say thank you very much for driving this! Thank you, Christopher Tetreault From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Renato Golin via llvm-dev Sent: Wednesday, November 4, 2020 5:45 AM To: Philip Reames <listmail at philipreames.com> Cc: LLVM Dev <llvm-dev at lists.llvm.org>; Mehdi Amini <aminim at google.com> Subject: [EXT] Re: [llvm-dev] Policy on support tiers, take 2 Thanks Philip! First draft at: https://reviews.llvm.org/D90761 Feel free to copy more people. cheers, --renato On Tue, 3 Nov 2020 at 17:25, Philip Reames <listmail at philipreames.com<mailto:listmail at philipreames.com>> wrote: 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<mailto: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/20201104/02af479a/attachment.html>