<div dir="ltr"><div dir="ltr">On Tue, 17 Nov 2020 at 05:41, Tom Stellard via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* I still worry about the bazel files causing merging conflicts when <br>
backported to the stable branch.  If these are added to tree, could we<br>
have a rule where commits to utils/bazel/ cannot include changes to<br>
other files?<br></blockquote><div><br></div><div>That's usually the policy for other non-code changes, but I agree that with build system components, this is specially important.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Expanding on this last point a little bit, this raises some larger <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
questions about what code should be allowed in tree.  Essentially what <br>
we have here is that a critical part of the LLVM project has been <br>
re-implemented and is now being asked to be included in tree alongside <br>
the original implementation (CMake).  There are parts of the codebase <br>
where this would clearly not be OK (e.g. a re-implementation of one of <br>
the backends), but for build systems I think you can make a valid case <br>
to either have it or not to have it.<br></blockquote><div><br></div><div>We have examples of competing front-ends (the three different "flang" projects), middle-end infrastructure (the new pass manager), back-ends (the two arm64 targets) and build systems (automake/CMake).<br></div><div><br></div><div>But in all examples above, the sub-communities involved agreed on replacing the flang implementation (twice), concurrently developing the new pass manager and merging the two arm64 backends. We also have elected to keep CMake over automake. </div><div><div><br></div><div>Those efforts were always with the intention to replace and not to co-exist. So none of our priors are close enough. </div><div><br></div><div>However, those are all things that we have considered to be "core tier". We should now consider a "peripheral tier" that would be ok with co-existence, as long as they follow the support policy.</div><div><br></div><div>For your specific point about stable releases, breaking them would be a major failure to follow the policy, so we need to make sure that doesn't happen.</div><div></div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">And this is why I think it should be a pitch.  In my opinion, these <br>
kinds of higher-level decisions are better made by review managers than <br>
by people on the mailing list.<br></blockquote><div><br></div><div>There should be an 100% overlap between those two groups. :)</div><div><br></div><div>And their views on this subject would be invaluable to the discussion. It'd be beneficial to all if they could chime in.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The other nice thing about a pitch is that we don't need to spend days <br>
arguing about this on the mailing list.  You can take my feedback, think <br>
about it, and if you think there is some validity to what I have said, <br>
then all you need to do is update your proposal to address my concerns.<br>
And if not, then you can just move on to the next email.<br></blockquote><div><br></div><div>That is true. It would be nice to have a document that reflects the latest updates on the discussion.</div><div><br></div><div>cheers,</div><div>--renato</div></div></div>