hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Szehon Ho <sze...@cloudera.com>
Subject Re: not committing things that add HiveQA failures
Date Wed, 25 Nov 2015 21:24:21 GMT
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 <sergey@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?
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message