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 <ser...@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? > >
