You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spark.apache.org by Patrick Wendell <pw...@gmail.com> on 2015/08/05 20:24:56 UTC
Avoiding unnecessary build changes until tests are in better shape
Hey All,
Was wondering if people would be willing to avoid merging build
changes until we have put the tests in better shape. The reason is
that build changes are the most likely to cause downstream issues with
the test matrix and it's very difficult to reverse engineer which
patches caused which problems when the tests are not in a stable
state. For instance, the updates to Hive 1.2.1 caused cascading
failures that have lasted several days now and in the mean time a few
other build related patches were also merged - as these pile up it
gets harder for us to have confidence those other patches didn't
introduce problems.
https://amplab.cs.berkeley.edu/jenkins/view/Spark-QA-Test/
- Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@spark.apache.org
For additional commands, e-mail: dev-help@spark.apache.org
Re: Avoiding unnecessary build changes until tests are in better
shape
Posted by Josh Rosen <ro...@gmail.com>.
+1. I've been holding off on reviewing / merging patches like the
run-tests-jenkins Python refactoring for exactly this reason.
On 8/5/15 11:24 AM, Patrick Wendell wrote:
> Hey All,
>
> Was wondering if people would be willing to avoid merging build
> changes until we have put the tests in better shape. The reason is
> that build changes are the most likely to cause downstream issues with
> the test matrix and it's very difficult to reverse engineer which
> patches caused which problems when the tests are not in a stable
> state. For instance, the updates to Hive 1.2.1 caused cascading
> failures that have lasted several days now and in the mean time a few
> other build related patches were also merged - as these pile up it
> gets harder for us to have confidence those other patches didn't
> introduce problems.
>
> https://amplab.cs.berkeley.edu/jenkins/view/Spark-QA-Test/
>
> - Patrick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@spark.apache.org
> For additional commands, e-mail: dev-help@spark.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@spark.apache.org
For additional commands, e-mail: dev-help@spark.apache.org