[lldb-dev] Managing Clang and LLVM dependencies systematically

[Reid Kleckner]

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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141119/5d8eb8bc/attachment.html>