<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 9, 2017, at 13:43, Chris Bieneman <<a href="mailto:beanz@apple.com" class="">beanz@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 9, 2017, at 12:09 PM, Jordan Rose via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi, Chris. I’m a bit confused by these changes. Swift’s master-next isn’t paired with upstream-with-swift; it’s paired with stable-next, which is resync’d to upstream-with-swift on a <i class="">fairly</i> regular cadence. Have you discussed this with the “merge czars” on the Swift side, who maintain master-next and stable-next?</div></div></div></blockquote><div class=""><br class=""></div><div class="">This has been discussed with the “merge czars”, and we may end up creating a stable-next branch, but Bob Wilson suggested that they were considering changes to the merge process that would eliminate the need for that branch.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">“upstream-with-trunk” is redundant; the “upstream” referred to in “upstream-with-swift” <i class="">is</i> LLVM trunk. “upstream-plus-swift-support” might have been a better name for the LLVM branch.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I mis-wrote that. It is “upstream-with-<i class="">swift</i>” not trunk. The LLDB “upstream” branch will be going away because it is unnecessary to maintain a branch that matches <a href="http://llvm.org/" class="">LLVM.org</a>.</div></div></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>Thanks for the clarification! </div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">What happens on the LLDB “stable" branch? No development happens on LLVM or Clang’s “stable” branch; they’re essentially just aliases for the latest release branch. Does the LLDB “stable” branch build against Swift master or Swift’s latest release branch?</div></div></div></blockquote><div class=""><br class=""></div><div class="">LLDB’s stable branch will be maintained in exactly the same way LLVM & Clang’s stable branches are. So it is currently identical to the swift-4.0-branch.</div></div></div></div></blockquote><div><br class=""></div><div>I’m concerned because this means LLDB “stable" builds against Swift master, while the release branches all build together. It’s frequent for changes to go into Swift master that are <i class="">not</i> immediately cherry-picked to the latest release branch.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">When I change something on Swift master that affects LLDB, where do I send a pull request going forward? It would be very painful for Swift developers to have a master-next/stable-next build set up just to submit changes to LLDB; today, most Swift developers don’t even need to think about master-next unless something breaks.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Patches to LLDB for swift-related functionality should go into the most current release branch, in the same way we handle LLVM & Clang changes.</div></div></div></div></blockquote><br class=""></div><div>Sorry, I don’t mean “patches for LLDB that add or change Swift functionality”. I mean “a Swift API changed, here’s a patch so that LLDB can continue building”. Admittedly we are not always good about this, but if the place to submit LLDB patches isn’t the standard build configuration for Swift, I think we’ll be much less likely to submit any at all. We get away with this for Clang and LLVM because (a) they do not have any pieces that depend on Swift, and (b) very few people make Swift-related changes in Clang and LLVM, so it’s okay if the process is a little awkward.</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>