not committing things that add HiveQA failures

[Sergey Shelukhin <se...@hortonworks.com>]

Hi. 
This has been happening a lot lately (and I have been guilty of that
myself…). We just fixed the LLAP test, and now I see a bunch of other
tests failing again in all the JIRAs now that didn’t fail as early as
yesterday.
In the past cases, I’ve seen HiveQA report failures that are ignored when
the patch is committed, and then these failures start happening in all the
JIRAs. It is understandable when people think failures are unrelated but
it often looks like noone even checked if they are.

How about we make sure to check the latest HiveQA run before committing a
patch, our own or somebody else’s? :)

Also should we have an expedited policy where it’s ok for a committer to
revert and reopen the patch that broken some tests first, and then ask
questions later?

Re: not committing things that add HiveQA failures

[Szehon Ho <sz...@cloudera.com>]

Yea I thought that has always been the agreed policy, to wait until HiveQA
doesn't report unexpected failures before checking in, it should be
strictly followed.

For fixing test/build, I think traditionally its nicer to first check with
the author/committer of breaking patch if there is a simple fix, otherwise
if there is no response (within few hours), or if fix is non-trivial, to
revert.  But I dont feel that strongly either way, and can also see the
value of immediate reversion if its a blocking break.

On Wed, Nov 25, 2015 at 12:55 PM, Sergey Shelukhin <se...@hortonworks.com>
wrote:

> Hi.
> This has been happening a lot lately (and I have been guilty of that
> myself…). We just fixed the LLAP test, and now I see a bunch of other
> tests failing again in all the JIRAs now that didn’t fail as early as
> yesterday.
> In the past cases, I’ve seen HiveQA report failures that are ignored when
> the patch is committed, and then these failures start happening in all the
> JIRAs. It is understandable when people think failures are unrelated but
> it often looks like noone even checked if they are.
>
> How about we make sure to check the latest HiveQA run before committing a
> patch, our own or somebody else’s? :)
>
> Also should we have an expedited policy where it’s ok for a committer to
> revert and reopen the patch that broken some tests first, and then ask
> questions later?
>
>