I’m on this. We have most of the infrastructure up, it’s just a matter of tying up some ends before we get regular reports. I’ll let you folks know more about the bot once it is doing something.
Sean > On Nov 19, 2014, at 3:03 PM, jing...@apple.com wrote: > > 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 _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
