<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Apr 18, 2014, at 1:13 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 18, 2014 at 12:58 PM, "C. Bergström" <span dir="ltr"><<a href="mailto:cbergstrom@pathscale.com" target="_blank">cbergstrom@pathscale.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":iki" class="a3s" style="overflow:hidden">On 04/19/14 02:47 AM, Chandler Carruth wrote:<div><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Fri, Apr 18, 2014 at 12:22 PM, Evan Cheng <<a href="mailto:evan.cheng@apple.com" target="_blank">evan.cheng@apple.com</a> <mailto:<a href="mailto:evan.cheng@apple.com" target="_blank">evan.cheng@apple.com</a>>> wrote:<br>
<br>
I agree the top priority should always be "getting it right”. But<br>
I can’t agree with this thinking completely. This has to be<br>
balanced with pragmatism. If we completely disregard the practical<br>
concerns of commercial use, it makes LLVM hostile towards an<br>
important group of users.<br>
<br>
<br>
Clearly, I can't argue with that. =] We benefit from it as well. And I don't think I'm arguing against a pragmatic approach in this case, although I'm sorry if it comes off that way.<br>
<br>
Just so we're on the same page, the only real question in my mind is: can we make breaking changes as we iterate on the design.<br>
<br>
What I would like to do is figure out the right design first, incrementally, trying one format, and seeing how it does, but potentially with backwards incompatible changes. Once we have the experience and know what the right format is, *then* we should consider pragmatic concerns such as how to structure support for reading legacy formats, or formats outside of the control of the project. I think if we start off with a format that we can't change because of external reasons (whatever they may be), it will be much harder to incrementally get to the right design. Does that seem reasonable (and hopefully help explain the concrete suggestion I'm making)?<br>
</blockquote></div></div>
Why can't we have our cake and eat it too?<br>
<br>
Off the cuff and flame away<br>
------------<br>
What's wrong with a soft policy like - Feel free to do an incremental improvement which breaks a change and then if someone else wants to contribute a patch that allows the old format/behavior - that's up to them (patches welcome). Both changes would be accepted and allows the parallel paths - (putting the burden of maintenance for backward compatibility on those stakeholders). Wouldn't this solve the problem Right Now(tm)?<br>
</div></blockquote><div><br></div><div>I think its important that there remain incentives for the contributors to address design feedback that comes up in review essentially. Making it "patches welcome" right away, removes that incentive IMO, and would be a shame. Sometimes, its unavoidable, but I think the project is better when we hold that line.</div>
<div><br></div><div>As an example, when we wanted to contribute the AST matchers to Clang, is was really useful that it was entirely on us to address all of the (excellent) design review from Doug. It may not have mattered for our use cases, but it mattered that the not-quite-right solution didn't just sit rotting in mainline waiting for someone to take up the challenge of making it the right solution.</div>
<div><br></div><div>The pragmatic tradeoff here is to do it incrementally, so you don't have to leap to the right solution before the first patch lands. And I don't think there has been any pushback against that in this thread.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":iki" class="a3s" style="overflow:hidden">
<br>
I don't mean this as an attack<br>
It's very depressing to see passionate Apple vs Google people not be able to come to middle ground very quickly</div></blockquote></div><br>=] I think we're actually pretty close, and the discussion continues to be polite, and non-circular, so I'm not depressed yet.</div>
</div>
</blockquote><br></div><div>I’m not depressed either. The community is growing and I expect and respect the difference of opinions. As far as I can tell, we’re all focused on making LLVM better. We’ll sort this out.</div><div><br></div><div>Evan</div><br></body></html>