From the general POV, I do agree that there's nothing inherently wrong about
having overlapping or even competing technologies as a part of our stack. My
comment was aimed to give the OP'a author a perspective of what is in already
and weigh it in. Not a call of discouragement ;)

Now, I respectfully disagree about not-being "opinionated". That's what
software distributions do all the time - they pick and choose what they want
to support and what not to. Which goes to the second point you expressed: as
long as there's a reliant maintainer for a given component, we might as well
on-board it. But the reverse principle has to be enacted as equally: if a
maintenance has dwindled - we should reserve the rights to drop the component
all together. Ultimately, it needs to be a community decision. Most recent
discussion of the kind is here [1].

Does it make sense?
 Cos

[1] https://issues.apache.org/jira/browse/BIGTOP-2804

On Wed, Jul 05, 2017 at 02:37PM, RJ Nowling wrote:
> I wanted to single out the issue of overlapping components that Cos raised
> for discussion without derailing the Crail conversation, so I'm starting a
> new thread.
> 
> Cos said:
> 
> >  - from a quick glance at the project, looks like it fits the general
> bucket
> >   of data fabric platforms. Something like Apache Ignite comes to mind,
> while
> >   Aluxio, as a simple caching solution, only has partial target
> >   functionality. While there's no limitation on having multiple components
> >   with overlapping functionality in a given Bigtop stack (after all, we
> have
> >   HDFS and QFS), it's an aspect worthy of some consideration.
> 
> I don't think having overlapping components is bad or should be avoided.
> Apache has tons of TLPs that overlap: Drill vs Hive vs Phoenix, Spark vs
> Flink vs Apex vs Storm vs Samza, Bookkeeper vs Zookeeper.  Rather, the
> "Apache way" seems to be to provide even ground for all projects and let
> "the market" decide whether projects succeed or fail.
> 
> From that standpoint, I think BigTop should not be opinionated about which
> components are included as long as someone is willing to maintain them.

Attachment: signature.asc
Description: Digital signature

Reply via email to