I just don't want to, say, exclude Apache Geode because we have Apache
Ignite or vice versa.

I agree with letting the presence / absence of maintainers be the main
judgement call.  But, I don't think that's being "opinionated".  BigTop's
user and developer communities overlap substantially.  I think that's
letting the "market" decide -- if people find having a particular component
in BigTop valuable, they will spend time to maintain its packaging.

On Wed, Jul 5, 2017 at 2:51 PM, Konstantin Boudnik <[email protected]> wrote:

> 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.
>

Reply via email to