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 https://github.com/chapuni/llvm-project, which is a git repo which is exactly for this purpose, and AFAIK is automatically maintained to ToT and has no limitations.
On Wed Nov 19 2014 at 1:12:02 PM Reid Kleckner <r...@google.com> wrote: > I don't think Chromium's dependency rolling model is a good fit for the > way that LLDB should consume Clang/LLVM. > > 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. > > 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. > > In short, what I really think we need is: > - More stable LLDB tests with more signal and less noise > - More visibility into LLDB build and test failures for Clang and LLVM > developers > > Rather than spending time managing blessed revisions, I would rather spend > resources watching the bots we already have ( > http://lab.llvm.org:8011/builders/lldb-x86_64-debian-clang, > http://lab.llvm.org:8011/builders/lldb-x86_64-freebsd) and pinging > developers on email and IRC to fix regressions. In other words, take a > harder stance on breakage. > > Does that seem reasonable? > > On Wed, Nov 19, 2014 at 11:09 AM, Vince Harron <vhar...@google.com> wrote: > >> We completely agree that there should be a continuous build with >> top-of-everything. >> >> 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. >> >> 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. >> >> 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. >> >> 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. >> >> Thanks, >> >> Vince >> >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
