Nishidha, have you thought about starting that discussion on dev@ about
branching?

On Wed, Aug 17, 2016 at 9:12 AM, Jim Apple <jbap...@cloudera.com> 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
> https://cwiki.apache.org/confluence/display/IMPALA/How+
> 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
>
> https://www.apache.org/licenses/cla-corporate.txt
>
> and
>
> https://www.apache.org/licenses/icla.txt
>
> >     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.
>

Reply via email to