hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yongjun Zhang <yzh...@cloudera.com>
Subject Re: set up jenkins test for branch-2
Date Mon, 15 Jun 2015 18:39:20 GMT
Thanks Sean and Allen!

I was not aware of that there is already a way to trigger branch-2 test.
Good to know.

There are multiple solutions here:

1. When posting patches, we can post two versions of patches, one for
trunk, and one for branch-2, so to trigger two pre-commit jenkins test for
both branches. This would help catching issue before committing. However,
it's going to be more workload on the testing machines, so alternatively,
we can probably defer the branch-2 testing until committing to trunk and
before branch-2 testing.

2. Only post patch for trunk, we cherry-pick to branch-2 when committing.
We can set up periodic jenkins test (such as nightly) for branch-2 to catch
problem periodically. But that's basically being ignored by us as Allen
pointed out.

The goal in my mind is to try our best to have both commits to trunk and
branch-2 to pass jenkins test, thus help on quality.



On Mon, Jun 15, 2015 at 7:21 AM, Allen Wittenauer <aw@altiscale.com> wrote:

> On Jun 14, 2015, at 1:00 PM, Yongjun Zhang <yzhang@cloudera.com> wrote:
> > From time to time we saw changes that work fine in trunk but not
> branch-2,
> > and we don't catch the issue in a timely manner. The difference between
> > trunk and branch-2 is sufficient to justify periodic jenkins test and
> even
> > pre-commit test for branch-2.
>         What is your expected outcome?
>         The current nightly builds have been failing pretty consistently
> for a while now.  Adding another one isn't going to make the situation any
> better since everyone pretty much ignores them.  As I said at the HDFS
> BOF:  we desperately need a moratorium on adding new features and need to
> work on stabilizing both branch-2 and trunk.          We seem to be in a
> "quantity over quality" mode and it's slowly killing the project.  We
> haven't had a stable release since 2.4.1, which is approaching the 1 year
> mark.
>         (Yes, I know.  Various vendors have shipped releases since 2.4.1
> as part of their distributions.  Before saying anything, perhaps you should
> spend some time with your support folks….)
>         As Sean pointed out, precommit for branch-2 has been working for a
> while now if one provides enough hints to test-patch as part of the patch
> name.

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