I think Sean & Adrian are working on this. Sean's out today, but I'll ask him tomorrow.
Jim > On Nov 19, 2014, at 3:00 PM, Zachary Turner <ztur...@google.com> wrote: > > Reid mentioned watching the bots we already have. Is there any way to get a > Mac bot on there? Do you guys already have one that I'm not aware of that > maybe just needs to be hooked up? > > On Wed Nov 19 2014 at 2:58:48 PM <jing...@apple.com> wrote: > > > On Nov 19, 2014, at 1:12 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? > > +1 > > Jim > > > > > 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 > > > _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
