accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Wall <mjw...@gmail.com>
Subject Re: [DISCUSS] Time for a 1.8.0 release?
Date Thu, 04 Aug 2016 01:39:07 GMT
Thanks Mike.  I recall you posting that in a email but didn't find it.
Rereading my email, I'd like to clarify that I'd be surprised if all ITs
passed for 1.7.2 every time in one run, like a CI environment.

Sean, your points about the difference between 1.8.0 being a minor release
and 1.7.2 being a patch release are valid.  I'll make sure I can get all
ITs to pass at least once before I cut an RC.  If I can't, I'll make sure
tickets are created or reassigned to 1.8.0.

Christopher, thanks for the better explanation.

On Wed, Aug 3, 2016 at 6:34 PM, Mike Drob <mdrob@apache.org> wrote:

> I had all of the tests passing at least once for 1.7.2, some had to be
> rerun however.
>
> On Wednesday, August 3, 2016, Christopher <ctubbsii@apache.org> wrote:
>
> > On Wed, Aug 3, 2016 at 5:47 PM Sean Busbey <busbey@cloudera.com
> > <javascript:;>> wrote:
> >
> > > My understanding was that maintenance releases (aka double dot, e.g.
> > > 1.7.2) had relaxed criteria because we expected the scope of changes
> > > in them to be more limited. Even so, the release notes for 1.7.2,
> > > 1.7.1, and 1.7.0 all claim the ITs passed.
> > >
> > >
> > Even those releases have periodic IT failure.
> >
> >
> > > Is there a reason we can't parallelize the ITs?
> >
> >
> > We can. Eric's mrit effort was all intended towards that. But, that's not
> > the same as CI passing. I don't know what it would take to parallelize
> them
> > in a CI server.
> >
> >
> > > What's stopping
> > > builds.a.o from running them? Specific requests from projects to asf
> > > infra can get us resources if that's the problem.
> > >
> > >
> > I spoke to infra in HipChat about this a a few weeks ago, and mentioned a
> > few things which impact builds on ASF jenkins (builds.apache.org):
> >
> > 1. Accumulo has an excessive number of tests to run.
> > 2. Build timeouts with Jenkins can abort builds.
> > 3. Tests are timing sensitive, and are affected by VM/host configuration
> > and contention with other concurrent builds from other projects.
> > 4. Tests need lots of RAM and storage (at least 4GB RAM, but ideally no
> > less than 16GB, and at least 6 GB for a workspace)
> > 5. Tests need specialized system configuration, (increasing ulimits,
> > optimizing kernel settings for swappiness, etc.)
> >
> > What we really need for reliable IT passing in CI, is exclusive use of
> > dedicated, bare-metal beefy build machines, for 6+ hours per build x 4
> > branches minimum, plus another 6+ hours for each pull request and other
> > builds which skipITs, so we can get immediate feedback on unit tests and
> > compilation errors.
> >
> > I don't think it's reasonable for us to even ask for such resources from
> > INFRA. Using ASF Jenkins for -DskipITs I think is reasonable, with
> > individual testing of full IT suite from the developers/contributors, as
> > well as feedback from independent dedicated CI builds (such as the
> Jenkins
> > server I'm running, as well as any Josh might still be running, and
> > others).
> >
> > The minimum passing to create a release candidate is -Psunny. Usually
> folks
> > submit test results on the full ITs which informed their vote. Sometimes,
> > but not always, the release manager will do some pre-vote testing and
> > prepare draft release notes. Testing information also gets aggregated
> from
> > the vote thread onto the release notes.
> >
>

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