impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Apple <>
Subject Re: Contributions to Cloudera Impala
Date Fri, 16 Sep 2016 17:43:41 GMT
Nishidha, have you thought about starting that discussion on dev@ about

On Wed, Aug 17, 2016 at 9:12 AM, Jim Apple <> wrote:

> > I'm glad to tell you that we are able to build and test Impala on Ubuntu
> > linux ppc64le with the great support from the Cloudera Community.
> Excellent!
> > Our next action is to upstream all our changes to Cloudera Impala.
> Great!
> Cloudera has donated Impala to the Apache Software Foundation (aka
> "ASF"). Cloudera now contributes to the project, and the project is
> managed by the Impala community.
> > With
> > this, our plan is to start building latest Impala on Power8 as we'd been
> > porting quite an old version (code from cdh5-trunk branch till 23rd
> March,
> > 2016). Since then, I know there have been many many changes happened
> which
> > are yet to be ported, specially kudu stuff.
> Yes, there have been many changes. One is that Impala is now hosted on
> ASF-owned git. Please see
> to+switch+to+Apache-hosted+git
> >    We know we need CLA to be signed to start contributions. We have
> already
> >    initiated the process and hoping to get it done soon.
> I think the right thing to do here is use the Apache CLAs. See
> and
> >     By the time we get CLA signed, we would start porting the changes
> done
> >    in last 5 months. So, I wanted to know which tag/branch should we take
> >    up for this.
> This is a question we could all discuss together, and it might end up
> being a decision made by the Project Management Committee (PMC).
> This is a big question about how Apache Impala will evolve. Our bylaws
> state:
> "Significant, pervasive features may be developed in a speculative
> branch of the repository. The PMC may grant commit rights on the
> branch to its consistent contributors for the duration of the
> initiative. Branch committers are responsible for shepherding their
> feature into an active release and do not cast binding votes or vetoes
> in the project."
> So perhaps this should happen on a separate branch?
> One question the community should also consider, IMHO, is whether the
> community will have sufficient resources to maintain a working ppc64le
> codebase indefinitely into the future.
> > Working on cdh5-trunk will put us into an unending loop of
> >    porting as it is being modified everyday. We are thinking to create a
> >    branch from cdh5.8.0-release tag and start working on it. Please
> suggest
> >    us the best way to do this.
> Since Impala is now developed on Apache infrastructure, we have
> switched branching schemas. Our main branch is now "master". We do not
> have any release branches yet.
> >    Verifying all the changes on x86 platforms ourself here will also be
> >    time consuming and add potential delays in upstreaming. So, we were
> >    thinking if we can get a job on Cloudera's Continuous integration
> server
> >    which would simply fetch our branch and verify it on all the supported
> >    platforms and do all the required checks. I'm not sure if this is
> >    feasible but just a thought. Any other suggestions  to foster this
> >    activity would be appreciated.
> We are working on making a publicly-available CI setup, but we aren't done
> yet.
> Do you have a CI setup and x86-64 machines that your CI workers can run on?
> >    For every Pull Request, what are the basic sanity tests required to be
> >    ensured? Do you test all BE, FE, End-to-End tests, Custom cluster
> tests?
> Patches are sent to gerrit for review. Before they are merged, all
> tests must pass in "core" (but not "exhaustive") mode.
> ==========
> If I were in your shoes, I might take the following steps:
> 1. Start a discussion on dev@ about whether a new branch is the right
> way to develop.
> 2. Work out long-term maintenance plans and commitments and CI plans
> 3. Do the arduous work of rebasing on a recent HEAD.

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