[lldb-dev] Managing Clang and LLVM dependencies systematically

[Zachary Turner]

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 <jingham at apple.com> wrote:

>
> > On Nov 19, 2014, at 1:12 PM, Reid Kleckner <rnk at 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 <vharron at 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 at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141119/c887654f/attachment.html>