incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Nauroth <cnaur...@apache.org>
Subject Re: [DISCUSS] Concur for Apache Incubator
Date Wed, 30 Nov 2016 19:01:14 GMT
Responding to a few points in the thread:

> Jitendra, So considering how strong of a community this is already and the
> success of recent TLP direct projects, what goals do you have for
> incubation?  And why incubation over straight to TLP?

As hinted by a few others, I would like to see the project's time in the
Incubator focus on establishing a repeatable release process (always tricky
the first few times for a podling), providing sufficient documentation for
usage and contributor onboarding, and establishing community interaction on
the mailing lists.  From my knowledge of straight-to-TLP projects, I
believe those spun out of "refactoring" pieces of well-established projects
into new TLPs, so the spin-offs to some degree were able to inherit these
pieces from being previously hosted in the larger project.  In this case, I
prefer incubation, because Concur is not a spin-off and therefore still
needs to establish these pieces for itself.

> I think it sounds like an interesting proposal but wonders which
> consumers (and potential developers) it is targeting - I wonder about
> the strong link to Hortonworks and Hadoop -- is Concur relying on
> Hadoop, Hadoop might use Concur, or can Concur be used with many
> things, including Hadoop?

Our goal is to provide a stand-alone library providing a RAFT
implementation.  Although Apache Hadoop ecosystem projects are mentioned as
one of the primary targeted use cases, we do not intend to constrain it to
usage only within the Hadoop ecosystem or tightly couple it to any
particular vendor's distribution of the Hadoop ecosystem.  I could imagine
it being viable for usage within pieces of Hadoop or in a proprietary
distributed system that I work on at my day job.

It is true that the Concur codebase currently has a Maven dependency on
Hadoop.  This was largely a matter of coding convenience to pick up helpful
utilities for configuration management and networking.  For those
knowledgeable of Hadoop, I have listed all "org.apache.hadoop" imports
below.  You'll see that this is not tightly coupled to deep pieces of HDFS,
YARN, etc., but instead more like helpful utilities.  Whether or not the
Hadoop dependency is desirable long-term toward the goal of "stand-alone
library" is a question worthy of consideration for the Concur community,
though I see that as a technical decision point for the community, not a
factor for consideration of whether to accept the incubation proposal.



org.apache.hadoop.classification.InterfaceAudience;
org.apache.hadoop.classification.InterfaceStability;
org.apache.hadoop.conf.Configuration;
org.apache.hadoop.fs.ChecksumException;
org.apache.hadoop.fs.CommonConfigurationKeysPublic.IPC_CLIENT_CONNECT_MAX_RETRIES_KEY;
org.apache.hadoop.fs.CommonConfigurationKeysPublic.IPC_CLIENT_CONNECT_TIMEOUT_KEY;
org.apache.hadoop.fs.FileUtil;
org.apache.hadoop.io.DataOutputOutputStream;
org.apache.hadoop.io.IOUtils;
org.apache.hadoop.io.MD5Hash;
org.apache.hadoop.io.Writable;
org.apache.hadoop.io.nativeio.NativeIO;
org.apache.hadoop.io.nativeio.NativeIOException;
org.apache.hadoop.io.retry.RetryPolicy;
org.apache.hadoop.ipc.Client.ConnectionId;
org.apache.hadoop.ipc.ProtobufRpcEngineShaded;
org.apache.hadoop.ipc.ProtocolInfo;
org.apache.hadoop.ipc.RPC.RpcInvoker;
org.apache.hadoop.ipc.RPC;
org.apache.hadoop.ipc.RemoteException;
org.apache.hadoop.net.NetUtils;
org.apache.hadoop.security.KerberosInfo;
org.apache.hadoop.security.UserGroupInformation;
org.apache.hadoop.security.token.SecretManager;
org.apache.hadoop.security.token.TokenIdentifier;
org.apache.hadoop.test.GenericTestUtils;
org.apache.hadoop.util.Daemon;
org.apache.hadoop.util.DataChecksum;
org.apache.hadoop.util.ExitUtil;
org.apache.hadoop.util.ProtoUtil;
org.apache.hadoop.util.StringInterner;
org.apache.hadoop.util.StringUtils;
org.apache.hadoop.util.Time;
org.apache.raft.shaded.org.apache.hadoop.ipc.protobuf.ProtobufRpcEngineProtos.RequestHeaderProto;
org.apache.raft.shaded.org.apache.hadoop.ipc.protobuf.RpcHeaderProtos.RpcRequestHeaderProto;
org.apache.raft.shaded.org.apache.hadoop.ipc.protobuf.RpcHeaderProtos.RpcResponseHeaderProto;

--
Chris Nauroth

On Tue, Nov 29, 2016 at 2:59 PM, Jitendra Pandey <jitendra@hortonworks.com>
wrote:

> Thanks for the feedback.
> How does Ratis (Latin for raft) sound for the name? A quick search in
> google doesn¹t show it is used. If this is acceptable, I will update the
> proposal.
>
> We are working on documentation for the user api's as well as the design.
>
> We didn¹t consider TLP as the project is very new. We will focus on a
> release cadence and community diversity to qualify for TLP.
>
> Thanks
> jitendra
>
>
> On 11/23/16, 6:19 AM, "Stian Soiland-Reyes" <stain@apache.org> wrote:
>
> >On 23 November 2016 at 11:40, Roman Shaposhnik <roman@shaposhnik.org>
> >wrote:
> >> FIWI: these were my thoughts exactly. In fact, for a second there I
> >>thought
> >> that SAP was donating Concur codebase.
> >> In the spirit of bikeshedding I propose Apache Thor (or Heyerdahl) 'cuz
> >> you know: raft ;-)
> >
> >As Norwegian I should not really disagree on that name -- but Thor is
> >already the name of lots of things, including at least two EU projecst
> >https://project-thor.eu/ (Open Research interoperability)
> >http://www.eu-thor.eu/ (Oceanography!)
> >
> >
> >Apache Heyerdahl..?
> >
> >http://www.ssb.no/en/befolkning/statistikker/navn says:
> >> There are 410 [Norwegians] with Heyerdahl as their surname
> >
> >(>200 meaning it is not a protected surname in .no :)
> >
> >And 111 businesses - just in Norway - several doing IT stuff:
> >https://w2.brreg.no/enhet/sok/treffliste.jsp?navn=Heyerdahl
> &orgform=0&fylk
> >e=0&kommune=0
> >
> >
> >But we can discuss the proposal even if it has to change its name -
> >that's OK to sort in the very beginning (but is very preferably
> >community-wise to agree before actually moving to the Incubator).
> >
> >
> >I think it sounds like an interesting proposal but wonders which
> >consumers (and potential developers) it is targeting - I wonder about
> >the strong link to Hortonworks and Hadoop -- is Concur relying on
> >Hadoop, Hadoop might use Concur, or can Concur be used with many
> >things, including Hadoop?
> >
> >
> >I see https://github.com/hortonworks/concur is already using
> >org.apache.raft (and before org.apache.hadoop.raft) as a package name
> >- I find this approach for proposals a bit concerning trademark-wise;
> >but then I didn't look closely if this started as a fork/pull request
> >for Hadoop or similar?
> >
> >--
> >Stian Soiland-Reyes
> >http://orcid.org/0000-0001-9842-9718
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >For additional commands, e-mail: general-help@incubator.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
> --
> Chris Nauroth
> <general-help@incubator.apache.org>
>
<general-help@incubator.apache.org>

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