<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 30, 2019, at 2:50 AM, Rui Ueyama <<a href="mailto:ruiu@google.com" class="">ruiu@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="">(Sorry for not replying to this thread -- I was on a business trip last week.)</div></div></div></blockquote><div><br class=""></div><div>No worries! I’m guilty of ignoring the entire thread since February ;-)</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="">Thank you for sharing your concerns, JF. I share your concerns. I personally don't think my communication was improper, as I clearly expressed my intent to make that change, gave heads-ups multiple times, and the change was not committed in a rush. That being said, there's room for improvement. As you wrote, in hindsight, replying to a thread with 100+ posts was probably not ideal.</div></div></div></blockquote><div><br class=""></div><div>I completely understand how, in the thick of the discussion, you were doing what seems right and proper. All I’m getting at is that from the outside none of the changes in approach came through. I didn’t want to imply any malice or anything, sorry for sounding that way.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="">In addition to that, people might not have complained to me because I'm the code owner of lld subtree and as long as I'm editing files under the subtree they might not have cared too much about it (although I don't think I have any authority when it comes to the identifier naming style even within lld directory, and I don't have any intention to diverge from the LLVM's coding style.) LLVM and Clang are an order of magnitude larger than lld in many aspects including the number of people involved, the number of out-of-tree repos, the length of the history, etc. Naturally a sweeping change to LLVM/Clang would cause more concerns, and we need to address that before making a sweeping change.</div><div class=""><br class=""></div><div class="">It's not only you who requested me send a new RFC to the mailing list if I'm planning to roll this out to the entire repository, and that's definitely my next thing to do.</div></div></div></blockquote><div><br class=""></div><div>Great, I appreciate it.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div dir="ltr" class="">On Tue, Jul 30, 2019 at 8:57 AM Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>> wrote:<br class=""></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class="">On Jul 29, 2019, at 10:58 AM, JF Bastien <<a href="mailto:jfbastien@apple.com" target="_blank" class="">jfbastien@apple.com</a>> wrote:<br class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="overflow-wrap: break-word;" class=""><div class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; float: none; display: inline;" class="">I think that Rui rolled this out in an incredibly great way with LLD, incorporating a lot of community feedback and discussion, and (as you say) this thread has accumulated many posts and a lot of discussion, so I don’t see the concern about lack of communication.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none;" class=""></div></blockquote><div class=""><br class=""></div><div class="">I think there’s lack of proper communication for this effort. The RFC is all about variable naming, with 100+ responses. Sounds like a bikeshed I’ve happily ignored, and I know many others have. Even if you don’t think I’m right, I’d appreciate a separate RFC with details of what’s actually being proposed. Off the top of my head I’d expect at least these questions answered:</div><div class=""><br class=""></div><div class=""><ul class="gmail-m_96048065291096565MailOutline"><li class="">What’s the final naming convention?</li><li class="">Will we have tools to auto-flag code that doesn’t follow it, and can auto-fix it?</li><li class="">Will we clang-format everything while we’re at it?</li><li class="">Will we run clang modernizer to move code to C++11 / C++14 idioms while we’re doing all this?</li><li class="">What’s the timeline for this change?</li><li class="">Is it just a single huge commit?</li><li class="">After the monorepo and GitHub move?</li><li class="">Is there a dev meeting roundtable scheduled?</li><li class="">What tooling exists to ease transition?</li><li class="">Out-of-tree LLVM backends are a normal thing. They use internal LLVM APIs that should all be auto-updatable, has this been tried?</li><li class="">Some folks have significant non-upstream code. Have they signed up to remedy that situation before the deadline (either by upstreaming or trying out auto-update scripts)?</li></ul></div><div class=""><br class=""></div><div class="">LLD and LLDB are indeed good small-scale experiments. However, I think the rest of the project is quite different in the impact such a change would have. LLVM and clang expose many more C++ APIs, and have many more out-of-tree changes (either on top of upstream, or in sub-folders such as backends or clang tools). They also have many more contributors affected, and not all those contributors have the same constraints, making this much more complex. So far this discussion hasn’t seemed to care about these concerns, and I’m worried we’re about to burn a bunch of bridges. Maybe I missed this part of the discussion in the 100+ emails! Sorry if I did… but again, a simple updated RFC would solve everything.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Thanks for the detailed list here. I have no idea what the status of most of these are - it sounds like you’re generally asking “what is the plan?” beyond LLD. :-)</div><div class=""><br class=""></div><div class="">Rui, what are your thoughts on next steps? LLDB seems like a logical step, particularly because it uses its own naming convention that is completely unlike the rest of the project.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Besides sending a new RFC, I think the next step is to improve a tool so that a sweeping change can be created mechanically. I was actually trying to improve clang-tidy for the variable renaming; clang-tidy already has a feature to rename identifiers, but that doesn't work well for our purposes in various corner cases, and because of the size of the repository, there are lots of corner cases, so I need to improve it. Once the tool is done, I'd try to apply the tool to the *entire* repo to rename everything all at once to see if such change is feasible. If it's feasible, I'd think that's probably better for everybody including downstream repo maintainers.</div><div class=""><br class=""></div><div class="">But all in all, the next logical step is to start a new thread with a concrete proposal how we'd like to rename identifiers and how we'd like to do that, to get a more concrete consensus and address concerns.</div></div></div></div></blockquote><div><br class=""></div><div>Thank you.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote"><div class="">(FWIW, I built the head-of-the-tree git and tried to use `git blame --ignore-rev` to see how it works to lld, and it looks like it's working pretty well. I'll mention that in an RFC.)</div></div></div></div></blockquote><div><br class=""></div><div>Nice!</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><div class=""><div class="">-Chris</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="overflow-wrap: break-word;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; float: none; display: inline;" class="">The reason that I personally pivoted to believe that a “do everything all at once in one commit generated by Rui’s script” approach was the right thing was seeing how lld contributors were able to cleanly move forward even when they have significant out of tree changes - they merged to the N-1 commit, then ran Rui's script on *their* trees, and were caught up with commit N. This seems to have provided a very smooth transition path, where the conversion was merely a bump in the road, not a major mountain to climb over.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none;" class=""></div></blockquote><div class=""><br class=""></div><div class="">That sounds fine to me. I just want to make sure everyone knows they’re about to have to climb a little hill. Surprise hills are the worst.</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; float: none; display: inline;" class="">In any case, I hope that we as a community don’t end up in a place where we are afraid of doing sweeping changes that make the codebase better.</span></div></blockquote><div class=""><br class=""></div><div class="">Sure the current naming is ugly and inconsistent, but honestly I don’t really care about naming. The one upside I see from this change is the same clang-format has brought: we can finally stop picking nits and arguing about stuff that doesn’t matter.</div><div class=""><br class=""></div><div class="">I agree that we should be able to make sweeping changes. I’m saying that I don’t think the direction I see us going in right now seems like it’ll work out well, and it seems easy to address my worries.</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; float: none; display: inline;" class="">It is important to continually reinvest in the health of the codebase, and it isn’t bad to incentivize people to merge their changes upstream.</span></div></blockquote><div class=""><br class=""></div><div class="">Agreed. However, as you know very well, merging upstream changes isn’t something that’s done over a weekend. First people have to know that a large change is coming and they probably should plan for upstreaming. Second we should give these folks enough time to do the upstreaming, and leave them enough slack in case they fall behind.</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; float: none; display: inline;" class="">Being overwhelmingly afraid of ‘breaking history’ is a path that leads stagnation and ultimate replacement by newer technologies. There are many other projects that have suffered this fate, usually for a combination of reasons including things like this.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none;" class=""></div></blockquote></div><br class=""><div class="">Again, this concern is small compared to the others I’ve expressed. Let’s have it as one item on the list of things we want answers to before moving forward. I think the rest of what I’m raising is much more important.</div></div></div></blockquote></div></div></blockquote></div></div></div></blockquote></div><br class=""></body></html>