Renato, By your earlier requirements for tier 1, not seeing how tier 2 could break tier 1. If a file was in tier 2, it would not be in tier 1. There would be no action in tier 1 on tier 2 files to cause a break. What this may mean is that those working in tier 2 do not wander into tier 1, obscuring that distinction. Or that there may be some confusion about what was in tier 1 vs. 2. That in some manner the distinction becomes not well defined. Neil Nelson On 10/30/20 6:13 PM, Renato Golin via llvm-dev wrote:> But I wanted to express: "3 can't break 2 can't break 1", and make it > easier to drop silly scripts or config files if they're no longer > valid or maintained, more easily than dropping entire build systems.-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201030/d4820584/attachment.html>
Examples of tier 2 breaking 1 are when a change in its code need & warrant a change in common apis (in tier 1), and those changes break unrelated tier 1 code. I agree it's not super well defined, but I really think we shouldn't try to list what is in/out of each tier and I'm hoping people can help me define the scope of each. Questions like yours are super helpful to do just that. Thanks! Renato On Sat, 31 Oct 2020, 02:21 Neil Nelson via llvm-dev, < llvm-dev at lists.llvm.org> wrote:> Renato, > > By your earlier requirements for tier 1, not seeing how tier 2 could break > tier 1. If a file was in tier 2, it would not be in tier 1. There would be > no action in tier 1 on tier 2 files to cause a break. > > What this may mean is that those working in tier 2 do not wander into tier > 1, obscuring that distinction. Or that there may be some confusion about > what was in tier 1 vs. 2. That in some manner the distinction becomes not > well defined. > > Neil Nelson > On 10/30/20 6:13 PM, Renato Golin via llvm-dev wrote: > > But I wanted to express: "3 can't break 2 can't break 1", and make it > easier to drop silly scripts or config files if they're no longer valid or > maintained, more easily than dropping entire build systems. > > _______________________________________________ > 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/20201031/5c80b522/attachment.html>
On 31/10/2020 09:03, Renato Golin via llvm-dev wrote:> Examples of tier 2 breaking 1 are when a change in its code need & > warrant a change in common apis (in tier 1), and those changes break > unrelated tier 1 code. > > I agree it's not super well defined, but I really think we shouldn't try > to list what is in/out of each tier and I'm hoping people can help me > define the scope of each. > > Questions like yours are super helpful to do just that. > > Thanks! > Renato >Reading this, I'm not suggesting any change to policy, but simply to the "official" wording. Let's do something along the lines of Tier 1 is LLVM. Tier 2 is Clang, and Cmake, and all the other stuff that was mentioned that is a first class citizen and supported as part of the project. Tier 3 is maybe incubator projects heading for tier 2 Tier 4 is projects like Bazel which we have no intention of supporting but are best supported as part of the project ... Then we define all our policies along the lines of No tier should trigger warnings or errors in a higher tier. If a tier requires changes in a higher tier, they are responsible for making those changes (bit like if you change an API in the kernel, you have to fix everywhere else). And so on. That way, the rules are consistent everywhere, and if some other class of project appears, we can just slot them straight in by creating a new tier. Cheers, Wol