Just to be clear, im totally on board with the global timeout. It's the per-test override I'm not crazy about, since it doesn't matter much for the bot, and it's non-discoverable for the user. On Thu, Dec 18, 2014 at 8:34 AM Vince Harron <[email protected]> wrote:
> > And in addition to both of those, we really should be either fixing the > tests or disabling them. Now that this timeout is in, i have a feeling that > fixing the hanging tests will be de-prioritized. > > Currently there are tests that only hang on the debian buildbot. These > hangs obscure all other test failures. This patch was the only way to > figure out what those tests are. Unfortunately, they are not hanging > locally for us and are therefore not at the top of our priority list. We > could mark them as XFail, but we still need the timeout in in case this > happens again. > > Remember, without the timeout feature, if a single test hangs, you need to > surgically delete the hung test or you lose all test results. > > > On Thu, Dec 18, 2014 at 7:50 AM, Zachary Turner <[email protected]> > wrote: >> >> My concern, and the reason I brought it up, is because it seems like >> unnecessary complexity which only benefits a handful of people. I don't >> like adding complexity that isn't useful for a wide audience. >> >> If this is just for making your own local test suite terminate in a >> reasonable amount of time, then you can do that with an external shell >> script which you run when you notice it's hung. If the issue is not >> knowing >> it's hung, then we should change the test runner to print its output as >> the >> test suite runs instead of at the end (we should do this anyway actually >> because that's very useful). >> >> And in addition to both of those, we really should be either fixing the >> tests or disabling them. Now that this timeout is in, i have a feeling >> that >> fixing the hanging tests will be de-prioritized. >> >> Anyway, this patch is going in (or has gone in) for now, but I really >> don't >> want to see this timeout logic get any more complicated in its current >> form. >> >> >> http://reviews.llvm.org/D6669 >> >> EMAIL PREFERENCES >> http://reviews.llvm.org/settings/panel/emailpreferences/ >> >> >> > > -- > > Vince Harron | Technical Lead Manager | [email protected] | 858-442-0868 >
_______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
