> On Sep 14, 2017, at 11:01 AM, Sean Busbey <bus...@cloudera.com> wrote:
>
>> Committers MUST check the qbt output after a commit. They MUST make sure
> their commit didn’t break something new.
>
> How do we make this easier / more likely to happen?
>
> For example, I don't see any notice on HADOOP-14654 that the qbt
> post-commit failed. Is this a timing thing? Did Steve L just notice the
> break before we could finish the 10 hours it takes to get qbt done?
qbt doesn't update JIRA because...
>
> How solid would qbt have to be for us to do something drastic like
> auto-revert changes after a failure?
... I have never seen the unit tests for Hadoop pass completely. So it
would always fail every JIRA that it was testing. There's no point in enabling
the JIRA issue update or anything like that until our unit tests actually get
reliable. But that also means we're reliant upon the community to self police.
That is also failing.
Prior to Yetus getting involved, the only unit tests that would
reliably pass was mapreduce. The rest would almost always fail. It had been
that way for years.
Someone should probably invest some time into integrating the HBase
flaky test code a) into Yetus and then b) into Hadoop.
It's also worth pointing out that the YARN findbugs error has been
there for about six months. It would also fail the build.
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org
