Re: [DISCUSS] Mentor neutrality policy

[Pierre Smits]

What are you referring to, Konstantin?

Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Sat, Oct 10, 2015 at 1:31 AM, Konstantin Boudnik  wrote:

> On Fri, Oct 09, 2015 at 08:36PM, Daniel Gruno wrote:
> > Does there always have to be an actual problem before we can propose a
> > policy? must we always be reactive instead of proactive?
>
> "We can't just stay on a side and wait, we should do something!" - sounds
> all
> too familiar, eh?
>
> > Yes, I am in a way implying that some mentors are, perhaps, not neutral
> > in their work. I will not back it up with specific names or contexts, as
> > I don't want to take a trip to lawsuit town for things I cannot back up
> > with publicly available information.
> >
> > I don't find this to be uncivil accusations - can you outline a specific
> > segment that you find uncivil? I am proposing a set of basic rules -
> > which is naturally up for discussion and improvement - that would
> > potentially alleviate us from having some nasty discussions - whether
> > they be public or private - about the neutrality and honesty of
> > recommendations, and hopefully ensure we have a more leveled playing
> > field in the incubator.
> >
> > I'll stop here, as my eyesight is playing a trick on me today and not
> > allowing me to see what I type.
> >
> > With regards,
> > Daniel.
> >
> > On 10/09/2015 08:03 PM, Chris Douglas wrote:
> > > What problem does this solve?
> > >
> > > This proposal lacks context. It implies that mentors are not neutral,
> > > and that they are motivated by interests not shared by the ASF. But it
> > > does not outline the merits of that belief, neither does it specify
> > > how this proposal would address them. Instead of allowing those
> > > definitions to float, this discussion would be more productive if it
> > > were about some concrete problems for which there is evidence. Yet
> > > another thread of rude responses to uncivil accusations is
> > > unproductive, even if it is an IPMC tradition. -C
> > >
> > > On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno 
> wrote:
> > >> Hi Incubator folks,
> > >>
> > >> I would like to propose we adopt a mentor neutrality policy for
> > >> incubating podlings:
> > >>
> > >> - A mentor must not be financially tied to the project or its
> incubation
> > >> status.
> > >> - A mentor must not have a vested interest in incubating, graduating
> or
> > >> dismantling a podling that goes beyond the general Apache mission
> > >> - A mentor must not be affiliated with the entity granting the code
> > >> (company or original project community)
> > >>
> > >> Furthermore, I would like to see this extended to votes on graduating
> or
> > >> retiring podlings, so that only people with no organizational (aparty
> > >> from the ASF) or financial ties to the project (or the companies
> behind
> > >> it) can cast a binding vote on graduation or retirement.
> > >>
> > >> This would essentially mean:
> > >>
> > >> - If you work for a company (or are hired as consultant/advisor) that
> is
> > >> entering a project into incubation, you cannot mentor it nor vote
> > >> for/against its incubation, graduation or retirement.
> > >> - If you are a in the original community behind the project, you
> cannot
> > >> mentor it nor vote for/against it.
> > >>
> > >> I believe this would create a neutral mentorship whose sole mission is
> > >> to guide podlings with the interests of the ASF in mind.
> > >>
> > >>
> > >> Please do discuss this. If there is (mostly) positive feedback, I
> would
> > >> like to, at some point, have a vote on including this in the Incubator
> > >> policy. I realize this would cut down on the number of potential
> > >> mentors, and I would ask that more people step up to the challenge of
> > >> mentoring if adopted.
> > >>
> > >> With regards,
> > >> Daniel
> > >>
> > >> -
> > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > >> For additional commands, e-mail: general-h...@incubator.apache.org
> > >>
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

On Fri, Oct 09, 2015 at 11:38AM, Greg Trasuk wrote:
> Hi Daniel:
> 
> Discussion intertwined below…
> 
> Cheers,
> 
> Greg Trasuk
> 
> > On Oct 9, 2015, at 11:07 AM, Daniel Gruno  wrote:
> > 
> > Hi Incubator folks,
> > 
> > I would like to propose we adopt a mentor neutrality policy for
> > incubating podlings:
> > 
> > - A mentor must not be financially tied to the project or its incubation
> > status.
> 
> This requirement would seem to be against the idea that we participate in
> Apache as individuals, rather than as employees/representatives of some
> company.  If there is a case where a member appears to be representing their

I'd even go as far as saying this requirement asserts that mentors aren't
capable of separating their employment/advisement affiliation from their
individual contribution to the ASF. If it were indeed a case it should be
dealt with on a case-per-case basis, instead of putting a round of the
red-tape on everything single member of IPMC.

Cos

> company’s interest rather than the Foundation’s interest, shouldn’t that be
> dealt with in itself?
> 
> > - A mentor must not have a vested interest in incubating, graduating or
> > dismantling a podling that goes beyond the general Apache mission
> 
> Could you elaborate on “beyond the general Apache mission”?  You probably 
> have some concrete examples in mind, and I’m sure we don’t want to start 
> dissecting those examples rather than your overall suggestion, but 
> personally, I’m not sure what you mean.
> 
> > - A mentor must not be affiliated with the entity granting the code
> > (company or original project community)
> > 
> 
> That suggestion would seem to preclude a knowledgable insider who happens to 
> be an Apache member from helping out with incubating a project.  Which seems 
> kind of inefficient.
> 
> > Furthermore, I would like to see this extended to votes on graduating or
> > retiring podlings, so that only people with no organizational (aparty
> > from the ASF) or financial ties to the project (or the companies behind
> > it) can cast a binding vote on graduation or retirement.
> > 
> > This would essentially mean:
> > 
> > - If you work for a company (or are hired as consultant/advisor) that is
> > entering a project into incubation, you cannot mentor it nor vote
> > for/against its incubation, graduation or retirement.
> > - If you are a in the original community behind the project, you cannot
> > mentor it nor vote for/against it.
> > 
> > I believe this would create a neutral mentorship whose sole mission is
> > to guide podlings with the interests of the ASF in mind.
> > 
> > 
> > Please do discuss this. If there is (mostly) positive feedback, I would
> > like to, at some point, have a vote on including this in the Incubator
> > policy. I realize this would cut down on the number of potential
> > mentors, and I would ask that more people step up to the challenge of
> > mentoring if adopted.
> > 
> > With regards,
> > Daniel
> > 
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> > 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

On Sat, Oct 10, 2015 at 01:29AM, Pierre Smits wrote:
> What are you referring to, Konstantin?

I am referring to the progressives of the world and all "policy frameworks"
they are so readily unleashing on everybody because they have an urge to
meddle. I am very much agree with Chris and Ross on immorality of the
guilt-by-association policy.

Cos

> Best regards,
> 
> Pierre Smits
> 
> *OFBiz Extensions Marketplace*
> http://oem.ofbizci.net/oci-2/
> 
> On Sat, Oct 10, 2015 at 1:31 AM, Konstantin Boudnik  wrote:
> 
> > On Fri, Oct 09, 2015 at 08:36PM, Daniel Gruno wrote:
> > > Does there always have to be an actual problem before we can propose a
> > > policy? must we always be reactive instead of proactive?
> >
> > "We can't just stay on a side and wait, we should do something!" - sounds
> > all
> > too familiar, eh?
> >
> > > Yes, I am in a way implying that some mentors are, perhaps, not neutral
> > > in their work. I will not back it up with specific names or contexts, as
> > > I don't want to take a trip to lawsuit town for things I cannot back up
> > > with publicly available information.
> > >
> > > I don't find this to be uncivil accusations - can you outline a specific
> > > segment that you find uncivil? I am proposing a set of basic rules -
> > > which is naturally up for discussion and improvement - that would
> > > potentially alleviate us from having some nasty discussions - whether
> > > they be public or private - about the neutrality and honesty of
> > > recommendations, and hopefully ensure we have a more leveled playing
> > > field in the incubator.
> > >
> > > I'll stop here, as my eyesight is playing a trick on me today and not
> > > allowing me to see what I type.
> > >
> > > With regards,
> > > Daniel.
> > >
> > > On 10/09/2015 08:03 PM, Chris Douglas wrote:
> > > > What problem does this solve?
> > > >
> > > > This proposal lacks context. It implies that mentors are not neutral,
> > > > and that they are motivated by interests not shared by the ASF. But it
> > > > does not outline the merits of that belief, neither does it specify
> > > > how this proposal would address them. Instead of allowing those
> > > > definitions to float, this discussion would be more productive if it
> > > > were about some concrete problems for which there is evidence. Yet
> > > > another thread of rude responses to uncivil accusations is
> > > > unproductive, even if it is an IPMC tradition. -C
> > > >
> > > > On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno 
> > wrote:
> > > >> Hi Incubator folks,
> > > >>
> > > >> I would like to propose we adopt a mentor neutrality policy for
> > > >> incubating podlings:
> > > >>
> > > >> - A mentor must not be financially tied to the project or its
> > incubation
> > > >> status.
> > > >> - A mentor must not have a vested interest in incubating, graduating
> > or
> > > >> dismantling a podling that goes beyond the general Apache mission
> > > >> - A mentor must not be affiliated with the entity granting the code
> > > >> (company or original project community)
> > > >>
> > > >> Furthermore, I would like to see this extended to votes on graduating
> > or
> > > >> retiring podlings, so that only people with no organizational (aparty
> > > >> from the ASF) or financial ties to the project (or the companies
> > behind
> > > >> it) can cast a binding vote on graduation or retirement.
> > > >>
> > > >> This would essentially mean:
> > > >>
> > > >> - If you work for a company (or are hired as consultant/advisor) that
> > is
> > > >> entering a project into incubation, you cannot mentor it nor vote
> > > >> for/against its incubation, graduation or retirement.
> > > >> - If you are a in the original community behind the project, you
> > cannot
> > > >> mentor it nor vote for/against it.
> > > >>
> > > >> I believe this would create a neutral mentorship whose sole mission is
> > > >> to guide podlings with the interests of the ASF in mind.
> > > >>
> > > >>
> > > >> Please do discuss this. If there is (mostly) positive feedback, I
> > would
> > > >> like to, at some point, have a vote on including this in the Incubator
> > > >> policy. I realize this would cut down on the number of potential
> > > >> mentors, and I would ask that more people step up to the challenge of
> > > >> mentoring if adopted.
> > > >>
> > > >> With regards,
> > > >> Daniel
> > > >>
> > > >> -
> > > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > >> For additional commands, e-mail: general-h...@incubator.apache.org
> > > >>
> > > >
> > > > -
> > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > > For additional commands, e-mail: general-h...@incubator.apache.org
> > > >
> > >
> > >
> > > -
> > > To unsubscribe, 

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

On Fri, Oct 09, 2015 at 08:36PM, Daniel Gruno wrote:
> Does there always have to be an actual problem before we can propose a
> policy? must we always be reactive instead of proactive?

"We can't just stay on a side and wait, we should do something!" - sounds all
too familiar, eh?

> Yes, I am in a way implying that some mentors are, perhaps, not neutral
> in their work. I will not back it up with specific names or contexts, as
> I don't want to take a trip to lawsuit town for things I cannot back up
> with publicly available information.
> 
> I don't find this to be uncivil accusations - can you outline a specific
> segment that you find uncivil? I am proposing a set of basic rules -
> which is naturally up for discussion and improvement - that would
> potentially alleviate us from having some nasty discussions - whether
> they be public or private - about the neutrality and honesty of
> recommendations, and hopefully ensure we have a more leveled playing
> field in the incubator.
> 
> I'll stop here, as my eyesight is playing a trick on me today and not
> allowing me to see what I type.
> 
> With regards,
> Daniel.
> 
> On 10/09/2015 08:03 PM, Chris Douglas wrote:
> > What problem does this solve?
> > 
> > This proposal lacks context. It implies that mentors are not neutral,
> > and that they are motivated by interests not shared by the ASF. But it
> > does not outline the merits of that belief, neither does it specify
> > how this proposal would address them. Instead of allowing those
> > definitions to float, this discussion would be more productive if it
> > were about some concrete problems for which there is evidence. Yet
> > another thread of rude responses to uncivil accusations is
> > unproductive, even if it is an IPMC tradition. -C
> > 
> > On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno  wrote:
> >> Hi Incubator folks,
> >>
> >> I would like to propose we adopt a mentor neutrality policy for
> >> incubating podlings:
> >>
> >> - A mentor must not be financially tied to the project or its incubation
> >> status.
> >> - A mentor must not have a vested interest in incubating, graduating or
> >> dismantling a podling that goes beyond the general Apache mission
> >> - A mentor must not be affiliated with the entity granting the code
> >> (company or original project community)
> >>
> >> Furthermore, I would like to see this extended to votes on graduating or
> >> retiring podlings, so that only people with no organizational (aparty
> >> from the ASF) or financial ties to the project (or the companies behind
> >> it) can cast a binding vote on graduation or retirement.
> >>
> >> This would essentially mean:
> >>
> >> - If you work for a company (or are hired as consultant/advisor) that is
> >> entering a project into incubation, you cannot mentor it nor vote
> >> for/against its incubation, graduation or retirement.
> >> - If you are a in the original community behind the project, you cannot
> >> mentor it nor vote for/against it.
> >>
> >> I believe this would create a neutral mentorship whose sole mission is
> >> to guide podlings with the interests of the ASF in mind.
> >>
> >>
> >> Please do discuss this. If there is (mostly) positive feedback, I would
> >> like to, at some point, have a vote on including this in the Incubator
> >> policy. I realize this would cut down on the number of potential
> >> mentors, and I would ask that more people step up to the challenge of
> >> mentoring if adopted.
> >>
> >> With regards,
> >> Daniel
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> > 
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> > 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Mattmann, Chris A (3980)]

I do not agree with this proposal I will elaborate more later

Sent from my iPhone

> On Oct 9, 2015, at 8:07 AM, Daniel Gruno  wrote:
> 
> Hi Incubator folks,
> 
> I would like to propose we adopt a mentor neutrality policy for
> incubating podlings:
> 
> - A mentor must not be financially tied to the project or its incubation
> status.
> - A mentor must not have a vested interest in incubating, graduating or
> dismantling a podling that goes beyond the general Apache mission
> - A mentor must not be affiliated with the entity granting the code
> (company or original project community)
> 
> Furthermore, I would like to see this extended to votes on graduating or
> retiring podlings, so that only people with no organizational (aparty
> from the ASF) or financial ties to the project (or the companies behind
> it) can cast a binding vote on graduation or retirement.
> 
> This would essentially mean:
> 
> - If you work for a company (or are hired as consultant/advisor) that is
> entering a project into incubation, you cannot mentor it nor vote
> for/against its incubation, graduation or retirement.
> - If you are a in the original community behind the project, you cannot
> mentor it nor vote for/against it.
> 
> I believe this would create a neutral mentorship whose sole mission is
> to guide podlings with the interests of the ASF in mind.
> 
> 
> Please do discuss this. If there is (mostly) positive feedback, I would
> like to, at some point, have a vote on including this in the Incubator
> policy. I realize this would cut down on the number of potential
> mentors, and I would ask that more people step up to the challenge of
> mentoring if adopted.
> 
> With regards,
> Daniel
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Graduate Kylin from the Apache Incubator

[Pierre Smits]

Maybe the podling should then elaborate on their choice of having it in the
request proposal, before it comes to a vote and it is still in.

Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Fri, Oct 9, 2015 at 11:47 PM, P. Taylor Goetz  wrote:

> Exactly my point. If it's intentional, leave it in, otherwise consider
> taking it out.
>
> As a (very recent) mentor, I see no indication that the Kylin community
> has plans to deviate.
>
> Background: When Storm was incubating I thought that creating bylaws was
> required, and we did so, for better or worse. In retrospect, I probably
> would have stuck with the defaults.
>
> -Taylor
>
> > On Oct 9, 2015, at 5:22 PM, Pierre Smits  wrote:
> >
> > Maybe the podling has a valid reason behind that choice. So let us not
> > chuck that out of the window because of other podlings not paying
> attention
> > to what they did.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *OFBiz Extensions Marketplace*
> > http://oem.ofbizci.net/oci-2/
> >
> >> On Fri, Oct 9, 2015 at 10:42 PM, P. Taylor Goetz 
> wrote:
> >>
> >> I agree.
> >>
> >> It’s also worth discussing whether the “tasked with the creation of a
> set
> >> of bylaws” section of the proposal is really needed.
> >>
> >> My understanding is that that section is not actually necessary, and has
> >> proliferated among projects largely due to copying/pasting of other
> >> graduation proposals. I believe it is only necessary if a project plans
> to
> >> deviate from the ASF standard ASF practices.
> >>
> >> Just something to consider.
> >>
> >> -Taylor
> >>
> >>> On Oct 9, 2015, at 3:53 PM, Julian Hyde  wrote:
> >>>
> >>> I am a mentor of Kylin and I believe the project is ready to graduate.
> >>> They have created a vibrant, open community and are conducting
> >>> business in the Apache Way.
> >>>
> >>> One proviso: Let's complete the name search before starting the IPMC
> >>> vote. It would be foolish to let that particular cart get in front of
> >>> the horse. I don't think that prevents us from discussing graduation.
> >>>
> >>> Julian
> >>>
> >>>
>  On Fri, Oct 9, 2015 at 10:44 AM, Samant, Medha 
> wrote:
>  +1
> 
> > On 10/9/15, 10:13 AM, "Adunuthula, Seshu" 
> wrote:
> >
> > +1
> >
> >> On 10/7/15, 8:32 AM, "John D. Ament"  wrote:
> >>
> >> I would be happy to see kylin graduate.
> >>> On Oct 7, 2015 11:28, "Luke Han"  wrote:
> >>>
> >>> The Kylin community and project made significant advances during
> the
> >>> incubating (from Nov 2014) and
> >>> believes it is ready to graduate as a top-level project.
> >>>
> >>> The Apache Kylin is very active. The PPMC doubled in size (added 6
> >>> committers and 2 mentors) and
> >>> increased diversity in the past year. Released 3 version in the
> past
> >> 6
> >>> months. There were presentations about Kylin
> >>> at most of the big conferences of the world (including
> Strata+Hadoop
> >>> World
> >>> London, Hadoop Summit San Jose,
> >>> ApacheCon EU, Big Data Technology China, Database Technology
> >> Conference
> >>> China) and some meetups (Bay Area,
> >>> Beijing and one is coming in this weekend in Shanghai), and many
> >> talks
> >>> around the world.
> >>> The dev mailing list is growing very month, about 500+ topics per
> >> month
> >>> now.
> >>> The community created 1000+ JIRA tickets, many patches from
> >>> contributors/committers have been merged into code base.
> >>>
> >>> A vote passed unanimously on the dev@ list (27 +1 votes). Please
> >> find
> >>> below
> >>> references to the graduation preparation artifacts:
> >>> * discussion on dev list [1]
> >>> * vote thread [2]
> >>> * podling name search (still in progress) [3]
> >>> * incubation status [4]
> >>> * proposed resolution below
> >>>
> >>> We believe Apache Kylin is ready to become a top-level project and
> if
> >>> the
> >>> IPMC agree we will move to a formal vote.
> >>> There are a few more items to be updated on the project status page
> >> and
> >>> others during the next couple of days.
> >>>
> >>>
> >>> Many thanks to the mentors and the IPMC for the support,
> >>> Luke Han (on behalf of the Apache Kylin PPMC)
> >>>
> >>> [1] http://s.apache.org/KylinDisGraduate
> >>> [2] http://s.apache.org/KylinGraduateVote
> >>> [3] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-86
> >>> [4] http://incubator.apache.org/projects/kylin.html
> >>>
> >>>
> >>>
> >>> Apache Kylin top-level project resolution:
> >>> ===
> >>>
> >>>  WHEREAS, the Board of Directors deems it to be in the best
> >>>  interests of the 

Re: [DISCUSS] Graduate Kylin from the Apache Incubator

[P. Taylor Goetz]

Exactly my point. If it's intentional, leave it in, otherwise consider taking 
it out.

As a (very recent) mentor, I see no indication that the Kylin community has 
plans to deviate.

Background: When Storm was incubating I thought that creating bylaws was 
required, and we did so, for better or worse. In retrospect, I probably would 
have stuck with the defaults.

-Taylor

> On Oct 9, 2015, at 5:22 PM, Pierre Smits  wrote:
> 
> Maybe the podling has a valid reason behind that choice. So let us not
> chuck that out of the window because of other podlings not paying attention
> to what they did.
> 
> Best regards,
> 
> Pierre Smits
> 
> *OFBiz Extensions Marketplace*
> http://oem.ofbizci.net/oci-2/
> 
>> On Fri, Oct 9, 2015 at 10:42 PM, P. Taylor Goetz  wrote:
>> 
>> I agree.
>> 
>> It’s also worth discussing whether the “tasked with the creation of a set
>> of bylaws” section of the proposal is really needed.
>> 
>> My understanding is that that section is not actually necessary, and has
>> proliferated among projects largely due to copying/pasting of other
>> graduation proposals. I believe it is only necessary if a project plans to
>> deviate from the ASF standard ASF practices.
>> 
>> Just something to consider.
>> 
>> -Taylor
>> 
>>> On Oct 9, 2015, at 3:53 PM, Julian Hyde  wrote:
>>> 
>>> I am a mentor of Kylin and I believe the project is ready to graduate.
>>> They have created a vibrant, open community and are conducting
>>> business in the Apache Way.
>>> 
>>> One proviso: Let's complete the name search before starting the IPMC
>>> vote. It would be foolish to let that particular cart get in front of
>>> the horse. I don't think that prevents us from discussing graduation.
>>> 
>>> Julian
>>> 
>>> 
 On Fri, Oct 9, 2015 at 10:44 AM, Samant, Medha  wrote:
 +1
 
> On 10/9/15, 10:13 AM, "Adunuthula, Seshu"  wrote:
> 
> +1
> 
>> On 10/7/15, 8:32 AM, "John D. Ament"  wrote:
>> 
>> I would be happy to see kylin graduate.
>>> On Oct 7, 2015 11:28, "Luke Han"  wrote:
>>> 
>>> The Kylin community and project made significant advances during the
>>> incubating (from Nov 2014) and
>>> believes it is ready to graduate as a top-level project.
>>> 
>>> The Apache Kylin is very active. The PPMC doubled in size (added 6
>>> committers and 2 mentors) and
>>> increased diversity in the past year. Released 3 version in the past
>> 6
>>> months. There were presentations about Kylin
>>> at most of the big conferences of the world (including Strata+Hadoop
>>> World
>>> London, Hadoop Summit San Jose,
>>> ApacheCon EU, Big Data Technology China, Database Technology
>> Conference
>>> China) and some meetups (Bay Area,
>>> Beijing and one is coming in this weekend in Shanghai), and many
>> talks
>>> around the world.
>>> The dev mailing list is growing very month, about 500+ topics per
>> month
>>> now.
>>> The community created 1000+ JIRA tickets, many patches from
>>> contributors/committers have been merged into code base.
>>> 
>>> A vote passed unanimously on the dev@ list (27 +1 votes). Please
>> find
>>> below
>>> references to the graduation preparation artifacts:
>>> * discussion on dev list [1]
>>> * vote thread [2]
>>> * podling name search (still in progress) [3]
>>> * incubation status [4]
>>> * proposed resolution below
>>> 
>>> We believe Apache Kylin is ready to become a top-level project and if
>>> the
>>> IPMC agree we will move to a formal vote.
>>> There are a few more items to be updated on the project status page
>> and
>>> others during the next couple of days.
>>> 
>>> 
>>> Many thanks to the mentors and the IPMC for the support,
>>> Luke Han (on behalf of the Apache Kylin PPMC)
>>> 
>>> [1] http://s.apache.org/KylinDisGraduate
>>> [2] http://s.apache.org/KylinGraduateVote
>>> [3] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-86
>>> [4] http://incubator.apache.org/projects/kylin.html
>>> 
>>> 
>>> 
>>> Apache Kylin top-level project resolution:
>>> ===
>>> 
>>>  WHEREAS, the Board of Directors deems it to be in the best
>>>  interests of the Foundation and consistent with the
>>>  Foundation's purpose to establish a Project Management
>>>  Committee charged with the creation and maintenance of
>>>  open-source software, for distribution at no charge to the
>>>  public, relative to distributed and scalable OLAP engine
>>> 
>>>  NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>>>  Committee (PMC), to be known as the "Apache Kylin Project",
>>>  be and hereby is established pursuant to Bylaws of the

[VOTE] Release Apache AsterixDB 0.8.7-incubating (RC3)

[Ian Maxon]

Hi everyone,

Please verify and vote on the first release of Apache AsterixDB . This is
our first incubating release for this part of the codebase, so as was the
case with our Hyracks components, feedback is much appreciated. As was
noted in the result and discussion on dev@asterixdb.i.a.o, this will be a
source-only release due to some issues with how our binaries are assembled
in Maven at the moment.

The vote to release on the development list passed:
*https://mail-archives.apache.org/mod_mbox/incubator-asterixdb-dev/201510.mbox/%3ccan_yf5wppfcnpfjkt5aejtm46x1z9osujxmqroscvjkvl+s...@mail.gmail.com%3E
*

with result

Binding +1s:
Till Westmann
Murtadha Hubail
Taewoo Kim
Yingyi Bu
Mike Carey
Ate Douma

Non-binding +1s:
Heri Ramampiaro

And no 0 or -1 votes


The tag to be voted on is

asterix-0.8.7-incubating
commit : d2e1e89cfdf39e2b772dff2600913bb79644a380
link:
https://git-wip-us.apache.org/repos/asf?p=incubator-asterixdb.git;a=tag;h=refs/tags/asterix-0.8.7-incubating

The artifacts, md5s, and signatures are at:

https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip
https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.asc
https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.md5
https://dist.apache.org/repos/dist/dev/incubator/asterixdb/asterix-0.8.7-incubating-source-release.zip.sha1

MD5: 7330e6d6c2dd691ae3ab6a641e4d5344
SHA1: bf0b4a2ceaa26bcf1fcda33fee1ba227e31a88ba


The KEYS file containing the PGP keys used to sign the release can be found
at

https://dist.apache.org/repos/dist/release/incubator/asterixdb/KEYS


RAT was executed as part of Maven via the RAT maven plugin, as well as
manually, but it
excludes the following paths:

.*\.adm
.*\.aql
.*\.cleaned
.*\.csv
.*\.csv.cr
.*\.csv.crlf
.*\.csv.lf
.*\.ddl
.*\.dot
.*\.hcli
.*\.iml
.*\.json
.*\.out
.*\.plan
.*\.ps
.*\.scm
.*\.tbl
.*\.tbl\.big
.*\.tsv
.*\.txt
.*large_text
.*part-0
.*part-1

.*\.goutputstream-YQMB2V
.*02-fuzzy-select
.*LockRequestFile
.*hosts
.*id_rsa
.*known_hosts

.*bottle.py
.*geostats.js
.*jquery.autosize-min.js
.*jquery.min.js
.*rainbowvis.js
.*smoothie.js


These files either are either data for tests, procedurally generated,
or source files which come without a header mentioning their license,
but have an explicit reference in the LICENSE file.

The complete RAT report is available at:
https://gist.githubusercontent.com/westmann/b6ed4b25bea44adcd526/raw/be93ff0c1d13c2ce7c88a2b713ace130b5e7ef5f/gistfile1.txt

The vote is open for 72 hours, or until the necessary number of votes
(3 +1) has been reached.

Please vote
[ ] +1 release this package as Apache AsterixDB 0.8.7-incubating
[ ] 0 No strong feeling either way
[ ] -1 do not release this package because ...

Thanks,
- Ian

Re: [VOTE] Accept Concerted into the Apache Incubator

[Atri Sharma]

Hi,

Please find answers below:

1) The main source code on Github wasn't updated for a while. However, the
original and main core was written in 2013 and has been open source since
then. As we discussed earlier current code base is only starting point for
complete development and will be first integrated with silo work done
independent and then used as starting implementation.

2) The JNI native API when optimized can provide great performance ( I have
written an application using it and it is on production systems for many
years). I think we can still provide a high performance API to the C++ core
and that is something I am personally working on right now.
On 10 Oct 2015 02:31, "Julian Hyde"  wrote:

> I have agreed to be a mentor to Concerted and I think it is an
> interesting idea. I am inclined to vote for it entering the incubator.
>
> However since the project has not released any source code yet, there
> are a couple of questions I'd like to get answered for the record:
>
> 1. How many lines of existing code are there? What is their approximate
> age?
>
> 2. Concerted is in C/C++ but you mention interfacing with JVM-based
> products like Hive. How you would interface with other languages? Is
> it a goal of the project to create APIs to other languages such as
> Java? Would access from those languages be as efficient as native
> access?
>
> I apologize that I didn't bring these up in the discussion thread.
>
> Julian
>
>
> On Fri, Oct 9, 2015 at 11:53 AM, Ayrton Gomesz 
> wrote:
> > +1
> > @henry.saputra thanks man
> > On Oct 9, 2015 5:50 PM, "Henry Saputra"  wrote:
> >
> >> +1 (binding)
> >> Good luck guys!
> >>
> >> On Fri, Oct 9, 2015 at 8:55 AM, Atri Sharma  wrote:
> >> > Hi all,
> >> >
> >> > Following the discussion about Concerted I would like to call a vote
> for
> >> > accepting Concerted as a new incubator project.
> >> >
> >> > The proposal text is included below, and available on the wiki:
> >> >
> >> > https://wiki.apache.org/incubator/ConcertedProposal
> >> >
> >> > The vote is open for 72 hours:
> >> >
> >> > [ ] +1 accept Concerted in the Incubator
> >> > [ ] ±0
> >> > [ ] -1 (please give reason)
> >> >
> >> > Regards,
> >> >
> >> > Atri
> >> >
> >> > = Abstract =
> >> >
> >> > Concerted is an in memory write less read more engine aimed to provide
> >> > extreme read performance with very high degree of concurrency and
> >> > scalability and focus on minimizing own resource footprint.
> >> >
> >> > = Proposal =
> >> > Concerted is built on the principal that a new type of workload is
> >> > dominating the scene and is now needed to be supported. These are the
> >> large
> >> > data set analytical workloads being analyzed or used on large
> clusters or
> >> > high power machines. Large analytical workloads depend on the ability
> to
> >> > query large data sets efficiently and in high concurrency while
> >> maintaining
> >> > semantics such as immediate consistency. An in memory engine designed
> to
> >> > support extreme read queries while providing support for aggregation
> >> > through various features (such as multidimensional representation of
> >> > tuples) will accelerate many usecases around large scale analytics.
> >> >
> >> > Concerted believes that best understanding of user application lies
> with
> >> > user application developer. The need for massive read scaling should
> be
> >> on
> >> > demand and should be flexible to the level that user can decide as to
> >> which
> >> > representation and access of data suits his/her current requirements.
> >> > Hence, Concerted is not built in a traditional client/server model.
> >> > Concerted provides users with an API which can be used to load, read,
> >> > update and delete data. User chooses which data structure has to be
> used
> >> > for his current requirements. All API access is covered by Concerted's
> >> > internal systems like lock manager, transaction manager and cache
> manager
> >> > which ensure that reads scale to high level in every API call.
> >> >
> >> > Concerted is a Do It Yourself in memory platform for making in memory
> >> > supporting engines. The use case we think of is supporting big data
> >> > warehouses like Hive, but there are endless use cases for a custom,
> >> highly
> >> > scalable in memory platform.
> >> >
> >> > The goal of this proposal is to leverage an existing code base
> available
> >> on
> >> > Github and licensed under the Apache License 2.0 to build a community
> >> > around the project. Currently the community consists of existing
> hackers
> >> of
> >> > Concerted as well as people who have been following and associated
> with
> >> the
> >> > project since a while as well as database experts who are excited
> about
> >> > building a project like this. We are hoping that entering into Apache
> >> would
> >> > help us attract more contributors as well as connect with existing big
> >> data
> >> > 

Re: [DISCUSS] Mentor neutrality policy

[Pierre Smits]

Meaning: proactively trying to doing the right thing, trying to define
boundaries before wrongdoing happens, is wrong?

Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Fri, Oct 9, 2015 at 10:51 PM, Chris Douglas  wrote:

> Daniel-
>
> If you have these concerns about mentors, a TLP proposal, or even an
> active TLP substantiated only by private information: notify the board
> via board-private@. That's why it's there.
>
> The proposal accuses mentors of selling influence, and acting contrary
> to the foundation's interest. That is by definition a problem to which
> we react, with proof of guilt. "Proactively" treating volunteers as
> suspect demands that mentors prove their innocence. Assuming guilt is
> not "proactive," but uncivil and immoral.
>
> There are also practical objections. Every IPMC member has a binding
> vote on decisions made by the incubator, period. IPMC members may
> voluntarily recuse themselves, but a policy that suppresses the votes
> of "suspicious" groups is invalid.
>
> The TLP resolution is only recommended by the IPMC. Anything achieved
> by this proposal is better implemented by the board considering that
> recommendation in context- including evidence provided privately- and
> rejecting improper proposals with actionable feedback to the PPMC. -C
>
> On Fri, Oct 9, 2015 at 11:36 AM, Daniel Gruno 
> wrote:
> > Does there always have to be an actual problem before we can propose a
> > policy? must we always be reactive instead of proactive?
> >
> > Yes, I am in a way implying that some mentors are, perhaps, not neutral
> > in their work. I will not back it up with specific names or contexts, as
> > I don't want to take a trip to lawsuit town for things I cannot back up
> > with publicly available information.
> >
> > I don't find this to be uncivil accusations - can you outline a specific
> > segment that you find uncivil? I am proposing a set of basic rules -
> > which is naturally up for discussion and improvement - that would
> > potentially alleviate us from having some nasty discussions - whether
> > they be public or private - about the neutrality and honesty of
> > recommendations, and hopefully ensure we have a more leveled playing
> > field in the incubator.
> >
> > I'll stop here, as my eyesight is playing a trick on me today and not
> > allowing me to see what I type.
> >
> > With regards,
> > Daniel.
> >
> > On 10/09/2015 08:03 PM, Chris Douglas wrote:
> >> What problem does this solve?
> >>
> >> This proposal lacks context. It implies that mentors are not neutral,
> >> and that they are motivated by interests not shared by the ASF. But it
> >> does not outline the merits of that belief, neither does it specify
> >> how this proposal would address them. Instead of allowing those
> >> definitions to float, this discussion would be more productive if it
> >> were about some concrete problems for which there is evidence. Yet
> >> another thread of rude responses to uncivil accusations is
> >> unproductive, even if it is an IPMC tradition. -C
> >>
> >> On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno 
> wrote:
> >>> Hi Incubator folks,
> >>>
> >>> I would like to propose we adopt a mentor neutrality policy for
> >>> incubating podlings:
> >>>
> >>> - A mentor must not be financially tied to the project or its
> incubation
> >>> status.
> >>> - A mentor must not have a vested interest in incubating, graduating or
> >>> dismantling a podling that goes beyond the general Apache mission
> >>> - A mentor must not be affiliated with the entity granting the code
> >>> (company or original project community)
> >>>
> >>> Furthermore, I would like to see this extended to votes on graduating
> or
> >>> retiring podlings, so that only people with no organizational (aparty
> >>> from the ASF) or financial ties to the project (or the companies behind
> >>> it) can cast a binding vote on graduation or retirement.
> >>>
> >>> This would essentially mean:
> >>>
> >>> - If you work for a company (or are hired as consultant/advisor) that
> is
> >>> entering a project into incubation, you cannot mentor it nor vote
> >>> for/against its incubation, graduation or retirement.
> >>> - If you are a in the original community behind the project, you cannot
> >>> mentor it nor vote for/against it.
> >>>
> >>> I believe this would create a neutral mentorship whose sole mission is
> >>> to guide podlings with the interests of the ASF in mind.
> >>>
> >>>
> >>> Please do discuss this. If there is (mostly) positive feedback, I would
> >>> like to, at some point, have a vote on including this in the Incubator
> >>> policy. I realize this would cut down on the number of potential
> >>> mentors, and I would ask that more people step up to the challenge of
> >>> mentoring if adopted.
> >>>
> >>> With regards,
> >>> Daniel
> >>>
> >>> -

Re: [DISCUSS] Mentor neutrality policy

[Pierre Smits]

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Fri, Oct 9, 2015 at 11:31 PM, Ross Gardler 
wrote:

> No. Meaning that starting from a place of no-trust in an environment where
> trust is critical is wrong.
>
> Ross
>
> -Original Message-
> From: Pierre Smits [mailto:pierre.sm...@gmail.com]
> Sent: Friday, October 9, 2015 2:26 PM
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] Mentor neutrality policy
>
> Meaning: proactively trying to doing the right thing, trying to define
> boundaries before wrongdoing happens, is wrong?
>
> Best regards,
>
> Pierre Smits
>
> *OFBiz Extensions Marketplace*
>
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2foem.ofbizci.net%2foci-2%2f=01%7c01%7cRoss.Gardler%40microsoft.com%7ce3df44d6e18b409c180c08d2d0f042cc%7c72f988bf86f141af91ab2d7cd011db47%7c1=jTO4UHTjBVDxUGUNMAPv5ocD5hBmTU0Xj9xM1PTNWEk%3d
>
> On Fri, Oct 9, 2015 at 10:51 PM, Chris Douglas 
> wrote:
>
> > Daniel-
> >
> > If you have these concerns about mentors, a TLP proposal, or even an
> > active TLP substantiated only by private information: notify the board
> > via board-private@. That's why it's there.
> >
> > The proposal accuses mentors of selling influence, and acting contrary
> > to the foundation's interest. That is by definition a problem to which
> > we react, with proof of guilt. "Proactively" treating volunteers as
> > suspect demands that mentors prove their innocence. Assuming guilt is
> > not "proactive," but uncivil and immoral.
> >
> > There are also practical objections. Every IPMC member has a binding
> > vote on decisions made by the incubator, period. IPMC members may
> > voluntarily recuse themselves, but a policy that suppresses the votes
> > of "suspicious" groups is invalid.
> >
> > The TLP resolution is only recommended by the IPMC. Anything achieved
> > by this proposal is better implemented by the board considering that
> > recommendation in context- including evidence provided privately- and
> > rejecting improper proposals with actionable feedback to the PPMC. -C
> >
> > On Fri, Oct 9, 2015 at 11:36 AM, Daniel Gruno 
> > wrote:
> > > Does there always have to be an actual problem before we can propose
> > > a policy? must we always be reactive instead of proactive?
> > >
> > > Yes, I am in a way implying that some mentors are, perhaps, not
> > > neutral in their work. I will not back it up with specific names or
> > > contexts, as I don't want to take a trip to lawsuit town for things
> > > I cannot back up with publicly available information.
> > >
> > > I don't find this to be uncivil accusations - can you outline a
> > > specific segment that you find uncivil? I am proposing a set of
> > > basic rules - which is naturally up for discussion and improvement -
> > > that would potentially alleviate us from having some nasty
> > > discussions - whether they be public or private - about the
> > > neutrality and honesty of recommendations, and hopefully ensure we
> > > have a more leveled playing field in the incubator.
> > >
> > > I'll stop here, as my eyesight is playing a trick on me today and
> > > not allowing me to see what I type.
> > >
> > > With regards,
> > > Daniel.
> > >
> > > On 10/09/2015 08:03 PM, Chris Douglas wrote:
> > >> What problem does this solve?
> > >>
> > >> This proposal lacks context. It implies that mentors are not
> > >> neutral, and that they are motivated by interests not shared by the
> > >> ASF. But it does not outline the merits of that belief, neither
> > >> does it specify how this proposal would address them. Instead of
> > >> allowing those definitions to float, this discussion would be more
> > >> productive if it were about some concrete problems for which there
> > >> is evidence. Yet another thread of rude responses to uncivil
> > >> accusations is unproductive, even if it is an IPMC tradition. -C
> > >>
> > >> On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno 
> > wrote:
> > >>> Hi Incubator folks,
> > >>>
> > >>> I would like to propose we adopt a mentor neutrality policy for
> > >>> incubating podlings:
> > >>>
> > >>> - A mentor must not be financially tied to the project or its
> > incubation
> > >>> status.
> > >>> - A mentor must not have a vested interest in incubating,
> > >>> graduating or dismantling a podling that goes beyond the general
> > >>> Apache mission
> > >>> - A mentor must not be affiliated with the entity granting the
> > >>> code (company or original project community)
> > >>>
> > >>> Furthermore, I would like to see this extended to votes on
> > >>> graduating
> > or
> > >>> retiring podlings, so that only people with no organizational
> > >>> (aparty from the ASF) or financial ties to the project (or the
> > >>> companies behind
> > >>> it) can cast a binding vote on graduation or retirement.
> > >>>
> > >>> This would essentially mean:
> > >>>
> > >>> - If you work 

Re: [VOTE] Accept Concerted into the Apache Incubator

[Julian Hyde]

I have agreed to be a mentor to Concerted and I think it is an
interesting idea. I am inclined to vote for it entering the incubator.

However since the project has not released any source code yet, there
are a couple of questions I'd like to get answered for the record:

1. How many lines of existing code are there? What is their approximate age?

2. Concerted is in C/C++ but you mention interfacing with JVM-based
products like Hive. How you would interface with other languages? Is
it a goal of the project to create APIs to other languages such as
Java? Would access from those languages be as efficient as native
access?

I apologize that I didn't bring these up in the discussion thread.

Julian


On Fri, Oct 9, 2015 at 11:53 AM, Ayrton Gomesz  wrote:
> +1
> @henry.saputra thanks man
> On Oct 9, 2015 5:50 PM, "Henry Saputra"  wrote:
>
>> +1 (binding)
>> Good luck guys!
>>
>> On Fri, Oct 9, 2015 at 8:55 AM, Atri Sharma  wrote:
>> > Hi all,
>> >
>> > Following the discussion about Concerted I would like to call a vote for
>> > accepting Concerted as a new incubator project.
>> >
>> > The proposal text is included below, and available on the wiki:
>> >
>> > https://wiki.apache.org/incubator/ConcertedProposal
>> >
>> > The vote is open for 72 hours:
>> >
>> > [ ] +1 accept Concerted in the Incubator
>> > [ ] ±0
>> > [ ] -1 (please give reason)
>> >
>> > Regards,
>> >
>> > Atri
>> >
>> > = Abstract =
>> >
>> > Concerted is an in memory write less read more engine aimed to provide
>> > extreme read performance with very high degree of concurrency and
>> > scalability and focus on minimizing own resource footprint.
>> >
>> > = Proposal =
>> > Concerted is built on the principal that a new type of workload is
>> > dominating the scene and is now needed to be supported. These are the
>> large
>> > data set analytical workloads being analyzed or used on large clusters or
>> > high power machines. Large analytical workloads depend on the ability to
>> > query large data sets efficiently and in high concurrency while
>> maintaining
>> > semantics such as immediate consistency. An in memory engine designed to
>> > support extreme read queries while providing support for aggregation
>> > through various features (such as multidimensional representation of
>> > tuples) will accelerate many usecases around large scale analytics.
>> >
>> > Concerted believes that best understanding of user application lies with
>> > user application developer. The need for massive read scaling should be
>> on
>> > demand and should be flexible to the level that user can decide as to
>> which
>> > representation and access of data suits his/her current requirements.
>> > Hence, Concerted is not built in a traditional client/server model.
>> > Concerted provides users with an API which can be used to load, read,
>> > update and delete data. User chooses which data structure has to be used
>> > for his current requirements. All API access is covered by Concerted's
>> > internal systems like lock manager, transaction manager and cache manager
>> > which ensure that reads scale to high level in every API call.
>> >
>> > Concerted is a Do It Yourself in memory platform for making in memory
>> > supporting engines. The use case we think of is supporting big data
>> > warehouses like Hive, but there are endless use cases for a custom,
>> highly
>> > scalable in memory platform.
>> >
>> > The goal of this proposal is to leverage an existing code base available
>> on
>> > Github and licensed under the Apache License 2.0 to build a community
>> > around the project. Currently the community consists of existing hackers
>> of
>> > Concerted as well as people who have been following and associated with
>> the
>> > project since a while as well as database experts who are excited about
>> > building a project like this. We are hoping that entering into Apache
>> would
>> > help us attract more contributors as well as connect with existing big
>> data
>> > projects like Apache Hive, Apache HAWQ, Apache Storm, Apache Tajo, Apache
>> > Spark, Apache Geode to leverage their community base while assisting in
>> > their use cases with Concerted. We had a discussion with founders of
>> Apache
>> > Tajo and they showed interest in using Concerted for some of their use
>> > cases.
>> > = Background =
>> > Relational databases were built with the cost of physical memory in mind.
>> > The cost is no longer very relevant and physical memory is now available
>> on
>> > demand. Another driving factor behind Concerted is that there is a
>> paradigm
>> > shift with big data coming into picture. Disk IO speeds are more of a
>> > bottleneck than ever before. Combining the read dominance of analytical
>> > workload with the speed of in memory structures, Concerted fits the
>> current
>> > scene. Also, supporting OLAP workloads with in memory support for faster
>> > read constant queries and joins will be 

Re: [VOTE] Accept Concerted into the Apache Incubator

[Julian Hyde]

Thanks for clarifying.

+1 (binding)

Julian


On Fri, Oct 9, 2015 at 2:09 PM, Atri Sharma  wrote:
> Hi,
>
> Please find answers below:
>
> 1) The main source code on Github wasn't updated for a while. However, the
> original and main core was written in 2013 and has been open source since
> then. As we discussed earlier current code base is only starting point for
> complete development and will be first integrated with silo work done
> independent and then used as starting implementation.
>
> 2) The JNI native API when optimized can provide great performance ( I have
> written an application using it and it is on production systems for many
> years). I think we can still provide a high performance API to the C++ core
> and that is something I am personally working on right now.
> On 10 Oct 2015 02:31, "Julian Hyde"  wrote:
>
>> I have agreed to be a mentor to Concerted and I think it is an
>> interesting idea. I am inclined to vote for it entering the incubator.
>>
>> However since the project has not released any source code yet, there
>> are a couple of questions I'd like to get answered for the record:
>>
>> 1. How many lines of existing code are there? What is their approximate
>> age?
>>
>> 2. Concerted is in C/C++ but you mention interfacing with JVM-based
>> products like Hive. How you would interface with other languages? Is
>> it a goal of the project to create APIs to other languages such as
>> Java? Would access from those languages be as efficient as native
>> access?
>>
>> I apologize that I didn't bring these up in the discussion thread.
>>
>> Julian
>>
>>
>> On Fri, Oct 9, 2015 at 11:53 AM, Ayrton Gomesz 
>> wrote:
>> > +1
>> > @henry.saputra thanks man
>> > On Oct 9, 2015 5:50 PM, "Henry Saputra"  wrote:
>> >
>> >> +1 (binding)
>> >> Good luck guys!
>> >>
>> >> On Fri, Oct 9, 2015 at 8:55 AM, Atri Sharma  wrote:
>> >> > Hi all,
>> >> >
>> >> > Following the discussion about Concerted I would like to call a vote
>> for
>> >> > accepting Concerted as a new incubator project.
>> >> >
>> >> > The proposal text is included below, and available on the wiki:
>> >> >
>> >> > https://wiki.apache.org/incubator/ConcertedProposal
>> >> >
>> >> > The vote is open for 72 hours:
>> >> >
>> >> > [ ] +1 accept Concerted in the Incubator
>> >> > [ ] ±0
>> >> > [ ] -1 (please give reason)
>> >> >
>> >> > Regards,
>> >> >
>> >> > Atri
>> >> >
>> >> > = Abstract =
>> >> >
>> >> > Concerted is an in memory write less read more engine aimed to provide
>> >> > extreme read performance with very high degree of concurrency and
>> >> > scalability and focus on minimizing own resource footprint.
>> >> >
>> >> > = Proposal =
>> >> > Concerted is built on the principal that a new type of workload is
>> >> > dominating the scene and is now needed to be supported. These are the
>> >> large
>> >> > data set analytical workloads being analyzed or used on large
>> clusters or
>> >> > high power machines. Large analytical workloads depend on the ability
>> to
>> >> > query large data sets efficiently and in high concurrency while
>> >> maintaining
>> >> > semantics such as immediate consistency. An in memory engine designed
>> to
>> >> > support extreme read queries while providing support for aggregation
>> >> > through various features (such as multidimensional representation of
>> >> > tuples) will accelerate many usecases around large scale analytics.
>> >> >
>> >> > Concerted believes that best understanding of user application lies
>> with
>> >> > user application developer. The need for massive read scaling should
>> be
>> >> on
>> >> > demand and should be flexible to the level that user can decide as to
>> >> which
>> >> > representation and access of data suits his/her current requirements.
>> >> > Hence, Concerted is not built in a traditional client/server model.
>> >> > Concerted provides users with an API which can be used to load, read,
>> >> > update and delete data. User chooses which data structure has to be
>> used
>> >> > for his current requirements. All API access is covered by Concerted's
>> >> > internal systems like lock manager, transaction manager and cache
>> manager
>> >> > which ensure that reads scale to high level in every API call.
>> >> >
>> >> > Concerted is a Do It Yourself in memory platform for making in memory
>> >> > supporting engines. The use case we think of is supporting big data
>> >> > warehouses like Hive, but there are endless use cases for a custom,
>> >> highly
>> >> > scalable in memory platform.
>> >> >
>> >> > The goal of this proposal is to leverage an existing code base
>> available
>> >> on
>> >> > Github and licensed under the Apache License 2.0 to build a community
>> >> > around the project. Currently the community consists of existing
>> hackers
>> >> of
>> >> > Concerted as well as people who have been following and associated
>> with
>> >> the
>> >> > project 

RE: [DISCUSS] Mentor neutrality policy

[Ross Gardler]

No. Meaning that starting from a place of no-trust in an environment where 
trust is critical is wrong.

Ross

-Original Message-
From: Pierre Smits [mailto:pierre.sm...@gmail.com] 
Sent: Friday, October 9, 2015 2:26 PM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Mentor neutrality policy

Meaning: proactively trying to doing the right thing, trying to define 
boundaries before wrongdoing happens, is wrong?

Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2foem.ofbizci.net%2foci-2%2f=01%7c01%7cRoss.Gardler%40microsoft.com%7ce3df44d6e18b409c180c08d2d0f042cc%7c72f988bf86f141af91ab2d7cd011db47%7c1=jTO4UHTjBVDxUGUNMAPv5ocD5hBmTU0Xj9xM1PTNWEk%3d

On Fri, Oct 9, 2015 at 10:51 PM, Chris Douglas  wrote:

> Daniel-
>
> If you have these concerns about mentors, a TLP proposal, or even an 
> active TLP substantiated only by private information: notify the board 
> via board-private@. That's why it's there.
>
> The proposal accuses mentors of selling influence, and acting contrary 
> to the foundation's interest. That is by definition a problem to which 
> we react, with proof of guilt. "Proactively" treating volunteers as 
> suspect demands that mentors prove their innocence. Assuming guilt is 
> not "proactive," but uncivil and immoral.
>
> There are also practical objections. Every IPMC member has a binding 
> vote on decisions made by the incubator, period. IPMC members may 
> voluntarily recuse themselves, but a policy that suppresses the votes 
> of "suspicious" groups is invalid.
>
> The TLP resolution is only recommended by the IPMC. Anything achieved 
> by this proposal is better implemented by the board considering that 
> recommendation in context- including evidence provided privately- and 
> rejecting improper proposals with actionable feedback to the PPMC. -C
>
> On Fri, Oct 9, 2015 at 11:36 AM, Daniel Gruno 
> wrote:
> > Does there always have to be an actual problem before we can propose 
> > a policy? must we always be reactive instead of proactive?
> >
> > Yes, I am in a way implying that some mentors are, perhaps, not 
> > neutral in their work. I will not back it up with specific names or 
> > contexts, as I don't want to take a trip to lawsuit town for things 
> > I cannot back up with publicly available information.
> >
> > I don't find this to be uncivil accusations - can you outline a 
> > specific segment that you find uncivil? I am proposing a set of 
> > basic rules - which is naturally up for discussion and improvement - 
> > that would potentially alleviate us from having some nasty 
> > discussions - whether they be public or private - about the 
> > neutrality and honesty of recommendations, and hopefully ensure we 
> > have a more leveled playing field in the incubator.
> >
> > I'll stop here, as my eyesight is playing a trick on me today and 
> > not allowing me to see what I type.
> >
> > With regards,
> > Daniel.
> >
> > On 10/09/2015 08:03 PM, Chris Douglas wrote:
> >> What problem does this solve?
> >>
> >> This proposal lacks context. It implies that mentors are not 
> >> neutral, and that they are motivated by interests not shared by the 
> >> ASF. But it does not outline the merits of that belief, neither 
> >> does it specify how this proposal would address them. Instead of 
> >> allowing those definitions to float, this discussion would be more 
> >> productive if it were about some concrete problems for which there 
> >> is evidence. Yet another thread of rude responses to uncivil 
> >> accusations is unproductive, even if it is an IPMC tradition. -C
> >>
> >> On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno 
> wrote:
> >>> Hi Incubator folks,
> >>>
> >>> I would like to propose we adopt a mentor neutrality policy for 
> >>> incubating podlings:
> >>>
> >>> - A mentor must not be financially tied to the project or its
> incubation
> >>> status.
> >>> - A mentor must not have a vested interest in incubating, 
> >>> graduating or dismantling a podling that goes beyond the general 
> >>> Apache mission
> >>> - A mentor must not be affiliated with the entity granting the 
> >>> code (company or original project community)
> >>>
> >>> Furthermore, I would like to see this extended to votes on 
> >>> graduating
> or
> >>> retiring podlings, so that only people with no organizational 
> >>> (aparty from the ASF) or financial ties to the project (or the 
> >>> companies behind
> >>> it) can cast a binding vote on graduation or retirement.
> >>>
> >>> This would essentially mean:
> >>>
> >>> - If you work for a company (or are hired as consultant/advisor) 
> >>> that
> is
> >>> entering a project into incubation, you cannot mentor it nor vote 
> >>> for/against its incubation, graduation or retirement.
> >>> - If you are a in the original community behind the project, you 
> >>> cannot mentor it nor vote for/against it.
> >>>
> >>> 

Re: [DISCUSS] Graduate Kylin from the Apache Incubator

[P. Taylor Goetz]

I agree.

It’s also worth discussing whether the “tasked with the creation of a set of 
bylaws” section of the proposal is really needed.

My understanding is that that section is not actually necessary, and has 
proliferated among projects largely due to copying/pasting of other graduation 
proposals. I believe it is only necessary if a project plans to deviate from 
the ASF standard ASF practices.

Just something to consider.

-Taylor

> On Oct 9, 2015, at 3:53 PM, Julian Hyde  wrote:
> 
> I am a mentor of Kylin and I believe the project is ready to graduate.
> They have created a vibrant, open community and are conducting
> business in the Apache Way.
> 
> One proviso: Let's complete the name search before starting the IPMC
> vote. It would be foolish to let that particular cart get in front of
> the horse. I don't think that prevents us from discussing graduation.
> 
> Julian
> 
> 
> On Fri, Oct 9, 2015 at 10:44 AM, Samant, Medha  wrote:
>> +1
>> 
>> On 10/9/15, 10:13 AM, "Adunuthula, Seshu"  wrote:
>> 
>>> +1
>>> 
>>> On 10/7/15, 8:32 AM, "John D. Ament"  wrote:
>>> 
 I would be happy to see kylin graduate.
 On Oct 7, 2015 11:28, "Luke Han"  wrote:
 
> The Kylin community and project made significant advances during the
> incubating (from Nov 2014) and
> believes it is ready to graduate as a top-level project.
> 
> The Apache Kylin is very active. The PPMC doubled in size (added 6
> committers and 2 mentors) and
> increased diversity in the past year. Released 3 version in the past 6
> months. There were presentations about Kylin
> at most of the big conferences of the world (including Strata+Hadoop
> World
> London, Hadoop Summit San Jose,
> ApacheCon EU, Big Data Technology China, Database Technology Conference
> China) and some meetups (Bay Area,
> Beijing and one is coming in this weekend in Shanghai), and many talks
> around the world.
> The dev mailing list is growing very month, about 500+ topics per month
> now.
> The community created 1000+ JIRA tickets, many patches from
> contributors/committers have been merged into code base.
> 
> A vote passed unanimously on the dev@ list (27 +1 votes). Please find
> below
> references to the graduation preparation artifacts:
> * discussion on dev list [1]
> * vote thread [2]
> * podling name search (still in progress) [3]
> * incubation status [4]
> * proposed resolution below
> 
> We believe Apache Kylin is ready to become a top-level project and if
> the
> IPMC agree we will move to a formal vote.
> There are a few more items to be updated on the project status page and
> others during the next couple of days.
> 
> 
> Many thanks to the mentors and the IPMC for the support,
> Luke Han (on behalf of the Apache Kylin PPMC)
> 
> [1] http://s.apache.org/KylinDisGraduate
> [2] http://s.apache.org/KylinGraduateVote
> [3] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-86
> [4] http://incubator.apache.org/projects/kylin.html
> 
> 
> 
> Apache Kylin top-level project resolution:
> ===
> 
>   WHEREAS, the Board of Directors deems it to be in the best
>   interests of the Foundation and consistent with the
>   Foundation's purpose to establish a Project Management
>   Committee charged with the creation and maintenance of
>   open-source software, for distribution at no charge to the
>   public, relative to distributed and scalable OLAP engine
> 
>   NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>   Committee (PMC), to be known as the "Apache Kylin Project",
>   be and hereby is established pursuant to Bylaws of the
>   Foundation; and be it further
> 
>   RESOLVED, that the Apache Kylin Project be and hereby is
>   responsible for the creation and maintenance of open-source
>   software related to distributed and scalable OLAP engine;
>   and be it further
> 
>   RESOLVED, that the office of "Vice President, Kylin" be and
>   hereby is created, the person holding such office to serve at
>   the direction of the Board of Directors as the chair of the
>   Apache Kylin Project, and to have primary responsibility for
>   management of the projects within the scope of responsibility
>   of the Apache Kylin Project; and be it further
> 
>   RESOLVED, that the persons listed immediately below be and
>   hereby are appointed to serve as the initial members of the
>   Apache Kylin Project:
> 
>* Dayue Gao 
>* Jason Zhong 
>* Julian Hyde 
>* Luke Han 
>* Henry 

Re: [DISCUSS] Mentor neutrality policy

[Chris Douglas]

Daniel-

If you have these concerns about mentors, a TLP proposal, or even an
active TLP substantiated only by private information: notify the board
via board-private@. That's why it's there.

The proposal accuses mentors of selling influence, and acting contrary
to the foundation's interest. That is by definition a problem to which
we react, with proof of guilt. "Proactively" treating volunteers as
suspect demands that mentors prove their innocence. Assuming guilt is
not "proactive," but uncivil and immoral.

There are also practical objections. Every IPMC member has a binding
vote on decisions made by the incubator, period. IPMC members may
voluntarily recuse themselves, but a policy that suppresses the votes
of "suspicious" groups is invalid.

The TLP resolution is only recommended by the IPMC. Anything achieved
by this proposal is better implemented by the board considering that
recommendation in context- including evidence provided privately- and
rejecting improper proposals with actionable feedback to the PPMC. -C

On Fri, Oct 9, 2015 at 11:36 AM, Daniel Gruno  wrote:
> Does there always have to be an actual problem before we can propose a
> policy? must we always be reactive instead of proactive?
>
> Yes, I am in a way implying that some mentors are, perhaps, not neutral
> in their work. I will not back it up with specific names or contexts, as
> I don't want to take a trip to lawsuit town for things I cannot back up
> with publicly available information.
>
> I don't find this to be uncivil accusations - can you outline a specific
> segment that you find uncivil? I am proposing a set of basic rules -
> which is naturally up for discussion and improvement - that would
> potentially alleviate us from having some nasty discussions - whether
> they be public or private - about the neutrality and honesty of
> recommendations, and hopefully ensure we have a more leveled playing
> field in the incubator.
>
> I'll stop here, as my eyesight is playing a trick on me today and not
> allowing me to see what I type.
>
> With regards,
> Daniel.
>
> On 10/09/2015 08:03 PM, Chris Douglas wrote:
>> What problem does this solve?
>>
>> This proposal lacks context. It implies that mentors are not neutral,
>> and that they are motivated by interests not shared by the ASF. But it
>> does not outline the merits of that belief, neither does it specify
>> how this proposal would address them. Instead of allowing those
>> definitions to float, this discussion would be more productive if it
>> were about some concrete problems for which there is evidence. Yet
>> another thread of rude responses to uncivil accusations is
>> unproductive, even if it is an IPMC tradition. -C
>>
>> On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno  wrote:
>>> Hi Incubator folks,
>>>
>>> I would like to propose we adopt a mentor neutrality policy for
>>> incubating podlings:
>>>
>>> - A mentor must not be financially tied to the project or its incubation
>>> status.
>>> - A mentor must not have a vested interest in incubating, graduating or
>>> dismantling a podling that goes beyond the general Apache mission
>>> - A mentor must not be affiliated with the entity granting the code
>>> (company or original project community)
>>>
>>> Furthermore, I would like to see this extended to votes on graduating or
>>> retiring podlings, so that only people with no organizational (aparty
>>> from the ASF) or financial ties to the project (or the companies behind
>>> it) can cast a binding vote on graduation or retirement.
>>>
>>> This would essentially mean:
>>>
>>> - If you work for a company (or are hired as consultant/advisor) that is
>>> entering a project into incubation, you cannot mentor it nor vote
>>> for/against its incubation, graduation or retirement.
>>> - If you are a in the original community behind the project, you cannot
>>> mentor it nor vote for/against it.
>>>
>>> I believe this would create a neutral mentorship whose sole mission is
>>> to guide podlings with the interests of the ASF in mind.
>>>
>>>
>>> Please do discuss this. If there is (mostly) positive feedback, I would
>>> like to, at some point, have a vote on including this in the Incubator
>>> policy. I realize this would cut down on the number of potential
>>> mentors, and I would ask that more people step up to the challenge of
>>> mentoring if adopted.
>>>
>>> With regards,
>>> Daniel
>>>
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: 

Re: [DISCUSS] Graduate Kylin from the Apache Incubator

[Pierre Smits]

Maybe the podling has a valid reason behind that choice. So let us not
chuck that out of the window because of other podlings not paying attention
to what they did.

Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Fri, Oct 9, 2015 at 10:42 PM, P. Taylor Goetz  wrote:

> I agree.
>
> It’s also worth discussing whether the “tasked with the creation of a set
> of bylaws” section of the proposal is really needed.
>
> My understanding is that that section is not actually necessary, and has
> proliferated among projects largely due to copying/pasting of other
> graduation proposals. I believe it is only necessary if a project plans to
> deviate from the ASF standard ASF practices.
>
> Just something to consider.
>
> -Taylor
>
> > On Oct 9, 2015, at 3:53 PM, Julian Hyde  wrote:
> >
> > I am a mentor of Kylin and I believe the project is ready to graduate.
> > They have created a vibrant, open community and are conducting
> > business in the Apache Way.
> >
> > One proviso: Let's complete the name search before starting the IPMC
> > vote. It would be foolish to let that particular cart get in front of
> > the horse. I don't think that prevents us from discussing graduation.
> >
> > Julian
> >
> >
> > On Fri, Oct 9, 2015 at 10:44 AM, Samant, Medha  wrote:
> >> +1
> >>
> >> On 10/9/15, 10:13 AM, "Adunuthula, Seshu"  wrote:
> >>
> >>> +1
> >>>
> >>> On 10/7/15, 8:32 AM, "John D. Ament"  wrote:
> >>>
>  I would be happy to see kylin graduate.
>  On Oct 7, 2015 11:28, "Luke Han"  wrote:
> 
> > The Kylin community and project made significant advances during the
> > incubating (from Nov 2014) and
> > believes it is ready to graduate as a top-level project.
> >
> > The Apache Kylin is very active. The PPMC doubled in size (added 6
> > committers and 2 mentors) and
> > increased diversity in the past year. Released 3 version in the past
> 6
> > months. There were presentations about Kylin
> > at most of the big conferences of the world (including Strata+Hadoop
> > World
> > London, Hadoop Summit San Jose,
> > ApacheCon EU, Big Data Technology China, Database Technology
> Conference
> > China) and some meetups (Bay Area,
> > Beijing and one is coming in this weekend in Shanghai), and many
> talks
> > around the world.
> > The dev mailing list is growing very month, about 500+ topics per
> month
> > now.
> > The community created 1000+ JIRA tickets, many patches from
> > contributors/committers have been merged into code base.
> >
> > A vote passed unanimously on the dev@ list (27 +1 votes). Please
> find
> > below
> > references to the graduation preparation artifacts:
> > * discussion on dev list [1]
> > * vote thread [2]
> > * podling name search (still in progress) [3]
> > * incubation status [4]
> > * proposed resolution below
> >
> > We believe Apache Kylin is ready to become a top-level project and if
> > the
> > IPMC agree we will move to a formal vote.
> > There are a few more items to be updated on the project status page
> and
> > others during the next couple of days.
> >
> >
> > Many thanks to the mentors and the IPMC for the support,
> > Luke Han (on behalf of the Apache Kylin PPMC)
> >
> > [1] http://s.apache.org/KylinDisGraduate
> > [2] http://s.apache.org/KylinGraduateVote
> > [3] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-86
> > [4] http://incubator.apache.org/projects/kylin.html
> >
> >
> >
> > Apache Kylin top-level project resolution:
> > ===
> >
> >   WHEREAS, the Board of Directors deems it to be in the best
> >   interests of the Foundation and consistent with the
> >   Foundation's purpose to establish a Project Management
> >   Committee charged with the creation and maintenance of
> >   open-source software, for distribution at no charge to the
> >   public, relative to distributed and scalable OLAP engine
> >
> >   NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> >   Committee (PMC), to be known as the "Apache Kylin Project",
> >   be and hereby is established pursuant to Bylaws of the
> >   Foundation; and be it further
> >
> >   RESOLVED, that the Apache Kylin Project be and hereby is
> >   responsible for the creation and maintenance of open-source
> >   software related to distributed and scalable OLAP engine;
> >   and be it further
> >
> >   RESOLVED, that the office of "Vice President, Kylin" be and
> >   hereby is created, the person holding such office to serve at
> >   the direction of the Board of Directors as the chair of 

Re: [VOTE] Accept Concerted into the Apache Incubator

[larsh]

+1 (binding)
This is exciting!Thanks for putting this together Atri.
-- Lars
  From: Atri Sharma 
 To: general@incubator.apache.org 
 Sent: Friday, October 9, 2015 8:55 AM
 Subject: [VOTE] Accept Concerted into the Apache Incubator
   
Hi all,

Following the discussion about Concerted I would like to call a vote for
accepting Concerted as a new incubator project.

The proposal text is included below, and available on the wiki:

https://wiki.apache.org/incubator/ConcertedProposal

The vote is open for 72 hours:

[ ] +1 accept Concerted in the Incubator
[ ] ±0
[ ] -1 (please give reason)

Regards,

Atri

= Abstract =

Concerted is an in memory write less read more engine aimed to provide
extreme read performance with very high degree of concurrency and
scalability and focus on minimizing own resource footprint.

= Proposal =
Concerted is built on the principal that a new type of workload is
dominating the scene and is now needed to be supported. These are the large
data set analytical workloads being analyzed or used on large clusters or
high power machines. Large analytical workloads depend on the ability to
query large data sets efficiently and in high concurrency while maintaining
semantics such as immediate consistency. An in memory engine designed to
support extreme read queries while providing support for aggregation
through various features (such as multidimensional representation of
tuples) will accelerate many usecases around large scale analytics.

Concerted believes that best understanding of user application lies with
user application developer. The need for massive read scaling should be on
demand and should be flexible to the level that user can decide as to which
representation and access of data suits his/her current requirements.
Hence, Concerted is not built in a traditional client/server model.
Concerted provides users with an API which can be used to load, read,
update and delete data. User chooses which data structure has to be used
for his current requirements. All API access is covered by Concerted's
internal systems like lock manager, transaction manager and cache manager
which ensure that reads scale to high level in every API call.

Concerted is a Do It Yourself in memory platform for making in memory
supporting engines. The use case we think of is supporting big data
warehouses like Hive, but there are endless use cases for a custom, highly
scalable in memory platform.

The goal of this proposal is to leverage an existing code base available on
Github and licensed under the Apache License 2.0 to build a community
around the project. Currently the community consists of existing hackers of
Concerted as well as people who have been following and associated with the
project since a while as well as database experts who are excited about
building a project like this. We are hoping that entering into Apache would
help us attract more contributors as well as connect with existing big data
projects like Apache Hive, Apache HAWQ, Apache Storm, Apache Tajo, Apache
Spark, Apache Geode to leverage their community base while assisting in
their use cases with Concerted. We had a discussion with founders of Apache
Tajo and they showed interest in using Concerted for some of their use
cases.
= Background =
Relational databases were built with the cost of physical memory in mind.
The cost is no longer very relevant and physical memory is now available on
demand. Another driving factor behind Concerted is that there is a paradigm
shift with big data coming into picture. Disk IO speeds are more of a
bottleneck than ever before. Combining the read dominance of analytical
workload with the speed of in memory structures, Concerted fits the current
scene. Also, supporting OLAP workloads with in memory support for faster
read constant queries and joins will be useful.

= Rationale =
As explained above, large analytical workloads need an in memory
lightweight engine which supports massive read concurrency, ground level
support for aggregations and analytics, extreme scalability and high read
performance, along with the engine being very light itself. Concerted aims
to solve these needs. Concerted is designed and built with three goals as
objectives:


Performance
    To provide high performance access to data from a large number of rows,
Concerted uses efficient representation and in memory indexing of data
coupled with high performance transactions, custom transactions and
lightweight locking and lockless techniques and an intelligent locking
manager.

Scalability
    Concerted is built with extreme concurrency and scalability in mind.

Efficiency
    Concerted aims to give expected performance under vast variety of
workloads and aims to have as low footprint as possible.

= Initial Goals =
The initial goal is to leverage an existing code base and invest in
building a community around the project. We anticipate a lot of initial
restructuring of the existing code so that it becomes 

Re: [DISCUSS] Mentor neutrality policy

[Andrew Purtell]

We should address perceived, and certainly provable, instances of
corruption at the Foundation directly, rather than prescribe policy that
seeks to prevent future instances as if there is a precedent (but there
isn't one here... at least one not spoken aloud, right?).

> A mentor must not be financially tied to the project or its incubation
status.

Aside from deviating greatly from treating mentors and all other persons as
individuals, for verification purposes this would require a level of
intrusive financial reporting that we don't remotely approach today and to
which most members would probably object.

> A mentor must not have a vested interest in incubating, graduating or
dismantling a podling that goes beyond the general Apache mission

None of this is well defined.

> If you are a in the original community behind the project, you cannot
mentor it nor vote for/against it.

​This diminishes the pool of available mentors and in particular those
probably most vested in the success of the podling.​




On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno  wrote:

> Hi Incubator folks,
>
> I would like to propose we adopt a mentor neutrality policy for
> incubating podlings:
>
> - A mentor must not be financially tied to the project or its incubation
> status.
> - A mentor must not have a vested interest in incubating, graduating or
> dismantling a podling that goes beyond the general Apache mission
> - A mentor must not be affiliated with the entity granting the code
> (company or original project community)
>
> Furthermore, I would like to see this extended to votes on graduating or
> retiring podlings, so that only people with no organizational (aparty
> from the ASF) or financial ties to the project (or the companies behind
> it) can cast a binding vote on graduation or retirement.
>
> This would essentially mean:
>
> - If you work for a company (or are hired as consultant/advisor) that is
> entering a project into incubation, you cannot mentor it nor vote
> for/against its incubation, graduation or retirement.
> - If you are a in the original community behind the project, you cannot
> mentor it nor vote for/against it.
>
> I believe this would create a neutral mentorship whose sole mission is
> to guide podlings with the interests of the ASF in mind.
>
>
> Please do discuss this. If there is (mostly) positive feedback, I would
> like to, at some point, have a vote on including this in the Incubator
> policy. I realize this would cut down on the number of potential
> mentors, and I would ask that more people step up to the challenge of
> mentoring if adopted.
>
> With regards,
> Daniel
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: Advice on LICENSE/NOTICE for Shaded Dependencies

[Mark Thomas]

On 09/10/2015 19:12, Stephen Mallette wrote:
> Hello all,
> 
> I feel like I'm on the verge of getting LICENSE/NOTICE right in all
> respects in The TinkerPop.  . Seems like there's one piece that's out of
> place and could use some advice as I wasn't able to map anything I'd read
> in the Apache docs on this topic to my issue.  We currently shade several
> libraries: Kryo, minlog, objenesis, and jackson, essentially re-packaging
> those binary dependencies in a jar called gremlin-shaded.jar. The
> gremlin-shaded.jar is then made part of our zip distributions.
> 
> As we didn't re-package the source code of these libs, I figured that the
> source LICENSE/NOTICE didn't need to change and that it was just the binary
> LICENSE/NOTICE that needed to change.  I assume this situation is somewhat
> similar to a project that builds an uber jar for distribution.
> 
> So that's where i'm about stuck. I took a wild stab at it and did this:
> 
> https://github.com/apache/incubator-tinkerpop/blob/5a8b61c09868e22a415c0469a2737d68acce9a4e/gremlin-console/src/main/LICENSE#L226-L228
> 
> but I have no idea if that is sufficient (or just plain wrong).  If anyone
> could offer some pointers on what needs to happen here to our binary
> LICENSE/NOTICE, that would be nice.  I'd really like to see us get a clean
> bill of health on the next LICENSE/NOTICE that goes through a release vote.

Looks good to me. The only thing I'd consider adding is what package
they were renamed to.

Mark


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Concerted into the Apache Incubator

[Chris Nauroth]

+1 (binding)

Thank you, Atri.

--Chris Nauroth




On 10/9/15, 8:55 AM, "Atri Sharma"  wrote:

>Hi all,
>
>Following the discussion about Concerted I would like to call a vote for
>accepting Concerted as a new incubator project.
>
>The proposal text is included below, and available on the wiki:
>
>https://wiki.apache.org/incubator/ConcertedProposal
>
>The vote is open for 72 hours:
>
>[ ] +1 accept Concerted in the Incubator
>[ ] ±0
>[ ] -1 (please give reason)
>
>Regards,
>
>Atri
>
>= Abstract =
>
>Concerted is an in memory write less read more engine aimed to provide
>extreme read performance with very high degree of concurrency and
>scalability and focus on minimizing own resource footprint.
>
>= Proposal =
>Concerted is built on the principal that a new type of workload is
>dominating the scene and is now needed to be supported. These are the
>large
>data set analytical workloads being analyzed or used on large clusters or
>high power machines. Large analytical workloads depend on the ability to
>query large data sets efficiently and in high concurrency while
>maintaining
>semantics such as immediate consistency. An in memory engine designed to
>support extreme read queries while providing support for aggregation
>through various features (such as multidimensional representation of
>tuples) will accelerate many usecases around large scale analytics.
>
>Concerted believes that best understanding of user application lies with
>user application developer. The need for massive read scaling should be on
>demand and should be flexible to the level that user can decide as to
>which
>representation and access of data suits his/her current requirements.
>Hence, Concerted is not built in a traditional client/server model.
>Concerted provides users with an API which can be used to load, read,
>update and delete data. User chooses which data structure has to be used
>for his current requirements. All API access is covered by Concerted's
>internal systems like lock manager, transaction manager and cache manager
>which ensure that reads scale to high level in every API call.
>
>Concerted is a Do It Yourself in memory platform for making in memory
>supporting engines. The use case we think of is supporting big data
>warehouses like Hive, but there are endless use cases for a custom, highly
>scalable in memory platform.
>
>The goal of this proposal is to leverage an existing code base available
>on
>Github and licensed under the Apache License 2.0 to build a community
>around the project. Currently the community consists of existing hackers
>of
>Concerted as well as people who have been following and associated with
>the
>project since a while as well as database experts who are excited about
>building a project like this. We are hoping that entering into Apache
>would
>help us attract more contributors as well as connect with existing big
>data
>projects like Apache Hive, Apache HAWQ, Apache Storm, Apache Tajo, Apache
>Spark, Apache Geode to leverage their community base while assisting in
>their use cases with Concerted. We had a discussion with founders of
>Apache
>Tajo and they showed interest in using Concerted for some of their use
>cases.
>= Background =
>Relational databases were built with the cost of physical memory in mind.
>The cost is no longer very relevant and physical memory is now available
>on
>demand. Another driving factor behind Concerted is that there is a
>paradigm
>shift with big data coming into picture. Disk IO speeds are more of a
>bottleneck than ever before. Combining the read dominance of analytical
>workload with the speed of in memory structures, Concerted fits the
>current
>scene. Also, supporting OLAP workloads with in memory support for faster
>read constant queries and joins will be useful.
>
>= Rationale =
>As explained above, large analytical workloads need an in memory
>lightweight engine which supports massive read concurrency, ground level
>support for aggregations and analytics, extreme scalability and high read
>performance, along with the engine being very light itself. Concerted aims
>to solve these needs. Concerted is designed and built with three goals as
>objectives:
>
>
>Performance
>To provide high performance access to data from a large number of
>rows,
>Concerted uses efficient representation and in memory indexing of data
>coupled with high performance transactions, custom transactions and
>lightweight locking and lockless techniques and an intelligent locking
>manager.
>
>Scalability
>Concerted is built with extreme concurrency and scalability in mind.
>
>Efficiency
>Concerted aims to give expected performance under vast variety of
>workloads and aims to have as low footprint as possible.
>
>= Initial Goals =
>The initial goal is to leverage an existing code base and invest in
>building a community around the project. We anticipate a lot of initial
>restructuring of the existing code so that it becomes easier to include
>new

Re: Concerted Proposal

[Atri Sharma]

Hi All,

Proposal is posted for voting.

Please vote.

Regards,

Atri

On Wed, Oct 7, 2015 at 1:59 PM, Atri Sharma  wrote:

> Hi All,
>
> I have posted proposal in Discuss thread.
>
> Please provide your contributions there.
>
> Regards,
>
> Atri
>
> On Wed, Oct 7, 2015 at 12:27 AM, Atri Sharma  wrote:
>
>> Thanks for your opinion.
>>
>> On Tue, Oct 6, 2015 at 4:50 PM, Sergio Fernández 
>> wrote:
>>
>>> I just wanted to state the fact that mentoring is not expected to take an
>>> active role in technical questions.
>>
>>
>> I agree for that and I understand that we are not looking for technical
>> mentoring. However, if our mentors are wishing to help us in that manner,
>> we will be more than happy.
>>
>> Moreover arguing that "bootstrapping
>>> the existing code base and community into ASF will generate much more
>>> interest" clearly shows an excessive fascination with the Apache brand.
>>>
>>
>> I respectfully disagree. I think the motivation here is not attracting
>> more people into the community using Apache brand but manage existing and
>> future community using Apache processes. I believe that managing our
>> community with the Apache way is a better way of handling the community and
>> that is what we mean when we say that the community management process is
>> easier and healthier with Apache way.
>>
>> For the visibility side, we believe that the biggest advantage Concerted
>> will have is that it will have a chance to be directed and helped by big
>> data projects which are end user targets for Concerted. The primary target
>> for Concerted is to be support engine platform for big data projects and
>> Apache Big Data projects are the biggest use cases that we see. Hence, we
>> see the project as a liable candidate for ASF project and since we aim to
>> have Concerted be in sync with needs and use cases for Apache Big Data
>> projects, it seems logical to have Concerted as an ASF project early on and
>> be able to start helping Apache Big Data projects. Community development in
>> this case only means the potential direction or support project might get
>> from Apache Big Data projects that might be interested in Concerted. I
>> assure you that it is not a translation of excessive fascination with
>> Apache brand for us. If we are incorrect please correct us.
>>
>>
>>> In
>>> the end you have to take into account that been a podling introduces
>>> quite
>>> some overhead, which personally I don't find healthy in such very early
>>> stage.
>>>
>>> But well, looks the proposal has enough support, so my opinion is just
>>> that, an individual opinion. Go ahead with the proposal, and all the
>>> best!
>>>
>>
>> Thank you.
>>
>>>
>>>
>>> On Mon, Oct 5, 2015 at 10:51 AM,  wrote:
>>>
>>> > As a member of Concerted community, I believe that acceptance into ASF
>>> > Incubator is beneficial for Concerted especially in terms of community
>>> > support. Being an independent project on github really does not help
>>> when
>>> > we want to build a healthy community of people interested in Concerted
>>> and
>>> > aiming to take Concerted to ultimate goal we have i.e. being the
>>> primary in
>>> > memory support framework for big data engines. I really feel that
>>> > bootstrapping the existing code base and community into ASF will
>>> generate
>>> > much more interest, visibility and allow the community to be regulated
>>> in a
>>> > much better manner.
>>> >
>>> > Also, I agree with Atri on the fact that since our eventual goal is to
>>> be
>>> > supporting existing big data projects, working with them early on is a
>>> > great way to improve our roadmap and get contributions from those
>>> projects.
>>> >
>>> > As a person who has been revamping Concerted code base for a while
>>> now, I
>>> > believe that the existing code base is a great place to pick up the
>>> main
>>> > development of Concerted.
>>> >
>>> > Nupur
>>> >
>>> >
>>> > On 05/10/2015 02:09 PM, Atri Sharma wrote:
>>> >
>>> >> While I do not disagree with the fact that the code base can evolve at
>>> >> github, the situation here is a bit different. Preliminary though it
>>> is,
>>> >> Concerted does have an existing code base. The bigger question is
>>> having
>>> >> the code base evolve at a higher frequency with a wider community.
>>> >>
>>> >> I think that if Concerted becomes a part of ASF Incubator, it has a
>>> much
>>> >> higher chance of evolving into a wider product with a much better
>>> >> alignment
>>> >> with the existing Apache big data ecosystem. Concerted provides the
>>> >> ability
>>> >> to DIY big data in memory support engines, with a high degree of
>>> custom
>>> >> building for each user project.
>>> >>
>>> >> The reason why Concerted is proposed to become part of ASF Incubator
>>> is
>>> >> that Concerted is a small project right now, with a roadmap and a set
>>> of
>>> >> developers. Getting into ASF allows the Concerted project to 

Re: [DISCUSS] Mentor neutrality policy

[Shane Curcuru]

Daniel Gruno wrote on 10/9/15 11:07 AM:
> Hi Incubator folks,
> 
> I would like to propose we adopt a mentor neutrality policy for
> incubating podlings:
> 
> - A mentor must not be financially tied to the project or its incubation
> status.
> - A mentor must not have a vested interest in incubating, graduating or
> dismantling a podling that goes beyond the general Apache mission
> - A mentor must not be affiliated with the entity granting the code
> (company or original project community)
> 
> Furthermore, I would like to see this extended to votes on graduating or
> retiring podlings, so that only people with no organizational (aparty
> from the ASF) or financial ties to the project (or the companies behind
> it) can cast a binding vote on graduation or retirement.
> 
> This would essentially mean:
> 
> - If you work for a company (or are hired as consultant/advisor) that is
> entering a project into incubation, you cannot mentor it nor vote
> for/against its incubation, graduation or retirement.
> - If you are a in the original community behind the project, you cannot
> mentor it nor vote for/against it.
> 
> I believe this would create a neutral mentorship whose sole mission is
> to guide podlings with the interests of the ASF in mind.
> 

This ties directly into the concept of independent project governance:

  http://community.apache.org/projectIndependence.html

It's really hard to feel confident that each of our soon-to-graduate
podlings is truly operating as an independent project in some cases.

Question: has everyone here read that essay?  Does everyone here agree
that project independence as described in general terms there is a
requirement of every TLP?  Do people think that this concept is clear to
every Apache PMC?

The fact that we are the "Switzerland of software" - a vendor-neutral
place where everyone could be comfortable collaborating, and we ensure
all of our governance is truly independent of commercial influence or
the influence of our various employers - is probably the hardest issue
we face in the big picture.  I sometimes wonder if we all are on the
same page with that point.

It's clear that the details of any changes here need discussion, and our
general rule of having at least three mentors (presumably, not all of
whom are at the same employer) goes a long way to helping.

But if you think about conflict of interest laws and procedures in the
world of corporate software - or really, any sort of business - the ASF
is the far outlier in trusting and assuming that we are all individuals
wearing our appropriate Apache hat.  That's a good thing, and it's part
of what makes the ASF special - but we also need to remember that the
rest of the world does not always understand our almost laissez-faire
way of treating everyone as an individual unaffected by their outside
affiliations.

- Shane

> 
> Please do discuss this. If there is (mostly) positive feedback, I would
> like to, at some point, have a vote on including this in the Incubator
> policy. I realize this would cut down on the number of potential
> mentors, and I would ask that more people step up to the challenge of
> mentoring if adopted.
> 
> With regards,
> Daniel
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Accept Concerted into the Apache Incubator

[Atri Sharma]

Hi all,

Following the discussion about Concerted I would like to call a vote for
accepting Concerted as a new incubator project.

The proposal text is included below, and available on the wiki:

https://wiki.apache.org/incubator/ConcertedProposal

The vote is open for 72 hours:

[ ] +1 accept Concerted in the Incubator
[ ] ±0
[ ] -1 (please give reason)

Regards,

Atri

= Abstract =

Concerted is an in memory write less read more engine aimed to provide
extreme read performance with very high degree of concurrency and
scalability and focus on minimizing own resource footprint.

= Proposal =
Concerted is built on the principal that a new type of workload is
dominating the scene and is now needed to be supported. These are the large
data set analytical workloads being analyzed or used on large clusters or
high power machines. Large analytical workloads depend on the ability to
query large data sets efficiently and in high concurrency while maintaining
semantics such as immediate consistency. An in memory engine designed to
support extreme read queries while providing support for aggregation
through various features (such as multidimensional representation of
tuples) will accelerate many usecases around large scale analytics.

Concerted believes that best understanding of user application lies with
user application developer. The need for massive read scaling should be on
demand and should be flexible to the level that user can decide as to which
representation and access of data suits his/her current requirements.
Hence, Concerted is not built in a traditional client/server model.
Concerted provides users with an API which can be used to load, read,
update and delete data. User chooses which data structure has to be used
for his current requirements. All API access is covered by Concerted's
internal systems like lock manager, transaction manager and cache manager
which ensure that reads scale to high level in every API call.

Concerted is a Do It Yourself in memory platform for making in memory
supporting engines. The use case we think of is supporting big data
warehouses like Hive, but there are endless use cases for a custom, highly
scalable in memory platform.

The goal of this proposal is to leverage an existing code base available on
Github and licensed under the Apache License 2.0 to build a community
around the project. Currently the community consists of existing hackers of
Concerted as well as people who have been following and associated with the
project since a while as well as database experts who are excited about
building a project like this. We are hoping that entering into Apache would
help us attract more contributors as well as connect with existing big data
projects like Apache Hive, Apache HAWQ, Apache Storm, Apache Tajo, Apache
Spark, Apache Geode to leverage their community base while assisting in
their use cases with Concerted. We had a discussion with founders of Apache
Tajo and they showed interest in using Concerted for some of their use
cases.
= Background =
Relational databases were built with the cost of physical memory in mind.
The cost is no longer very relevant and physical memory is now available on
demand. Another driving factor behind Concerted is that there is a paradigm
shift with big data coming into picture. Disk IO speeds are more of a
bottleneck than ever before. Combining the read dominance of analytical
workload with the speed of in memory structures, Concerted fits the current
scene. Also, supporting OLAP workloads with in memory support for faster
read constant queries and joins will be useful.

= Rationale =
As explained above, large analytical workloads need an in memory
lightweight engine which supports massive read concurrency, ground level
support for aggregations and analytics, extreme scalability and high read
performance, along with the engine being very light itself. Concerted aims
to solve these needs. Concerted is designed and built with three goals as
objectives:


Performance
To provide high performance access to data from a large number of rows,
Concerted uses efficient representation and in memory indexing of data
coupled with high performance transactions, custom transactions and
lightweight locking and lockless techniques and an intelligent locking
manager.

Scalability
Concerted is built with extreme concurrency and scalability in mind.

Efficiency
Concerted aims to give expected performance under vast variety of
workloads and aims to have as low footprint as possible.

= Initial Goals =
The initial goal is to leverage an existing code base and invest in
building a community around the project. We anticipate a lot of initial
restructuring of the existing code so that it becomes easier to include new
contributors and minimize ramp up time. We plan to approach this
refactoring in a fully transparent, community-driven way thus starting to
practice the "Apache Way" governance model from the get go.

Various contributors are getting 

Re: [DISCUSS] Graduate Kylin from the Apache Incubator

[Adunuthula, Seshu]

+1 

On 10/7/15, 8:32 AM, "John D. Ament"  wrote:

>I would be happy to see kylin graduate.
>On Oct 7, 2015 11:28, "Luke Han"  wrote:
>
>> The Kylin community and project made significant advances during the
>> incubating (from Nov 2014) and
>> believes it is ready to graduate as a top-level project.
>>
>> The Apache Kylin is very active. The PPMC doubled in size (added 6
>> committers and 2 mentors) and
>>  increased diversity in the past year. Released 3 version in the past 6
>> months. There were presentations about Kylin
>> at most of the big conferences of the world (including Strata+Hadoop
>>World
>> London, Hadoop Summit San Jose,
>> ApacheCon EU, Big Data Technology China, Database Technology Conference
>> China) and some meetups (Bay Area,
>> Beijing and one is coming in this weekend in Shanghai), and many talks
>> around the world.
>> The dev mailing list is growing very month, about 500+ topics per month
>> now.
>> The community created 1000+ JIRA tickets, many patches from
>> contributors/committers have been merged into code base.
>>
>> A vote passed unanimously on the dev@ list (27 +1 votes). Please find
>> below
>> references to the graduation preparation artifacts:
>> * discussion on dev list [1]
>> * vote thread [2]
>> * podling name search (still in progress) [3]
>> * incubation status [4]
>> * proposed resolution below
>>
>> We believe Apache Kylin is ready to become a top-level project and if
>>the
>> IPMC agree we will move to a formal vote.
>> There are a few more items to be updated on the project status page and
>> others during the next couple of days.
>>
>>
>> Many thanks to the mentors and the IPMC for the support,
>> Luke Han (on behalf of the Apache Kylin PPMC)
>>
>> [1] http://s.apache.org/KylinDisGraduate
>> [2] http://s.apache.org/KylinGraduateVote
>> [3] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-86
>> [4] http://incubator.apache.org/projects/kylin.html
>>
>>
>>
>> Apache Kylin top-level project resolution:
>> ===
>>
>>WHEREAS, the Board of Directors deems it to be in the best
>>interests of the Foundation and consistent with the
>>Foundation's purpose to establish a Project Management
>>Committee charged with the creation and maintenance of
>>open-source software, for distribution at no charge to the
>>public, relative to distributed and scalable OLAP engine
>>
>>NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>>Committee (PMC), to be known as the "Apache Kylin Project",
>>be and hereby is established pursuant to Bylaws of the
>>Foundation; and be it further
>>
>>RESOLVED, that the Apache Kylin Project be and hereby is
>>responsible for the creation and maintenance of open-source
>>software related to distributed and scalable OLAP engine;
>>and be it further
>>
>>RESOLVED, that the office of "Vice President, Kylin" be and
>>hereby is created, the person holding such office to serve at
>>the direction of the Board of Directors as the chair of the
>>Apache Kylin Project, and to have primary responsibility for
>>management of the projects within the scope of responsibility
>>of the Apache Kylin Project; and be it further
>>
>>RESOLVED, that the persons listed immediately below be and
>>hereby are appointed to serve as the initial members of the
>>Apache Kylin Project:
>>
>> * Dayue Gao 
>> * Jason Zhong 
>> * Julian Hyde 
>> * Luke Han 
>> * Henry Saputra 
>> * Hongbin Ma 
>> * Hua Huang 
>> * Owen O'Malley 
>> * P. Taylor Goetz 
>> * Qianhao Zhou 
>> * Shaofeng Shi 
>> * Song Yi 
>> * Ted Dunning 
>> * Xu Jiang 
>> * Yang Li 
>> * Yerui Sun < sunyerui at apache dot org>
>>
>>
>>NOW, THEREFORE, BE IT FURTHER RESOLVED, that Luke Han
>>be appointed to the office of Vice President, Kylin, to serve
>>in accordance with and subject to the direction of the Board of
>>Directors and the Bylaws of the Foundation until death,
>>resignation, retirement, removal or disqualification, or until
>>a successor is appointed; and be it further
>>
>>RESOLVED, that the initial Apache Kylin Project be and hereby
>>is tasked with the creation of a set of bylaws intended to
>>encourage open development and increased participation in the
>>Kylin Project; and be it further
>>
>>RESOLVED, that the initial Apache Kylin Project be and hereby
>>is tasked with the migration and rationalization of the Apache
>>Incubator Kylin podling; and be it further
>>
>>RESOLVED, that all responsibility pertaining to the Apache
>>Incubator Kylin podling encumbered upon the Apache Incubator
>>PMC 

Re: [VOTE] Accept Concerted into the Apache Incubator

[Amol Kekre]

+1 (non-binding)

Amol


On Fri, Oct 9, 2015 at 8:55 AM, Atri Sharma  wrote:

> Hi all,
>
> Following the discussion about Concerted I would like to call a vote for
> accepting Concerted as a new incubator project.
>
> The proposal text is included below, and available on the wiki:
>
> https://wiki.apache.org/incubator/ConcertedProposal
>
> The vote is open for 72 hours:
>
> [ ] +1 accept Concerted in the Incubator
> [ ] ±0
> [ ] -1 (please give reason)
>
> Regards,
>
> Atri
>
> = Abstract =
>
> Concerted is an in memory write less read more engine aimed to provide
> extreme read performance with very high degree of concurrency and
> scalability and focus on minimizing own resource footprint.
>
> = Proposal =
> Concerted is built on the principal that a new type of workload is
> dominating the scene and is now needed to be supported. These are the large
> data set analytical workloads being analyzed or used on large clusters or
> high power machines. Large analytical workloads depend on the ability to
> query large data sets efficiently and in high concurrency while maintaining
> semantics such as immediate consistency. An in memory engine designed to
> support extreme read queries while providing support for aggregation
> through various features (such as multidimensional representation of
> tuples) will accelerate many usecases around large scale analytics.
>
> Concerted believes that best understanding of user application lies with
> user application developer. The need for massive read scaling should be on
> demand and should be flexible to the level that user can decide as to which
> representation and access of data suits his/her current requirements.
> Hence, Concerted is not built in a traditional client/server model.
> Concerted provides users with an API which can be used to load, read,
> update and delete data. User chooses which data structure has to be used
> for his current requirements. All API access is covered by Concerted's
> internal systems like lock manager, transaction manager and cache manager
> which ensure that reads scale to high level in every API call.
>
> Concerted is a Do It Yourself in memory platform for making in memory
> supporting engines. The use case we think of is supporting big data
> warehouses like Hive, but there are endless use cases for a custom, highly
> scalable in memory platform.
>
> The goal of this proposal is to leverage an existing code base available on
> Github and licensed under the Apache License 2.0 to build a community
> around the project. Currently the community consists of existing hackers of
> Concerted as well as people who have been following and associated with the
> project since a while as well as database experts who are excited about
> building a project like this. We are hoping that entering into Apache would
> help us attract more contributors as well as connect with existing big data
> projects like Apache Hive, Apache HAWQ, Apache Storm, Apache Tajo, Apache
> Spark, Apache Geode to leverage their community base while assisting in
> their use cases with Concerted. We had a discussion with founders of Apache
> Tajo and they showed interest in using Concerted for some of their use
> cases.
> = Background =
> Relational databases were built with the cost of physical memory in mind.
> The cost is no longer very relevant and physical memory is now available on
> demand. Another driving factor behind Concerted is that there is a paradigm
> shift with big data coming into picture. Disk IO speeds are more of a
> bottleneck than ever before. Combining the read dominance of analytical
> workload with the speed of in memory structures, Concerted fits the current
> scene. Also, supporting OLAP workloads with in memory support for faster
> read constant queries and joins will be useful.
>
> = Rationale =
> As explained above, large analytical workloads need an in memory
> lightweight engine which supports massive read concurrency, ground level
> support for aggregations and analytics, extreme scalability and high read
> performance, along with the engine being very light itself. Concerted aims
> to solve these needs. Concerted is designed and built with three goals as
> objectives:
>
>
> Performance
> To provide high performance access to data from a large number of rows,
> Concerted uses efficient representation and in memory indexing of data
> coupled with high performance transactions, custom transactions and
> lightweight locking and lockless techniques and an intelligent locking
> manager.
>
> Scalability
> Concerted is built with extreme concurrency and scalability in mind.
>
> Efficiency
> Concerted aims to give expected performance under vast variety of
> workloads and aims to have as low footprint as possible.
>
> = Initial Goals =
> The initial goal is to leverage an existing code base and invest in
> building a community around the project. We anticipate a lot of initial
> restructuring of the existing code 

Re: [VOTE] Accept Concerted into the Apache Incubator

[Pavel Stehule]

+1 (non-binding)

Pavel

2015-10-09 17:55 GMT+02:00 Atri Sharma :

> Hi all,
>
> Following the discussion about Concerted I would like to call a vote for
> accepting Concerted as a new incubator project.
>
> The proposal text is included below, and available on the wiki:
>
> https://wiki.apache.org/incubator/ConcertedProposal
>
> The vote is open for 72 hours:
>
> [ ] +1 accept Concerted in the Incubator
> [ ] ±0
> [ ] -1 (please give reason)
>
> Regards,
>
> Atri
>
> = Abstract =
>
> Concerted is an in memory write less read more engine aimed to provide
> extreme read performance with very high degree of concurrency and
> scalability and focus on minimizing own resource footprint.
>
> = Proposal =
> Concerted is built on the principal that a new type of workload is
> dominating the scene and is now needed to be supported. These are the large
> data set analytical workloads being analyzed or used on large clusters or
> high power machines. Large analytical workloads depend on the ability to
> query large data sets efficiently and in high concurrency while maintaining
> semantics such as immediate consistency. An in memory engine designed to
> support extreme read queries while providing support for aggregation
> through various features (such as multidimensional representation of
> tuples) will accelerate many usecases around large scale analytics.
>
> Concerted believes that best understanding of user application lies with
> user application developer. The need for massive read scaling should be on
> demand and should be flexible to the level that user can decide as to which
> representation and access of data suits his/her current requirements.
> Hence, Concerted is not built in a traditional client/server model.
> Concerted provides users with an API which can be used to load, read,
> update and delete data. User chooses which data structure has to be used
> for his current requirements. All API access is covered by Concerted's
> internal systems like lock manager, transaction manager and cache manager
> which ensure that reads scale to high level in every API call.
>
> Concerted is a Do It Yourself in memory platform for making in memory
> supporting engines. The use case we think of is supporting big data
> warehouses like Hive, but there are endless use cases for a custom, highly
> scalable in memory platform.
>
> The goal of this proposal is to leverage an existing code base available on
> Github and licensed under the Apache License 2.0 to build a community
> around the project. Currently the community consists of existing hackers of
> Concerted as well as people who have been following and associated with the
> project since a while as well as database experts who are excited about
> building a project like this. We are hoping that entering into Apache would
> help us attract more contributors as well as connect with existing big data
> projects like Apache Hive, Apache HAWQ, Apache Storm, Apache Tajo, Apache
> Spark, Apache Geode to leverage their community base while assisting in
> their use cases with Concerted. We had a discussion with founders of Apache
> Tajo and they showed interest in using Concerted for some of their use
> cases.
> = Background =
> Relational databases were built with the cost of physical memory in mind.
> The cost is no longer very relevant and physical memory is now available on
> demand. Another driving factor behind Concerted is that there is a paradigm
> shift with big data coming into picture. Disk IO speeds are more of a
> bottleneck than ever before. Combining the read dominance of analytical
> workload with the speed of in memory structures, Concerted fits the current
> scene. Also, supporting OLAP workloads with in memory support for faster
> read constant queries and joins will be useful.
>
> = Rationale =
> As explained above, large analytical workloads need an in memory
> lightweight engine which supports massive read concurrency, ground level
> support for aggregations and analytics, extreme scalability and high read
> performance, along with the engine being very light itself. Concerted aims
> to solve these needs. Concerted is designed and built with three goals as
> objectives:
>
>
> Performance
> To provide high performance access to data from a large number of rows,
> Concerted uses efficient representation and in memory indexing of data
> coupled with high performance transactions, custom transactions and
> lightweight locking and lockless techniques and an intelligent locking
> manager.
>
> Scalability
> Concerted is built with extreme concurrency and scalability in mind.
>
> Efficiency
> Concerted aims to give expected performance under vast variety of
> workloads and aims to have as low footprint as possible.
>
> = Initial Goals =
> The initial goal is to leverage an existing code base and invest in
> building a community around the project. We anticipate a lot of initial
> restructuring of the existing code so that it 

Re: [DISCUSS] Graduate Kylin from the Apache Incubator

[Samant, Medha]

+1

On 10/9/15, 10:13 AM, "Adunuthula, Seshu"  wrote:

>+1 
>
>On 10/7/15, 8:32 AM, "John D. Ament"  wrote:
>
>>I would be happy to see kylin graduate.
>>On Oct 7, 2015 11:28, "Luke Han"  wrote:
>>
>>> The Kylin community and project made significant advances during the
>>> incubating (from Nov 2014) and
>>> believes it is ready to graduate as a top-level project.
>>>
>>> The Apache Kylin is very active. The PPMC doubled in size (added 6
>>> committers and 2 mentors) and
>>>  increased diversity in the past year. Released 3 version in the past 6
>>> months. There were presentations about Kylin
>>> at most of the big conferences of the world (including Strata+Hadoop
>>>World
>>> London, Hadoop Summit San Jose,
>>> ApacheCon EU, Big Data Technology China, Database Technology Conference
>>> China) and some meetups (Bay Area,
>>> Beijing and one is coming in this weekend in Shanghai), and many talks
>>> around the world.
>>> The dev mailing list is growing very month, about 500+ topics per month
>>> now.
>>> The community created 1000+ JIRA tickets, many patches from
>>> contributors/committers have been merged into code base.
>>>
>>> A vote passed unanimously on the dev@ list (27 +1 votes). Please find
>>> below
>>> references to the graduation preparation artifacts:
>>> * discussion on dev list [1]
>>> * vote thread [2]
>>> * podling name search (still in progress) [3]
>>> * incubation status [4]
>>> * proposed resolution below
>>>
>>> We believe Apache Kylin is ready to become a top-level project and if
>>>the
>>> IPMC agree we will move to a formal vote.
>>> There are a few more items to be updated on the project status page and
>>> others during the next couple of days.
>>>
>>>
>>> Many thanks to the mentors and the IPMC for the support,
>>> Luke Han (on behalf of the Apache Kylin PPMC)
>>>
>>> [1] http://s.apache.org/KylinDisGraduate
>>> [2] http://s.apache.org/KylinGraduateVote
>>> [3] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-86
>>> [4] http://incubator.apache.org/projects/kylin.html
>>>
>>>
>>>
>>> Apache Kylin top-level project resolution:
>>> ===
>>>
>>>WHEREAS, the Board of Directors deems it to be in the best
>>>interests of the Foundation and consistent with the
>>>Foundation's purpose to establish a Project Management
>>>Committee charged with the creation and maintenance of
>>>open-source software, for distribution at no charge to the
>>>public, relative to distributed and scalable OLAP engine
>>>
>>>NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>>>Committee (PMC), to be known as the "Apache Kylin Project",
>>>be and hereby is established pursuant to Bylaws of the
>>>Foundation; and be it further
>>>
>>>RESOLVED, that the Apache Kylin Project be and hereby is
>>>responsible for the creation and maintenance of open-source
>>>software related to distributed and scalable OLAP engine;
>>>and be it further
>>>
>>>RESOLVED, that the office of "Vice President, Kylin" be and
>>>hereby is created, the person holding such office to serve at
>>>the direction of the Board of Directors as the chair of the
>>>Apache Kylin Project, and to have primary responsibility for
>>>management of the projects within the scope of responsibility
>>>of the Apache Kylin Project; and be it further
>>>
>>>RESOLVED, that the persons listed immediately below be and
>>>hereby are appointed to serve as the initial members of the
>>>Apache Kylin Project:
>>>
>>> * Dayue Gao 
>>> * Jason Zhong 
>>> * Julian Hyde 
>>> * Luke Han 
>>> * Henry Saputra 
>>> * Hongbin Ma 
>>> * Hua Huang 
>>> * Owen O'Malley 
>>> * P. Taylor Goetz 
>>> * Qianhao Zhou 
>>> * Shaofeng Shi 
>>> * Song Yi 
>>> * Ted Dunning 
>>> * Xu Jiang 
>>> * Yang Li 
>>> * Yerui Sun < sunyerui at apache dot org>
>>>
>>>
>>>NOW, THEREFORE, BE IT FURTHER RESOLVED, that Luke Han
>>>be appointed to the office of Vice President, Kylin, to serve
>>>in accordance with and subject to the direction of the Board of
>>>Directors and the Bylaws of the Foundation until death,
>>>resignation, retirement, removal or disqualification, or until
>>>a successor is appointed; and be it further
>>>
>>>RESOLVED, that the initial Apache Kylin Project be and hereby
>>>is tasked with the creation of a set of bylaws intended to
>>>encourage open development and increased participation in the
>>>Kylin Project; and be it further
>>>
>>>RESOLVED, that the initial Apache Kylin Project be and hereby
>>>is tasked with the migration and rationalization of the Apache
>>>

Re: [DISCUSS] Mentor neutrality policy

[Bertrand Delacretaz]

Hi,

On Fri, Oct 9, 2015 at 5:07 PM, Daniel Gruno  wrote:
> ...Furthermore, I would like to see this extended to votes on graduating or
> retiring podlings,..

IMO this is where independence is important. We could require that 3
"organizationally independent" IPMC members review each podling before
graduating or retiring. Those people do not need to be project
mentors.

Having a written report from this graduating evaluation would be good,
for example something based on our maturity model [1]. Also useful for
the board to decide whether to accept graduation or ask for more
details.

Apart from that, if an organization donates code via incubation it can
IMO actually be beneficial to have one or two mentors who are familiar
with the project and its initial community.

So maybe define some independence criteria for mentors, but IMO mostly
require that independence for whoever reviews and recommends the
podling for graduation or retirement. Currently we mostly equate
mentors with this "graduation review team" but that might not be the
best way to do it.

-Bertrand

[1] http://community.apache.org/apache-way/apache-project-maturity-model.html

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Chris Douglas]

What problem does this solve?

This proposal lacks context. It implies that mentors are not neutral,
and that they are motivated by interests not shared by the ASF. But it
does not outline the merits of that belief, neither does it specify
how this proposal would address them. Instead of allowing those
definitions to float, this discussion would be more productive if it
were about some concrete problems for which there is evidence. Yet
another thread of rude responses to uncivil accusations is
unproductive, even if it is an IPMC tradition. -C

On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno  wrote:
> Hi Incubator folks,
>
> I would like to propose we adopt a mentor neutrality policy for
> incubating podlings:
>
> - A mentor must not be financially tied to the project or its incubation
> status.
> - A mentor must not have a vested interest in incubating, graduating or
> dismantling a podling that goes beyond the general Apache mission
> - A mentor must not be affiliated with the entity granting the code
> (company or original project community)
>
> Furthermore, I would like to see this extended to votes on graduating or
> retiring podlings, so that only people with no organizational (aparty
> from the ASF) or financial ties to the project (or the companies behind
> it) can cast a binding vote on graduation or retirement.
>
> This would essentially mean:
>
> - If you work for a company (or are hired as consultant/advisor) that is
> entering a project into incubation, you cannot mentor it nor vote
> for/against its incubation, graduation or retirement.
> - If you are a in the original community behind the project, you cannot
> mentor it nor vote for/against it.
>
> I believe this would create a neutral mentorship whose sole mission is
> to guide podlings with the interests of the ASF in mind.
>
>
> Please do discuss this. If there is (mostly) positive feedback, I would
> like to, at some point, have a vote on including this in the Incubator
> policy. I realize this would cut down on the number of potential
> mentors, and I would ask that more people step up to the challenge of
> mentoring if adopted.
>
> With regards,
> Daniel
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Advice on LICENSE/NOTICE for Shaded Dependencies

[Stephen Mallette]

Hello all,

I feel like I'm on the verge of getting LICENSE/NOTICE right in all
respects in The TinkerPop.  . Seems like there's one piece that's out of
place and could use some advice as I wasn't able to map anything I'd read
in the Apache docs on this topic to my issue.  We currently shade several
libraries: Kryo, minlog, objenesis, and jackson, essentially re-packaging
those binary dependencies in a jar called gremlin-shaded.jar. The
gremlin-shaded.jar is then made part of our zip distributions.

As we didn't re-package the source code of these libs, I figured that the
source LICENSE/NOTICE didn't need to change and that it was just the binary
LICENSE/NOTICE that needed to change.  I assume this situation is somewhat
similar to a project that builds an uber jar for distribution.

So that's where i'm about stuck. I took a wild stab at it and did this:

https://github.com/apache/incubator-tinkerpop/blob/5a8b61c09868e22a415c0469a2737d68acce9a4e/gremlin-console/src/main/LICENSE#L226-L228

but I have no idea if that is sufficient (or just plain wrong).  If anyone
could offer some pointers on what needs to happen here to our binary
LICENSE/NOTICE, that would be nice.  I'd really like to see us get a clean
bill of health on the next LICENSE/NOTICE that goes through a release vote.

Thanks for your help,

Stephen

Re: [DISCUSS] Mentor neutrality policy

[Sam Ruby]

On Fri, Oct 9, 2015 at 1:25 PM, Bertrand Delacretaz
 wrote:
> Hi,
>
> On Fri, Oct 9, 2015 at 5:07 PM, Daniel Gruno  wrote:
>> ...Furthermore, I would like to see this extended to votes on graduating or
>> retiring podlings,..
>
> IMO this is where independence is important. We could require that 3
> "organizationally independent" IPMC members review each podling before
> graduating or retiring. Those people do not need to be project
> mentors.

I much prefer a formulation of "3 independent" over "no financial
ties", and would prefer such a criteria be considered whenever the
impulse arises to ensure that NO involved individual has a vested
interest.

I'll go further and say that financial interests are but one way in
which individuals have a vested interest in the success of a project,
and echoing a statement by Ross -- having a vested interest is not a
bad thing.

Finally, I would prefer a model whereby those that have achieved ASF
member status are given the benefit of the doubt in matters involving
a group vote when it comes to their ability to separate their ASF role
from their relationship with their employee.  Nothing wrong with still
requiring 3 completely independent votes, but having a rule that
excludes participation by those that have demonstrated their merit as
ASF members just seems wrong.

- Sam Ruby

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Daniel Gruno]

Does there always have to be an actual problem before we can propose a
policy? must we always be reactive instead of proactive?

Yes, I am in a way implying that some mentors are, perhaps, not neutral
in their work. I will not back it up with specific names or contexts, as
I don't want to take a trip to lawsuit town for things I cannot back up
with publicly available information.

I don't find this to be uncivil accusations - can you outline a specific
segment that you find uncivil? I am proposing a set of basic rules -
which is naturally up for discussion and improvement - that would
potentially alleviate us from having some nasty discussions - whether
they be public or private - about the neutrality and honesty of
recommendations, and hopefully ensure we have a more leveled playing
field in the incubator.

I'll stop here, as my eyesight is playing a trick on me today and not
allowing me to see what I type.

With regards,
Daniel.

On 10/09/2015 08:03 PM, Chris Douglas wrote:
> What problem does this solve?
> 
> This proposal lacks context. It implies that mentors are not neutral,
> and that they are motivated by interests not shared by the ASF. But it
> does not outline the merits of that belief, neither does it specify
> how this proposal would address them. Instead of allowing those
> definitions to float, this discussion would be more productive if it
> were about some concrete problems for which there is evidence. Yet
> another thread of rude responses to uncivil accusations is
> unproductive, even if it is an IPMC tradition. -C
> 
> On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno  wrote:
>> Hi Incubator folks,
>>
>> I would like to propose we adopt a mentor neutrality policy for
>> incubating podlings:
>>
>> - A mentor must not be financially tied to the project or its incubation
>> status.
>> - A mentor must not have a vested interest in incubating, graduating or
>> dismantling a podling that goes beyond the general Apache mission
>> - A mentor must not be affiliated with the entity granting the code
>> (company or original project community)
>>
>> Furthermore, I would like to see this extended to votes on graduating or
>> retiring podlings, so that only people with no organizational (aparty
>> from the ASF) or financial ties to the project (or the companies behind
>> it) can cast a binding vote on graduation or retirement.
>>
>> This would essentially mean:
>>
>> - If you work for a company (or are hired as consultant/advisor) that is
>> entering a project into incubation, you cannot mentor it nor vote
>> for/against its incubation, graduation or retirement.
>> - If you are a in the original community behind the project, you cannot
>> mentor it nor vote for/against it.
>>
>> I believe this would create a neutral mentorship whose sole mission is
>> to guide podlings with the interests of the ASF in mind.
>>
>>
>> Please do discuss this. If there is (mostly) positive feedback, I would
>> like to, at some point, have a vote on including this in the Incubator
>> policy. I realize this would cut down on the number of potential
>> mentors, and I would ask that more people step up to the challenge of
>> mentoring if adopted.
>>
>> With regards,
>> Daniel
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Concerted into the Apache Incubator

[Henry Saputra]

+1 (binding)
Good luck guys!

On Fri, Oct 9, 2015 at 8:55 AM, Atri Sharma  wrote:
> Hi all,
>
> Following the discussion about Concerted I would like to call a vote for
> accepting Concerted as a new incubator project.
>
> The proposal text is included below, and available on the wiki:
>
> https://wiki.apache.org/incubator/ConcertedProposal
>
> The vote is open for 72 hours:
>
> [ ] +1 accept Concerted in the Incubator
> [ ] ±0
> [ ] -1 (please give reason)
>
> Regards,
>
> Atri
>
> = Abstract =
>
> Concerted is an in memory write less read more engine aimed to provide
> extreme read performance with very high degree of concurrency and
> scalability and focus on minimizing own resource footprint.
>
> = Proposal =
> Concerted is built on the principal that a new type of workload is
> dominating the scene and is now needed to be supported. These are the large
> data set analytical workloads being analyzed or used on large clusters or
> high power machines. Large analytical workloads depend on the ability to
> query large data sets efficiently and in high concurrency while maintaining
> semantics such as immediate consistency. An in memory engine designed to
> support extreme read queries while providing support for aggregation
> through various features (such as multidimensional representation of
> tuples) will accelerate many usecases around large scale analytics.
>
> Concerted believes that best understanding of user application lies with
> user application developer. The need for massive read scaling should be on
> demand and should be flexible to the level that user can decide as to which
> representation and access of data suits his/her current requirements.
> Hence, Concerted is not built in a traditional client/server model.
> Concerted provides users with an API which can be used to load, read,
> update and delete data. User chooses which data structure has to be used
> for his current requirements. All API access is covered by Concerted's
> internal systems like lock manager, transaction manager and cache manager
> which ensure that reads scale to high level in every API call.
>
> Concerted is a Do It Yourself in memory platform for making in memory
> supporting engines. The use case we think of is supporting big data
> warehouses like Hive, but there are endless use cases for a custom, highly
> scalable in memory platform.
>
> The goal of this proposal is to leverage an existing code base available on
> Github and licensed under the Apache License 2.0 to build a community
> around the project. Currently the community consists of existing hackers of
> Concerted as well as people who have been following and associated with the
> project since a while as well as database experts who are excited about
> building a project like this. We are hoping that entering into Apache would
> help us attract more contributors as well as connect with existing big data
> projects like Apache Hive, Apache HAWQ, Apache Storm, Apache Tajo, Apache
> Spark, Apache Geode to leverage their community base while assisting in
> their use cases with Concerted. We had a discussion with founders of Apache
> Tajo and they showed interest in using Concerted for some of their use
> cases.
> = Background =
> Relational databases were built with the cost of physical memory in mind.
> The cost is no longer very relevant and physical memory is now available on
> demand. Another driving factor behind Concerted is that there is a paradigm
> shift with big data coming into picture. Disk IO speeds are more of a
> bottleneck than ever before. Combining the read dominance of analytical
> workload with the speed of in memory structures, Concerted fits the current
> scene. Also, supporting OLAP workloads with in memory support for faster
> read constant queries and joins will be useful.
>
> = Rationale =
> As explained above, large analytical workloads need an in memory
> lightweight engine which supports massive read concurrency, ground level
> support for aggregations and analytics, extreme scalability and high read
> performance, along with the engine being very light itself. Concerted aims
> to solve these needs. Concerted is designed and built with three goals as
> objectives:
>
>
> Performance
> To provide high performance access to data from a large number of rows,
> Concerted uses efficient representation and in memory indexing of data
> coupled with high performance transactions, custom transactions and
> lightweight locking and lockless techniques and an intelligent locking
> manager.
>
> Scalability
> Concerted is built with extreme concurrency and scalability in mind.
>
> Efficiency
> Concerted aims to give expected performance under vast variety of
> workloads and aims to have as low footprint as possible.
>
> = Initial Goals =
> The initial goal is to leverage an existing code base and invest in
> building a community around the project. We anticipate a lot of initial
> restructuring of the existing 

Re: [VOTE] Accept Concerted into the Apache Incubator

[Ayrton Gomesz]

+1
@henry.saputra thanks man
On Oct 9, 2015 5:50 PM, "Henry Saputra"  wrote:

> +1 (binding)
> Good luck guys!
>
> On Fri, Oct 9, 2015 at 8:55 AM, Atri Sharma  wrote:
> > Hi all,
> >
> > Following the discussion about Concerted I would like to call a vote for
> > accepting Concerted as a new incubator project.
> >
> > The proposal text is included below, and available on the wiki:
> >
> > https://wiki.apache.org/incubator/ConcertedProposal
> >
> > The vote is open for 72 hours:
> >
> > [ ] +1 accept Concerted in the Incubator
> > [ ] ±0
> > [ ] -1 (please give reason)
> >
> > Regards,
> >
> > Atri
> >
> > = Abstract =
> >
> > Concerted is an in memory write less read more engine aimed to provide
> > extreme read performance with very high degree of concurrency and
> > scalability and focus on minimizing own resource footprint.
> >
> > = Proposal =
> > Concerted is built on the principal that a new type of workload is
> > dominating the scene and is now needed to be supported. These are the
> large
> > data set analytical workloads being analyzed or used on large clusters or
> > high power machines. Large analytical workloads depend on the ability to
> > query large data sets efficiently and in high concurrency while
> maintaining
> > semantics such as immediate consistency. An in memory engine designed to
> > support extreme read queries while providing support for aggregation
> > through various features (such as multidimensional representation of
> > tuples) will accelerate many usecases around large scale analytics.
> >
> > Concerted believes that best understanding of user application lies with
> > user application developer. The need for massive read scaling should be
> on
> > demand and should be flexible to the level that user can decide as to
> which
> > representation and access of data suits his/her current requirements.
> > Hence, Concerted is not built in a traditional client/server model.
> > Concerted provides users with an API which can be used to load, read,
> > update and delete data. User chooses which data structure has to be used
> > for his current requirements. All API access is covered by Concerted's
> > internal systems like lock manager, transaction manager and cache manager
> > which ensure that reads scale to high level in every API call.
> >
> > Concerted is a Do It Yourself in memory platform for making in memory
> > supporting engines. The use case we think of is supporting big data
> > warehouses like Hive, but there are endless use cases for a custom,
> highly
> > scalable in memory platform.
> >
> > The goal of this proposal is to leverage an existing code base available
> on
> > Github and licensed under the Apache License 2.0 to build a community
> > around the project. Currently the community consists of existing hackers
> of
> > Concerted as well as people who have been following and associated with
> the
> > project since a while as well as database experts who are excited about
> > building a project like this. We are hoping that entering into Apache
> would
> > help us attract more contributors as well as connect with existing big
> data
> > projects like Apache Hive, Apache HAWQ, Apache Storm, Apache Tajo, Apache
> > Spark, Apache Geode to leverage their community base while assisting in
> > their use cases with Concerted. We had a discussion with founders of
> Apache
> > Tajo and they showed interest in using Concerted for some of their use
> > cases.
> > = Background =
> > Relational databases were built with the cost of physical memory in mind.
> > The cost is no longer very relevant and physical memory is now available
> on
> > demand. Another driving factor behind Concerted is that there is a
> paradigm
> > shift with big data coming into picture. Disk IO speeds are more of a
> > bottleneck than ever before. Combining the read dominance of analytical
> > workload with the speed of in memory structures, Concerted fits the
> current
> > scene. Also, supporting OLAP workloads with in memory support for faster
> > read constant queries and joins will be useful.
> >
> > = Rationale =
> > As explained above, large analytical workloads need an in memory
> > lightweight engine which supports massive read concurrency, ground level
> > support for aggregations and analytics, extreme scalability and high read
> > performance, along with the engine being very light itself. Concerted
> aims
> > to solve these needs. Concerted is designed and built with three goals as
> > objectives:
> >
> >
> > Performance
> > To provide high performance access to data from a large number of
> rows,
> > Concerted uses efficient representation and in memory indexing of data
> > coupled with high performance transactions, custom transactions and
> > lightweight locking and lockless techniques and an intelligent locking
> > manager.
> >
> > Scalability
> > Concerted is built with extreme concurrency and scalability in mind.
> >
> > Efficiency

Re: [DISCUSS] Mentor neutrality policy

[Daniel Gruno]

On 10/09/2015 08:02 PM, Sam Ruby wrote:
> On Fri, Oct 9, 2015 at 1:25 PM, Bertrand Delacretaz
>  wrote:
>> Hi,
>>
>> On Fri, Oct 9, 2015 at 5:07 PM, Daniel Gruno  wrote:
>>> ...Furthermore, I would like to see this extended to votes on graduating or
>>> retiring podlings,..
>>
>> IMO this is where independence is important. We could require that 3
>> "organizationally independent" IPMC members review each podling before
>> graduating or retiring. Those people do not need to be project
>> mentors.
> 
> I much prefer a formulation of "3 independent" over "no financial
> ties", and would prefer such a criteria be considered whenever the
> impulse arises to ensure that NO involved individual has a vested
> interest.
> 
> I'll go further and say that financial interests are but one way in
> which individuals have a vested interest in the success of a project,
> and echoing a statement by Ross -- having a vested interest is not a
> bad thing.

Perhaps my initial suggestion needs some modification to the wording.
People with a vested interest (for a certain definition of the term) is
in itself not a bad thing when it comes to mentoring, but it can become
tricky when it comes to giving recommendations to the IPMC about how to
proceed from a neutral standpoint. That is what I aimed to have us work on.

I would imagine no one would object to a policy that says you cannot
have a binding vote if you have a financial interest in graduating a
podling, but my real point is we should leave the decision making to
those who are truly neutral, much as we let a judge and/or a neutral
jury decide if we're guilty or not in a legal case.

Perhaps we could change it to:

- Binding votes on incubation, graduation and/or retirement are only
valid when given by members of the IPMC who are independent from the
podling in question. Mentors are free to recommend such actions, but
cannot cast a vote themselves.

WDYT?

With regards,
Daniel.


> 
> Finally, I would prefer a model whereby those that have achieved ASF
> member status are given the benefit of the doubt in matters involving
> a group vote when it comes to their ability to separate their ASF role
> from their relationship with their employee.  Nothing wrong with still
> requiring 3 completely independent votes, but having a rule that
> excludes participation by those that have demonstrated their merit as
> ASF members just seems wrong.
> 
> - Sam Ruby
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Graduate Kylin from the Apache Incubator

[Julian Hyde]

I am a mentor of Kylin and I believe the project is ready to graduate.
They have created a vibrant, open community and are conducting
business in the Apache Way.

One proviso: Let's complete the name search before starting the IPMC
vote. It would be foolish to let that particular cart get in front of
the horse. I don't think that prevents us from discussing graduation.

Julian


On Fri, Oct 9, 2015 at 10:44 AM, Samant, Medha  wrote:
> +1
>
> On 10/9/15, 10:13 AM, "Adunuthula, Seshu"  wrote:
>
>>+1
>>
>>On 10/7/15, 8:32 AM, "John D. Ament"  wrote:
>>
>>>I would be happy to see kylin graduate.
>>>On Oct 7, 2015 11:28, "Luke Han"  wrote:
>>>
 The Kylin community and project made significant advances during the
 incubating (from Nov 2014) and
 believes it is ready to graduate as a top-level project.

 The Apache Kylin is very active. The PPMC doubled in size (added 6
 committers and 2 mentors) and
  increased diversity in the past year. Released 3 version in the past 6
 months. There were presentations about Kylin
 at most of the big conferences of the world (including Strata+Hadoop
World
 London, Hadoop Summit San Jose,
 ApacheCon EU, Big Data Technology China, Database Technology Conference
 China) and some meetups (Bay Area,
 Beijing and one is coming in this weekend in Shanghai), and many talks
 around the world.
 The dev mailing list is growing very month, about 500+ topics per month
 now.
 The community created 1000+ JIRA tickets, many patches from
 contributors/committers have been merged into code base.

 A vote passed unanimously on the dev@ list (27 +1 votes). Please find
 below
 references to the graduation preparation artifacts:
 * discussion on dev list [1]
 * vote thread [2]
 * podling name search (still in progress) [3]
 * incubation status [4]
 * proposed resolution below

 We believe Apache Kylin is ready to become a top-level project and if
the
 IPMC agree we will move to a formal vote.
 There are a few more items to be updated on the project status page and
 others during the next couple of days.


 Many thanks to the mentors and the IPMC for the support,
 Luke Han (on behalf of the Apache Kylin PPMC)

 [1] http://s.apache.org/KylinDisGraduate
 [2] http://s.apache.org/KylinGraduateVote
 [3] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-86
 [4] http://incubator.apache.org/projects/kylin.html



 Apache Kylin top-level project resolution:
 ===

WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project Management
Committee charged with the creation and maintenance of
open-source software, for distribution at no charge to the
public, relative to distributed and scalable OLAP engine

NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the "Apache Kylin Project",
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further

RESOLVED, that the Apache Kylin Project be and hereby is
responsible for the creation and maintenance of open-source
software related to distributed and scalable OLAP engine;
and be it further

RESOLVED, that the office of "Vice President, Kylin" be and
hereby is created, the person holding such office to serve at
the direction of the Board of Directors as the chair of the
Apache Kylin Project, and to have primary responsibility for
management of the projects within the scope of responsibility
of the Apache Kylin Project; and be it further

RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache Kylin Project:

 * Dayue Gao 
 * Jason Zhong 
 * Julian Hyde 
 * Luke Han 
 * Henry Saputra 
 * Hongbin Ma 
 * Hua Huang 
 * Owen O'Malley 
 * P. Taylor Goetz 
 * Qianhao Zhou 
 * Shaofeng Shi 
 * Song Yi 
 * Ted Dunning 
 * Xu Jiang 
 * Yang Li 
 * Yerui Sun < sunyerui at apache dot org>


NOW, THEREFORE, BE IT FURTHER RESOLVED, that Luke Han
be appointed to the office of Vice President, Kylin, to serve
in accordance with and subject to the direction of the Board of
Directors and the Bylaws of the Foundation until 

[DISCUSS] Mentor neutrality policy

[Daniel Gruno]

Hi Incubator folks,

I would like to propose we adopt a mentor neutrality policy for
incubating podlings:

- A mentor must not be financially tied to the project or its incubation
status.
- A mentor must not have a vested interest in incubating, graduating or
dismantling a podling that goes beyond the general Apache mission
- A mentor must not be affiliated with the entity granting the code
(company or original project community)

Furthermore, I would like to see this extended to votes on graduating or
retiring podlings, so that only people with no organizational (aparty
from the ASF) or financial ties to the project (or the companies behind
it) can cast a binding vote on graduation or retirement.

This would essentially mean:

- If you work for a company (or are hired as consultant/advisor) that is
entering a project into incubation, you cannot mentor it nor vote
for/against its incubation, graduation or retirement.
- If you are a in the original community behind the project, you cannot
mentor it nor vote for/against it.

I believe this would create a neutral mentorship whose sole mission is
to guide podlings with the interests of the ASF in mind.


Please do discuss this. If there is (mostly) positive feedback, I would
like to, at some point, have a vote on including this in the Incubator
policy. I realize this would cut down on the number of potential
mentors, and I would ask that more people step up to the challenge of
mentoring if adopted.

With regards,
Daniel

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Julian Hyde]

It seems to me that the negatives of your proposed policy outweigh the 
positives.

Presumably the goal is to prevent mentors from making biased decisions due to 
conflicts of interest. There are other approaches to solving CoI, such as 
declaring conflicts of interest and, Apache’s current approach, to trust 
mentors to “wear multiple hats”.

A more pressing problem, in my opinion, is absentee mentors. Your proposed 
changes would make that problem a good deal worse, by eliminating from the pool 
of possible mentors those people who have the most knowledge about the subject 
area and motivation to help the project succeed.

I suggest that we look at “conflict of interest” as a whole, ascertain whether 
it is a significant problem and if so, consider other solutions to it.

Julian

 
> On Oct 9, 2015, at 8:07 AM, Daniel Gruno  wrote:
> 
> Hi Incubator folks,
> 
> I would like to propose we adopt a mentor neutrality policy for
> incubating podlings:
> 
> - A mentor must not be financially tied to the project or its incubation
> status.
> - A mentor must not have a vested interest in incubating, graduating or
> dismantling a podling that goes beyond the general Apache mission
> - A mentor must not be affiliated with the entity granting the code
> (company or original project community)
> 
> Furthermore, I would like to see this extended to votes on graduating or
> retiring podlings, so that only people with no organizational (aparty
> from the ASF) or financial ties to the project (or the companies behind
> it) can cast a binding vote on graduation or retirement.
> 
> This would essentially mean:
> 
> - If you work for a company (or are hired as consultant/advisor) that is
> entering a project into incubation, you cannot mentor it nor vote
> for/against its incubation, graduation or retirement.
> - If you are a in the original community behind the project, you cannot
> mentor it nor vote for/against it.
> 
> I believe this would create a neutral mentorship whose sole mission is
> to guide podlings with the interests of the ASF in mind.
> 
> 
> Please do discuss this. If there is (mostly) positive feedback, I would
> like to, at some point, have a vote on including this in the Incubator
> policy. I realize this would cut down on the number of potential
> mentors, and I would ask that more people step up to the challenge of
> mentoring if adopted.
> 
> With regards,
> Daniel
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

RE: [DISCUSS] Mentor neutrality policy

[Ross Gardler]

I'm not sure about this.

In the past I've argued that we need mentors who *do* have a personal interest. 
Those are the ones least likely to be absent during incubation.

I do agree that mentors must act in a neutral way. I would hope that if this 
were not the case then someone would speak up. I accept that it would be 
awkward to do so but concerns need not be raised in a "person Foo is not acting 
in a neutral way" in most cases it would always be possible to say "the project 
is not acting in a neutral way".  

Furthermore, how do we evaluate "vested interest". If someone agrees to mentor 
a project that is from a team in a different part of their company do they have 
a vested interest? Speaking personally I have more interest in the success of 
our partners than I do in some unrelated parts of my employers business. Does 
that mean I should not be allowed to mentor projects from my partners too? 
While I can hide behind a "big company blindness" case others have no such 
option. What if they are from a SME who does not have that luxury, how do we 
enforce this proposal fairly?

I'd like to think that if the ASF is the right place for a project in which 
someone has a vested interest then they will want that project to operate as an 
Apache project. By definition that means that the mentor must act impartially 
if they are to achieve their goals.

Personally I would focus more on better oversight of podling and mentor 
activity. The goal is to catch the occasional problem case rather than put 
restrictions in place. I'm not sure how to do that though. I and others have 
made many suggestions over the years. They can be found here 
http://wiki.apache.org/incubator/IncubatorIssues2013 (you might want to add 
your proposal there).

Ross

-Original Message-
From: Daniel Gruno [mailto:humbed...@apache.org] 
Sent: Friday, October 9, 2015 8:07 AM
To: general@incubator.apache.org
Subject: [DISCUSS] Mentor neutrality policy

Hi Incubator folks,

I would like to propose we adopt a mentor neutrality policy for incubating 
podlings:

- A mentor must not be financially tied to the project or its incubation status.
- A mentor must not have a vested interest in incubating, graduating or 
dismantling a podling that goes beyond the general Apache mission
- A mentor must not be affiliated with the entity granting the code (company or 
original project community)

Furthermore, I would like to see this extended to votes on graduating or 
retiring podlings, so that only people with no organizational (aparty from the 
ASF) or financial ties to the project (or the companies behind
it) can cast a binding vote on graduation or retirement.

This would essentially mean:

- If you work for a company (or are hired as consultant/advisor) that is 
entering a project into incubation, you cannot mentor it nor vote for/against 
its incubation, graduation or retirement.
- If you are a in the original community behind the project, you cannot mentor 
it nor vote for/against it.

I believe this would create a neutral mentorship whose sole mission is to guide 
podlings with the interests of the ASF in mind.


Please do discuss this. If there is (mostly) positive feedback, I would like 
to, at some point, have a vote on including this in the Incubator policy. I 
realize this would cut down on the number of potential mentors, and I would ask 
that more people step up to the challenge of mentoring if adopted.

With regards,
Daniel

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Greg Trasuk]

Hi Daniel:

Discussion intertwined below…

Cheers,

Greg Trasuk

> On Oct 9, 2015, at 11:07 AM, Daniel Gruno  wrote:
> 
> Hi Incubator folks,
> 
> I would like to propose we adopt a mentor neutrality policy for
> incubating podlings:
> 
> - A mentor must not be financially tied to the project or its incubation
> status.

This requirement would seem to be against the idea that we participate in 
Apache as individuals, rather than as employees/representatives of some 
company.  If there is a case where a member appears to be representing their 
company’s interest rather than the Foundation’s interest, shouldn’t that be 
dealt with in itself?

> - A mentor must not have a vested interest in incubating, graduating or
> dismantling a podling that goes beyond the general Apache mission

Could you elaborate on “beyond the general Apache mission”?  You probably have 
some concrete examples in mind, and I’m sure we don’t want to start dissecting 
those examples rather than your overall suggestion, but personally, I’m not 
sure what you mean.

> - A mentor must not be affiliated with the entity granting the code
> (company or original project community)
> 

That suggestion would seem to preclude a knowledgable insider who happens to be 
an Apache member from helping out with incubating a project.  Which seems kind 
of inefficient.

> Furthermore, I would like to see this extended to votes on graduating or
> retiring podlings, so that only people with no organizational (aparty
> from the ASF) or financial ties to the project (or the companies behind
> it) can cast a binding vote on graduation or retirement.
> 
> This would essentially mean:
> 
> - If you work for a company (or are hired as consultant/advisor) that is
> entering a project into incubation, you cannot mentor it nor vote
> for/against its incubation, graduation or retirement.
> - If you are a in the original community behind the project, you cannot
> mentor it nor vote for/against it.
> 
> I believe this would create a neutral mentorship whose sole mission is
> to guide podlings with the interests of the ASF in mind.
> 
> 
> Please do discuss this. If there is (mostly) positive feedback, I would
> like to, at some point, have a vote on including this in the Incubator
> policy. I realize this would cut down on the number of potential
> mentors, and I would ask that more people step up to the challenge of
> mentoring if adopted.
> 
> With regards,
> Daniel
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org