Moving discussion here from HADOOP-14654.
Short synopsis:
* HADOOP-14654 updated commons-httplient to a new patch release in
hadoop-project
* Precommit checked the modules that changed (i.e. not many)
* nightly had Azure support break due to a change in behavior.
Is this just the cost of our app
> On Sep 14, 2017, at 8:03 AM, Sean Busbey wrote:
>
> * HADOOP-14654 updated commons-httplient to a new patch release in
> hadoop-project
> * Precommit checked the modules that changed (i.e. not many)
> * nightly had Azure support break due to a change in behavior.
OK, so it worked as c
> 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 no
Thanks Sean busbey for starting the discussion.This was one of pain point
even I notified to Allen couple of times.IIUC his point is committers and
contributors should monitor qbt.
IMHO,instead of post-commit try to fix in pre-commit only?? May be we can
get dependcy module(dependency:list) and ex
> On Sep 14, 2017, at 11:01 AM, Sean Busbey 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
This has gotten bad enough that people are dismissing legitimate test
failures among the noise.
On Thu, Sep 14, 2017 at 1:20 PM, Allen Wittenauer
wrote:
> Someone should probably invest some time into integrating the HBase
> flaky test code a) into Yetus and then b) into Hadoop.
What do
On 9/14/17 1:36 PM, Chris Douglas wrote:
This has gotten bad enough that people are dismissing legitimate test
failures among the noise.
On Thu, Sep 14, 2017 at 1:20 PM, Allen Wittenauer
wrote:
Someone should probably invest some time into integrating the HBase
flaky test code a) in
On Thu, Sep 14, 2017 at 1:43 PM, Ray Chiang wrote:
> The other solution I've seen (from Oozie?) is to re-run just the subset of
> failing tests once more. That should help cut down the failures except for
> the mostly flaky of flakies.
Many of our unit tests generate random cases and report the
On 2017-09-14 15:36, Chris Douglas wrote:
> This has gotten bad enough that people are dismissing legitimate test
> failures among the noise.
>
> On Thu, Sep 14, 2017 at 1:20 PM, Allen Wittenauer
> wrote:
> > Someone should probably invest some time into integrating the HBase
> > fla
On Thu, Sep 14, 2017 at 1:59 PM, Sean Busbey wrote:
>
>
> On 2017-09-14 15:36, Chris Douglas wrote:
> > This has gotten bad enough that people are dismissing legitimate test
> > failures among the noise.
> >
> > On Thu, Sep 14, 2017 at 1:20 PM, Allen Wittenauer
> > wrote:
> > > Someone
I actually like this idea:
> One approach: do a dependency:list of each module and for those that show
a
change with the patch we run tests there.
Can 'jdeps' be used to prune the list of sub modules on which we do
pre-commit ? Essentially, we figure out which classes actually use the
modified cl
On Thu, Sep 14, 2017 at 4:23 PM, Andrew Wang
wrote:
>
> >
> > I discussed this on yetus-dev a while back and Allen thought it'd be
> non-trivial:
>
> https://lists.apache.org/thread.html/552ad614d1b3d5226a656b60c01084
> 57bcaa1219fb9ad985f8750ba1@%3Cdev.yetus.apache.org%3E
>
> I unfortunately don
1. I think maybe we should have the special ability or process for patches
which change dependencies. We know that they have the potential for damage way
beyond their .patch size and I fear them
2. like allen says, we can't afford to have a full test run on every patch.
Because t hen the infra
I am +1 for a way to specify additional modules that should be run. Always
running all module dependencies would be prohibitively expensive (especially
for hadoop-common patches) but developers should have a good understanding of
which patches are more high-risk for downstream consumers and can
14 matches
Mail list logo
