I've made a point of prioritizing getting our tests to run cleanly here, so it would be a good time for the community to do likewise for other platforms. Among other benefits, Improving the signal/noise ratio for test failures will make the message to LLVM a lot clearer.
Kate Stone k8st...@apple.com Xcode Runtime Analysis Tools > On Nov 18, 2014, at 4:57 PM, Reid Kleckner <r...@google.com> wrote: > >> On Tue, Nov 18, 2014 at 3:15 PM, <jing...@apple.com> wrote: >> I actually think it is good that incompatible changes to llvm break the lldb >> build bots right away. Then they will get fixed in lldb right after the >> change was made when it is clear in people's minds what just went on. So I >> wouldn't want to add any of this sort of machinery to lldb's build w.r.t. >> the build bots. Now that the build-bots are running regularly, the clang >> folks can also see the breakage right away and just fix it, which they often >> do (thanks for that BTW...) So if there were a "GOOD_LLVM" it should not be >> used for the build-bots. > > +1, LLDB breakages need to be more visible to Clang/LLVM developers. > Currently they are not very visible, mostly for no good reason. > > Stabilizing the LLDB test suite would help, but the bots could probably be > more aggressive about sending IRC or email pings when the build (not tests) > fails, as this is the primary way that LLVM and Clang changes break LLDB. > _______________________________________________ > 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
