I think one of the use cases they were trying to solve was being able to bisect and find which change caused a particular break.  It might be worth mentioning <a href="https://github.com/chapuni/llvm-project">https://github.com/chapuni/llvm-project</a>, which is a git repo which is exactly for this purpose, and AFAIK is automatically maintained to ToT and has no limitations.<br><br><div class="gmail_quote">On Wed Nov 19 2014 at 1:12:02 PM Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I don't think Chromium's dependency rolling model is a good fit for the way that LLDB should consume Clang/LLVM.<div><br></div><div>I would say that Chromium is to Blink as LLDB is to Clang. Both are run under the same parent umbrella project. However, I've been lead to understand that Blink rolls are a huge pain, and Chromium is actively moving away from this model by attempting to merge the repositories.</div><div><br></div><div>I'm not proposing merging LLDB and Clang repos, but I would say that we should consider them part of the same project. If Clang changes break LLDB, then there is a burden on the Clang developer to to fix LLDB promptly or find someone with more LLDB knowledge if the fix isn't trivial. This is the relationship that Clang already has to LLVM. It's OK for LLVM to break Clang, and it should be OK for Clang to break LLDB, so long as it's fixed promptly. If the fix isn't prompt, it's OK to start reverting to get back to green.</div><div><br></div><div>In short, what I really think we need is:</div><div>- More stable LLDB tests with more signal and less noise</div><div>- More visibility into LLDB build and test failures for Clang and LLVM developers</div><div><br></div><div>Rather than spending time managing blessed revisions, I would rather spend resources watching the bots we already have (<a href="http://lab.llvm.org:8011/builders/lldb-x86_64-debian-clang" target="_blank">http://lab.llvm.org:8011/builders/lldb-x86_64-debian-clang</a>, <a href="http://lab.llvm.org:8011/builders/lldb-x86_64-freebsd" target="_blank">http://lab.llvm.org:8011/builders/lldb-x86_64-freebsd</a>) and pinging developers on email and IRC to fix regressions. In other words, take a harder stance on breakage.</div><div><br></div><div>Does that seem reasonable?</div></div><div dir="ltr"><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 19, 2014 at 11:09 AM, Vince Harron <span dir="ltr"><<a href="mailto:vharron@google.com" target="_blank">vharron@google.com</a>></span> wrote:<br><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 dir="ltr"><div>We completely agree that there should be a continuous build with top-of-everything.</div><div><br></div><div>We're looking to *add* a continuous lldb build with the curated versions of llvm/clang.  I think this will help lldb developers with the signal to noise ratio.  (Separating their breaks from clang/llvm breaks)  I can probably get some CPU time for this new build.</div><div><br></div><div>Chromium does a similar thing with their multitude of open source dependencies.  Siva was explaining to me that there is a engineer "gardener" that updates the working versions file daily (we could do weekly) by looking for successful "top-of-everything" builds.  The "gardener" responsibility is handed off in rotation.</div><div><br></div><div>Why don't we do this as a trial.  We will setup the hardware (linux at least) and take responsibility for gardening.  We would like our build slave to be triggered by the llvm buildbot master.  </div><div><br></div><div>If there is value in this to the community, we'll expand the gardening responsibilities.  We can also update the public lldb build instructions to use the curated build script.</div><div><br></div><div><div>Thanks,<br></div></div><div><br></div><div>Vince</div></div></blockquote></div></div></div></div></blockquote></div>