<div dir="ltr">On Fri, Nov 8, 2013 at 8:49 AM,  <span dir="ltr"><<a href="mailto:dag@cray.com" target="_blank">dag@cray.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> writes:<br>
<br>
> The overwhelming majority of contributors and users of trunk seem to<br>
> be fine with this, so while I'm interested in anything we can do to<br>
> make it easier for you, unless we see significantly more concerns<br>
> about this plan, I think we should move forward.<br>
><br>
> Fundamentally, we aren't going to be able to make everyone happy. Some<br>
> people will be seriously inconvenienced by this, but thus far the<br>
> benefit seems to significantly outweigh the cost.<br>
<br>
</div>But the benefit is still there even if it takes a month or two longer.<br>
<br>
This is a *serious* issue.  It doesn't seem like people really<br>
comprehend the challenges of upgrading toolchains in large software<br>
projects.  We're talking about millions and millions of lines of code<br>
spread out over many independent modules.  These all have to fit<br>
together to create a usable tool.<br>
<br>
What is so hard about waiting an extra month to give people a chance to<br>
test the new toolchain?</blockquote><div><br></div><div>The options we're discussing seem to be:</div><div><br></div><div>1) Switch trunk to C++11 at time T. People whose toolchains aren't ready stop integrating from LLVM trunk until they are ready.</div>
<div>2) Switch trunk to C++11 at time T + an extra month. Again, people whose toolchains aren't ready stop integrating from LLVM trunk until they are ready.</div><div><br></div><div>For people who are paying attention to this thread, or to the release notes, or otherwise being engaged in the community, there seems to be very little difference. If they do (say) weekly integrates, that's *at most* three extra integrates they miss. That's unfortunate, but not huge.</div>
<div><br></div><div>For people who are *not* paying attention, this makes no difference at all: they're not going to start switching their toolchain until they notice a problem.</div><div><br></div><div>So I don't see that waiting is a significant win. Conversely, it gives us less time to get the C++11-enabled code tested across relevant toolchains (including perhaps rolling back the change if we find a fatal issue) before we release 3.5 next year.</div>
<div><br></div><div>Setting T = 3.4 release has another advantage: people who stop integrating then are stopped at a stable, well-tested revision, not after the inevitable post-release churn.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
> That said, while I'm about to commit the change to the release notes<br>
> and send a summary email to the dev lists, we should continue<br>
> discussing this. Nothing is going to be set in stone until the 3.4<br>
> release goes out, and maybe not even then. Especially if you or others<br>
> want to discuss this with me in person (or others in person) at the<br>
> dev meeting, I'm writing this email from the hacking session. =] Happy<br>
> to chat.<br>
<br>
</div>I'm not going to be at the dev meeting.<br>
<div class=""><div class="h5"><br>
                         -David<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>