Re: [Result][VOTE] Graduate Apache Kylin from the Apache Incubator

[Luke Han]

Hi all,
 Apache Kylin's new release, v1.1.1-incubating, has been rolled out
with KYLIN-999 fixed [1].
 Could you please help to check again and convert your -1 vote for the
graduation if possible.

 Really appreciated for your guide and help.

 Thanks.
Luke


Best Regards!
-

Luke Han

On Wed, Nov 4, 2015 at 10:23 PM, Luke Han  wrote:

> Hi there,
> The new release (v1.1.1) already rolled out in IPMC for vote now [1].
>
> The release vote in IPMC will send out later once vote pass in PPMC,
> but it will perfect if someone could help to double check and test this
> release if possible in advance. Just want to make sure such concern and
> issue already be fixed in this release.
>
>  Thank you very much.
>
> Luke
>
> [1]. *http://s.apache.org/kV2 *
>
>
>
> Best Regards!
> -
>
> Luke Han
>
> On Wed, Nov 4, 2015 at 12:15 PM, Luke Han  wrote:
>
>> The merge will happen after release, but we could apply this patch first
>> if community has concern about this.
>>
>> Thanks.
>>
>> Regards!
>> Luke Han
>>
>>
>>
>>
>> On Tue, Nov 3, 2015 at 7:57 PM -0800, "John D. Ament" <
>> johndam...@apache.org> wrote:
>>
>> That's a good way to fix it. Do you merge your release branches back to
>>> master/next develop?
>>> On Nov 3, 2015 22:04, "Luke Han"  wrote:
>>>
>>> > Anyway, removed such reference in Kylin's code, there's no more Google
>>> > Fonts or Adobe Fonts now.
>>> >
>>> > Please help to check:
>>> >
>>> > https://github.com/apache/incubator-kylin/commit/a2fa3e8e93765bf3db39f5da935aca3a588789f1
>>> >
>>> > Thanks.
>>> >
>>> >
>>> > Best Regards!
>>> > -
>>> >
>>> > Luke Han
>>> >
>>> > On Wed, Nov 4, 2015 at 10:56 AM, Justin Mclean
>>> > wrote:
>>> >
>>> > > Hi,
>>> > >
>>> > > > The referenced font is SIL OFL 1.1
>>> > > > http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi=OFL
>>> > > >
>>> > > > You're not technically bundling the font, but referencing it via URL.
>>> > > It's
>>> > > > a good question for legal.
>>> > >
>>> > > The fonts are actually being bundled as well. [1] It just not obvious
>>> > from
>>> > > their names.
>>> > >
>>> > > Thanks,
>>> > > Justin
>>> > >
>>> > > 1.
>>> > >
>>> > https://github.com/apache/incubator-kylin/tree/1.x-staging/webapp/app/fonts
>>> > > -
>>> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> > > For additional commands, e-mail: general-h...@incubator.apache.org
>>> > >
>>> > >
>>> >
>>>
>>>
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Bertrand Delacretaz]

Hi Steve,

On Tue, Nov 10, 2015 at 9:31 PM, Steve Loughran  wrote:
> ...is JIRA-first development conducive to developing a community?...

I don't think so, as you say this breaks the project into very small
buckets and it's very hard for someone new to get the overview of
what's going on and what the big ideas and visions are.

I'm a big fan of backing all my work with issue tracker tickets, but
*decisions* (except minor ones which only have a very local impact)
should not happen in those tickets. IMO tickets are for execution of
something that's been decided on your project's dev list.

It's a difficult balance, and it requires all developers to be aware
of when the time comes to stop discussing in a ticket and bring that
discussion to the dev list.

>... Maybe we should embrace online conferencing more

I don't think so, as that's not inclusive nor asynchronous.

IMO the combination of dev list + tickets can work well but it
requires lots of discipline for the most active developers, to make
sure they expose their ideas, decisions and discussions to their
project's dev list.

-Bertrand

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

Re: [Result][VOTE] Graduate Apache Kylin from the Apache Incubator

[Luke Han]

1. v1.1.1-incubating release vote result link: http://s.apache.org/Zps



Best Regards!
-

Luke Han

On Wed, Nov 11, 2015 at 5:52 PM, Luke Han  wrote:

> Hi all,
>  Apache Kylin's new release, v1.1.1-incubating, has been rolled out
> with KYLIN-999 fixed [1].
>  Could you please help to check again and convert your -1 vote for the
> graduation if possible.
>
>  Really appreciated for your guide and help.
>
>  Thanks.
> Luke
>
>
> Best Regards!
> -
>
> Luke Han
>
> On Wed, Nov 4, 2015 at 10:23 PM, Luke Han  wrote:
>
>> Hi there,
>> The new release (v1.1.1) already rolled out in IPMC for vote now [1].
>>
>> The release vote in IPMC will send out later once vote pass in PPMC,
>> but it will perfect if someone could help to double check and test this
>> release if possible in advance. Just want to make sure such concern and
>> issue already be fixed in this release.
>>
>>  Thank you very much.
>>
>> Luke
>>
>> [1]. *http://s.apache.org/kV2 *
>>
>>
>>
>> Best Regards!
>> -
>>
>> Luke Han
>>
>> On Wed, Nov 4, 2015 at 12:15 PM, Luke Han  wrote:
>>
>>> The merge will happen after release, but we could apply this patch first
>>> if community has concern about this.
>>>
>>> Thanks.
>>>
>>> Regards!
>>> Luke Han
>>>
>>>
>>>
>>>
>>> On Tue, Nov 3, 2015 at 7:57 PM -0800, "John D. Ament" <
>>> johndam...@apache.org> wrote:
>>>
>>> That's a good way to fix it. Do you merge your release branches back to
 master/next develop?
 On Nov 3, 2015 22:04, "Luke Han"  wrote:

 > Anyway, removed such reference in Kylin's code, there's no more Google
 > Fonts or Adobe Fonts now.
 >
 > Please help to check:
 >
 > https://github.com/apache/incubator-kylin/commit/a2fa3e8e93765bf3db39f5da935aca3a588789f1
 >
 > Thanks.
 >
 >
 > Best Regards!
 > -
 >
 > Luke Han
 >
 > On Wed, Nov 4, 2015 at 10:56 AM, Justin Mclean
 > wrote:
 >
 > > Hi,
 > >
 > > > The referenced font is SIL OFL 1.1
 > > > http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi=OFL
 > > >
 > > > You're not technically bundling the font, but referencing it via URL.
 > > It's
 > > > a good question for legal.
 > >
 > > The fonts are actually being bundled as well. [1] It just not obvious
 > from
 > > their names.
 > >
 > > Thanks,
 > > Justin
 > >
 > > 1.
 > >
 > https://github.com/apache/incubator-kylin/tree/1.x-staging/webapp/app/fonts
 > > -
 > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 > > For additional commands, e-mail: general-h...@incubator.apache.org
 > >
 > >
 >


>>
>

Re: [DISCUSS] OpenMiracl for Incubation

[Patrick Hilt]

Hi!
Definitely interesting points to consider… I have just discussed this with 
Brian (MIracl CEO) and he’ll post some comments back and we can take it from 
there.

Thanks for the input and support,
Patrick

---
Patrick Hilt
Chief Technology Officer
Certivox Ltd.

> On Nov 10, 2015, at 9:53 PM, Alex Harui  wrote:
> 
> 
> 
> On 11/10/15, 9:37 PM, "Nick Kew"  wrote:
> 
>> On Wed, 2015-11-11 at 04:38 +, Alex Harui wrote:
>> 
>>> In case it helps, when Adobe transferred the Flex trademark to the ASF,
>>> the ASF licensed use of the Flex trademark back to Adobe so Adobe could
>>> use Flex for its already-released versions and documentation.
>> 
>> Aha, that's interesting.  The suggestion was floated that our
>> project could be Apache MIRACL (sharing the name), but I
>> thought ASF wouldn't be happy with that.  Overcautious? :)
> 
> @trademarks would make the final ruling.  Out in the wild, the terms
> “Apache Flex” and “Adobe Flex” are used to distinguish between the Apache
> versions and Adobe versions.  The trademark “Flex” is now owned by the
> ASF.  IIRC, one aspect of the license back to Adobe was that Adobe could
> not use it on newer versions, which was fine with Adobe since it was no
> longer going to provide new versions of Flex, it just need a way to
> reference the legacy versions since plenty of customers are still using
> and talking about these legacy versions.
> 
> All Adobe website references to Flex (well, at least the prominent ones we
> could easily find) had to be tweaked to indicate that Flex was now a
> trademark of the ASF.
> 
> So a key question likely is: if there is something other than Apache
> MIRACL also being actively promoted, like a commercial version from a
> for-profit, then that would probably fail the “confusion” test and
> @trademarks would likely frown on it.
> 
> I’m not sure the ASF allows new releases of commercial products to use the
> trademark name, even with qualifiers like the company that produced it.
> IIRC, Subversion sort of has a “nickname” in “SVN” that commercial
> entities can use, but not “Subversion” itself.  When Adobe brought the
> technology behind its PhoneGap product to the ASF, the project was given a
> completely new name and then even renamed itself again to “Cordova”.
> Meanwhile, AIUI, Adobe ships new releases of PhoneGap with proper
> attribution to Cordova, but there is no "Adobe Cordova”.
> 
> Of course, I could be wrong ;-)
> 
> -Alex
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Greg Stein]

On Wed, Nov 11, 2015 at 6:27 AM, Steve Loughran 
wrote:

>
> > On 11 Nov 2015, at 09:38, Bertrand Delacretaz 
> wrote:
> >
> > Hi Steve,
> >
> > On Tue, Nov 10, 2015 at 9:31 PM, Steve Loughran 
> wrote:
> >> ...is JIRA-first development conducive to developing a community?...
> >
> > I don't think so, as you say this breaks the project into very small
> > buckets and it's very hard for someone new to get the overview of
> > what's going on and what the big ideas and visions are.
>

Agreed.

I also find it sad that work is *gated* by using Jira first. We should be
trusting our peers, let them commit changes necessary, and review their
work afterwards. Trust is the basis of a healthy community, and RTC (via
Jira or otherwise) just screams "we don't trust you. we must review all
commits first."

>...

> One of the troublespots is those "minor" patches which have traumatic
> consequences; you don't notice when the issue is created, don't watch it,
> and then, when its merged in, you discover that things now behave
> differently. Anything related to specific dependency updates are things to
> watch there (guava, jackson, jersey), but it could be something more subtle
> like a change in the concurrency model of some bit of code. It's only later
> that you find your code has stopped working and you are left trying to work
> out what happened and why.
>

I'm not sure what the above has to do with issues/Jira. Any commit can have
this effect, whether it was done directly or via an issue. It's just a
typical problem with development.

(and yeah, it leads into a whole separate conversation about testing and CI)

>...

> Noted, but we're going to try it in the slider dev group anyway, so we can
> do some more detailed code review of various complex things more
> interactively. I know it excludes people who can't be there, but its still
> more inclusive of
>

I see no problem doing code reviews this way, as other devs can still
comment/review whatever output gets committed. They're only "shut out" of
the first review, not ALL review.

Using them for initial code development or decisions? Not so much.

Using them to reach a consensus among a subset of the community? Sure, and
bring that result to the dev@ list to reach full community consensus. We
see this done all the time with hackathons: the group at the 'thon come up
with some idea they all like, and bring that to the dev@ list. 10 people
think it is the right approach and share it, then rope in the other 10.

>...

Cheers,
-g

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Alex Harui]

On 11/10/15, 12:31 PM, "Steve Loughran"  wrote:

>* In any project where a significant number of the team members are
>expected to ship something in approximate correlation with a release
>schedule imposed by product management, project development decisions are
>going to follow. Similarly, priorities for weekday work by those
>engineers is going to be made by other people. This not only constrains
>what goes in, but providers a motivator for keeping things out if they're
>felt to be too risky.

I found this interesting.  Do lots of Apache projects have a schedule and
project manager?  I thought that wasn’t really the “Apache Way”.  I
thought committers could commit what they wanted with minimal coordination
amongst themselves without some other person being the gate keeper.  Seems
like that would scare away new committers who just want to scratch their
own itch.

-Alex

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Joe Witt]

"Trust is the basis of a healthy community"

-- For sure.

"and RTC (via Jira or otherwise) just screams "we don't trust you. we
must review all commits first.""

-- I disagree.  RTC has merit independent of concerns of trust.  If
trust issues are present in a community then any number of challenges
will exist and all processes will suffer.  Keep in mind RTC applies to
everyone (PMC, committer, contributor).  So it isn't about trust at
all.  It is about community.

Not wanting to sidetrack this thread but also didn't want that comment
to go without a counter.

Thanks
Joe

On Wed, Nov 11, 2015 at 12:59 PM, Greg Stein  wrote:
> On Wed, Nov 11, 2015 at 6:27 AM, Steve Loughran 
> wrote:
>
>>
>> > On 11 Nov 2015, at 09:38, Bertrand Delacretaz 
>> wrote:
>> >
>> > Hi Steve,
>> >
>> > On Tue, Nov 10, 2015 at 9:31 PM, Steve Loughran 
>> wrote:
>> >> ...is JIRA-first development conducive to developing a community?...
>> >
>> > I don't think so, as you say this breaks the project into very small
>> > buckets and it's very hard for someone new to get the overview of
>> > what's going on and what the big ideas and visions are.
>>
>
> Agreed.
>
> I also find it sad that work is *gated* by using Jira first. We should be
> trusting our peers, let them commit changes necessary, and review their
> work afterwards. Trust is the basis of a healthy community, and RTC (via
> Jira or otherwise) just screams "we don't trust you. we must review all
> commits first."
>
>>...
>
>> One of the troublespots is those "minor" patches which have traumatic
>> consequences; you don't notice when the issue is created, don't watch it,
>> and then, when its merged in, you discover that things now behave
>> differently. Anything related to specific dependency updates are things to
>> watch there (guava, jackson, jersey), but it could be something more subtle
>> like a change in the concurrency model of some bit of code. It's only later
>> that you find your code has stopped working and you are left trying to work
>> out what happened and why.
>>
>
> I'm not sure what the above has to do with issues/Jira. Any commit can have
> this effect, whether it was done directly or via an issue. It's just a
> typical problem with development.
>
> (and yeah, it leads into a whole separate conversation about testing and CI)
>
>>...
>
>> Noted, but we're going to try it in the slider dev group anyway, so we can
>> do some more detailed code review of various complex things more
>> interactively. I know it excludes people who can't be there, but its still
>> more inclusive of
>>
>
> I see no problem doing code reviews this way, as other devs can still
> comment/review whatever output gets committed. They're only "shut out" of
> the first review, not ALL review.
>
> Using them for initial code development or decisions? Not so much.
>
> Using them to reach a consensus among a subset of the community? Sure, and
> bring that result to the dev@ list to reach full community consensus. We
> see this done all the time with hackathons: the group at the 'thon come up
> with some idea they all like, and bring that to the dev@ list. 10 people
> think it is the right approach and share it, then rope in the other 10.
>
>>...
>
> Cheers,
> -g

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

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Steve Loughran]

> On 11 Nov 2015, at 09:38, Bertrand Delacretaz  wrote:
> 
> Hi Steve,
> 
> On Tue, Nov 10, 2015 at 9:31 PM, Steve Loughran  
> wrote:
>> ...is JIRA-first development conducive to developing a community?...
> 
> I don't think so, as you say this breaks the project into very small
> buckets and it's very hard for someone new to get the overview of
> what's going on and what the big ideas and visions are.
> 
> I'm a big fan of backing all my work with issue tracker tickets, but
> *decisions* (except minor ones which only have a very local impact)
> should not happen in those tickets. IMO tickets are for execution of
> something that's been decided on your project's dev list.
> 
> It's a difficult balance, and it requires all developers to be aware
> of when the time comes to stop discussing in a ticket and bring that
> discussion to the dev list.

One of the troublespots is those "minor" patches which have traumatic 
consequences; you don't notice when the issue is created, don't watch it, and 
then, when its merged in, you discover that things now behave differently. 
Anything related to specific dependency updates are things to watch there 
(guava, jackson, jersey), but it could be something more subtle like a change 
in the concurrency model of some bit of code. It's only later that you find 
your code has stopped working and you are left trying to work out what happened 
and why.

> 
>> ... Maybe we should embrace online conferencing more
> 
> I don't think so, as that's not inclusive nor asynchronous.
> 


Noted, but we're going to try it in the slider dev group anyway, so we can do 
some more detailed code review of various complex things more interactively. I 
know it excludes people who can't be there, but its still more inclusive of 


> IMO the combination of dev list + tickets can work well but it
> requires lots of discipline for the most active developers, to make
> sure they expose their ideas, decisions and discussions to their
> project's dev list.
> 
> -

what we shouldn't be doing in conf calls is those big decisions, the stuff 
you'd vote on; the mailing list must also be the normative history of 
discussions. It's just that the online conf tooling has grown so that its 
fairly straightforward to have a small multuser conf with google+ (sadly 
excluding all .cn participants), and an awful but global experience using Cisco 
webex.

-Steve

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

[VOTE] Apache DataFu 1.3.0 (incubating)

[Matthew Hayes]

Hi all,

The Apache DataFu community has voted on and approved a proposal to release
Apache DataFu 1.3.0 (incubating).  This is the first release since the
project began incubating!

Proposal:

http://mail-archives.apache.org/mod_mbox/incubator-datafu-dev/201511.mbox/%3CCAA4Vo8BR_-8whhNYr6jUdXTrE2ZYZWwJEx2XvgHDt22SRyr55w%40mail.gmail.com%3E

Results:

3 binding +1 votes
No 0 votes
No -1 votes

http://mail-archives.apache.org/mod_mbox/incubator-datafu-dev/201511.mbox/%3CCAA4Vo8ARiFsxZnRbZ-QPp9y_%2B_2SDhA%3DT4UChH24kaqtLG-PMA%40mail.gmail.com%3E

You can download the release candidate RC1 here:

http://people.apache.org/~mhayes/incubator-datafu-1.3.0-rc1/

This has been signed with PGP key 01D3DE61, which is included in the
repository's KEYS file.  This key can be found on keyservers, such as:

http://pgp.mit.edu/pks/lookup?op=get=0x01D3DE61

The release candidate has been tagged with release-1.3.0-rc1, which has
been signed with the same key.  You can also checkout branch 1.3.0.  For
repo checkout instructions, please see:

http://datafu.incubator.apache.org/community/contributing.html

For reference, here is a list of all closed JIRAs tagged with 1.3.0:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20DATAFU%20AND%20fixVersion%20%3D%201.3.0%20ORDER%20BY%20updated%20DESC%2C%20created%20DESC%2C%20status%20DESC%2C%20priority%20DESC

For a summary of the changes, see:

https://github.com/apache/incubator-datafu/blob/master/changes.md

The vote will be open for 72 hours.

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Thanks,
Matt, on behalf of the Apache DataFu PPMC

Re: [Result][VOTE] Graduate Apache Kylin from the Apache Incubator

[John D. Ament]

Looks good to me, consider my vote a +1 after seeing a good release.

John

On Wed, Nov 11, 2015 at 4:53 AM Luke Han  wrote:

> 1. v1.1.1-incubating release vote result link: http://s.apache.org/Zps
>
>
>
> Best Regards!
> -
>
> Luke Han
>
> On Wed, Nov 11, 2015 at 5:52 PM, Luke Han  wrote:
>
> > Hi all,
> >  Apache Kylin's new release, v1.1.1-incubating, has been rolled out
> > with KYLIN-999 fixed [1].
> >  Could you please help to check again and convert your -1 vote for
> the
> > graduation if possible.
> >
> >  Really appreciated for your guide and help.
> >
> >  Thanks.
> > Luke
> >
> >
> > Best Regards!
> > -
> >
> > Luke Han
> >
> > On Wed, Nov 4, 2015 at 10:23 PM, Luke Han  wrote:
> >
> >> Hi there,
> >> The new release (v1.1.1) already rolled out in IPMC for vote now
> [1].
> >>
> >> The release vote in IPMC will send out later once vote pass in PPMC,
> >> but it will perfect if someone could help to double check and test this
> >> release if possible in advance. Just want to make sure such concern and
> >> issue already be fixed in this release.
> >>
> >>  Thank you very much.
> >>
> >> Luke
> >>
> >> [1]. *http://s.apache.org/kV2 *
> >>
> >>
> >>
> >> Best Regards!
> >> -
> >>
> >> Luke Han
> >>
> >> On Wed, Nov 4, 2015 at 12:15 PM, Luke Han  wrote:
> >>
> >>> The merge will happen after release, but we could apply this patch
> first
> >>> if community has concern about this.
> >>>
> >>> Thanks.
> >>>
> >>> Regards!
> >>> Luke Han
> >>>
> >>>
> >>>
> >>>
> >>> On Tue, Nov 3, 2015 at 7:57 PM -0800, "John D. Ament" <
> >>> johndam...@apache.org> wrote:
> >>>
> >>> That's a good way to fix it. Do you merge your release branches back to
>  master/next develop?
>  On Nov 3, 2015 22:04, "Luke Han"  wrote:
> 
>  > Anyway, removed such reference in Kylin's code, there's no more
> Google
>  > Fonts or Adobe Fonts now.
>  >
>  > Please help to check:
>  >
>  >
> https://github.com/apache/incubator-kylin/commit/a2fa3e8e93765bf3db39f5da935aca3a588789f1
>  >
>  > Thanks.
>  >
>  >
>  > Best Regards!
>  > -
>  >
>  > Luke Han
>  >
>  > On Wed, Nov 4, 2015 at 10:56 AM, Justin Mclean
>  > wrote:
>  >
>  > > Hi,
>  > >
>  > > > The referenced font is SIL OFL 1.1
>  > > > http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi=OFL
>  > > >
>  > > > You're not technically bundling the font, but referencing it
> via URL.
>  > > It's
>  > > > a good question for legal.
>  > >
>  > > The fonts are actually being bundled as well. [1] It just not
> obvious
>  > from
>  > > their names.
>  > >
>  > > Thanks,
>  > > Justin
>  > >
>  > > 1.
>  > >
>  >
> https://github.com/apache/incubator-kylin/tree/1.x-staging/webapp/app/fonts
>  > >
> -
>  > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>  > > For additional commands, e-mail:
> general-h...@incubator.apache.org
>  > >
>  > >
>  >
> 
> 
> >>
> >
>

Re: [Result][VOTE] Graduate Apache Kylin from the Apache Incubator

[Luke Han]

Thanks John. really happy to have your +1 vote :)








Best Regards!
-

Luke Han

On Thu, Nov 12, 2015 at 7:45 AM, John D. Ament 
wrote:

> Looks good to me, consider my vote a +1 after seeing a good release.
>
> John
>
> On Wed, Nov 11, 2015 at 4:53 AM Luke Han  wrote:
>
> > 1. v1.1.1-incubating release vote result link: http://s.apache.org/Zps
> >
> >
> >
> > Best Regards!
> > -
> >
> > Luke Han
> >
> > On Wed, Nov 11, 2015 at 5:52 PM, Luke Han  wrote:
> >
> > > Hi all,
> > >  Apache Kylin's new release, v1.1.1-incubating, has been rolled out
> > > with KYLIN-999 fixed [1].
> > >  Could you please help to check again and convert your -1 vote for
> > the
> > > graduation if possible.
> > >
> > >  Really appreciated for your guide and help.
> > >
> > >  Thanks.
> > > Luke
> > >
> > >
> > > Best Regards!
> > > -
> > >
> > > Luke Han
> > >
> > > On Wed, Nov 4, 2015 at 10:23 PM, Luke Han  wrote:
> > >
> > >> Hi there,
> > >> The new release (v1.1.1) already rolled out in IPMC for vote now
> > [1].
> > >>
> > >> The release vote in IPMC will send out later once vote pass in
> PPMC,
> > >> but it will perfect if someone could help to double check and test
> this
> > >> release if possible in advance. Just want to make sure such concern
> and
> > >> issue already be fixed in this release.
> > >>
> > >>  Thank you very much.
> > >>
> > >> Luke
> > >>
> > >> [1]. *http://s.apache.org/kV2 *
> > >>
> > >>
> > >>
> > >> Best Regards!
> > >> -
> > >>
> > >> Luke Han
> > >>
> > >> On Wed, Nov 4, 2015 at 12:15 PM, Luke Han  wrote:
> > >>
> > >>> The merge will happen after release, but we could apply this patch
> > first
> > >>> if community has concern about this.
> > >>>
> > >>> Thanks.
> > >>>
> > >>> Regards!
> > >>> Luke Han
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Tue, Nov 3, 2015 at 7:57 PM -0800, "John D. Ament" <
> > >>> johndam...@apache.org> wrote:
> > >>>
> > >>> That's a good way to fix it. Do you merge your release branches back
> to
> >  master/next develop?
> >  On Nov 3, 2015 22:04, "Luke Han"  wrote:
> > 
> >  > Anyway, removed such reference in Kylin's code, there's no more
> > Google
> >  > Fonts or Adobe Fonts now.
> >  >
> >  > Please help to check:
> >  >
> >  >
> >
> https://github.com/apache/incubator-kylin/commit/a2fa3e8e93765bf3db39f5da935aca3a588789f1
> >  >
> >  > Thanks.
> >  >
> >  >
> >  > Best Regards!
> >  > -
> >  >
> >  > Luke Han
> >  >
> >  > On Wed, Nov 4, 2015 at 10:56 AM, Justin Mclean
> >  > wrote:
> >  >
> >  > > Hi,
> >  > >
> >  > > > The referenced font is SIL OFL 1.1
> >  > > >
> http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi=OFL
> >  > > >
> >  > > > You're not technically bundling the font, but referencing it
> > via URL.
> >  > > It's
> >  > > > a good question for legal.
> >  > >
> >  > > The fonts are actually being bundled as well. [1] It just not
> > obvious
> >  > from
> >  > > their names.
> >  > >
> >  > > Thanks,
> >  > > Justin
> >  > >
> >  > > 1.
> >  > >
> >  >
> >
> https://github.com/apache/incubator-kylin/tree/1.x-staging/webapp/app/fonts
> >  > >
> > -
> >  > > To unsubscribe, e-mail:
> general-unsubscr...@incubator.apache.org
> >  > > For additional commands, e-mail:
> > general-h...@incubator.apache.org
> >  > >
> >  > >
> >  >
> > 
> > 
> > >>
> > >
> >
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Marvin Humphrey]

On Tue, Nov 10, 2015 at 12:31 PM, Steve Loughran  wrote:
> This is an interesting topic, and one that is broader than just Apache
> Sentry (incubating). Even so, I want to praise Joe Brockmeier for raising
> it, and the comments -especially those from Greg Stein and Rich Bowen and
> Marvin Humphrey for making me think more about this.

I'd also like to acknowledge Patrick Hunt and Sravya Tirukkovalur who have
done the heavy lifting in defense of Sentry. Having to respond to critiques is
an uncomfortable position to be in, and it is with their endurance that we
have been able to have a productive discussion.

Marvin Humphrey

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

Incubator Wiki Request

[david]

Please add wiki username DavidFallside to the Contributors Group so that I
may put forward a new proposal.
Thank you,
David Fallside



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

Re: [DISCUSS] S2Graph Incubator Proposal

[Hyunsik Choi]

Hi Luke,

Thank you for your interest in S2Graph project. If you don't mind,
we'd like to add you to the initial committer list. I think that your
experience and skills about HBase would be very helpful to S2Graph
project.

Best regards,
Hyunsik

On Mon, Nov 9, 2015 at 6:58 PM, Luke Han  wrote:
> I'm very interesting about this project, would love to help but I'm not
> IPMC member.
>
> Please let me know if there's anything I could help on.
>
> Thanks.
>
>
> Best Regards!
> -
>
> Luke Han
>
> On Tue, Nov 10, 2015 at 9:03 AM, Hyunsik Choi  wrote:
>
>> Hi Seetharam,
>>
>> Thank you for your volunteering! I've added your name to the mentor list.
>>
>> I also updated the initial committer list and affiliations via google
>> search.
>> If I wrote wrong affiliations, please let me know.
>>
>> Best regards,
>> Hyunsik
>>
>>
>> On Mon, Nov 9, 2015 at 4:21 PM, Seetharam Venkatesh
>>  wrote:
>> > Hi Hyunsik,
>> >
>> > If you are still looking for mentors, let me volunteer as one.
>> >
>> > Thanks!
>> >
>> > On Mon, Nov 9, 2015 at 3:45 PM Hyunsik Choi  wrote:
>> >
>> >> Thank you all guys  I just put you names on the nominated mentor list.
>> >>
>> >> @Andrew,
>> >>
>> >> I agree with you. S2Graph already has good relationships with other
>> >> ASF projects, such as HBase and Spark,  In addition, they have a plan
>> >> to expand its relationship to Apache incubator TinkerPop, which is a
>> >> graph computing framework. I'm looking forward to their combinations.
>> >>
>> >> @Sergio,
>> >>
>> >> Thank you for attending the talk and joining the S2Graph mentors. That
>> >> was Doyung Yoon, one of the S2Graph creators. He had a talk at the
>> >> last ApacheCon.
>> >>
>> >> On Mon, Nov 9, 2015 at 11:58 AM, Sergio Fernández 
>> >> wrote:
>> >> > Hi Hyunsik, I attended your talk at the last ApacheCon, and I think S2
>> >> has
>> >> > quite some potential. So if you need a mentor, count me in!
>> >> >
>> >> > On Mon, Nov 9, 2015 at 7:54 PM, Hyunsik Choi 
>> wrote:
>> >> >
>> >> >> This project is looking for mentors. Anyone can help? We are also
>> >> >> looking forward to any feedback.
>> >> >>
>> >> >> Also, I attached the proposal here. I forgot it.
>> >> >>
>> >> >> 
>> >> >>
>> >> >> = S2Graph Proposal =
>> >> >>
>> >> >> == Abstract ==
>> >> >> S2Graph is a distributed and scalable OLTP graph database built on
>> >> >> HBase to support fast traversal on extremely large graph.
>> >> >>
>> >> >> Here are additional materials to introduce S2Graph.
>> >> >>  * HBaseCon 2015 -
>> >> http://www.slideshare.net/HBaseCon/use-cases-session-5
>> >> >>  * Apache: Big Data 2015 -
>> >> >>
>> http://schd.ws/hosted_files/apachebigdata2015/06/s2graph_apache_con.pdf
>> >> >>
>> >> >> == Proposal ==
>> >> >> S2Graph is to provide a scalable distributed graph database engine
>> >> >> over key/value storage such as HBase. S2Graph provide fully
>> >> >> ashynchronous API to manupulate data as property graph model and fast
>> >> >> breadth first search query on graph.
>> >> >>
>> >> >> == Background ==
>> >> >> S2Graph initially started as an internal project at Kakao.com to
>> >> >> efficiently store user relation and user activities as one large
>> graph
>> >> >> and provide unified query to traverse graph. It was open sourced on
>> >> >> Github about a 3 months ago in June 2015.
>> >> >>
>> >> >> Over time S2Graph, together with HBase as storage tier, has begun to
>> >> >> be adapted into various applications, such as messaging, social
>> feeds,
>> >> >> realtime recommendations at Kakao.
>> >> >>
>> >> >> Users can benefit from S2Graph`s generalized high level API instead
>> of
>> >> >> low-level key/value API for graph abstraction, just like Phoenix
>> >> >> provide SQL layer over HBase.
>> >> >>
>> >> >> == Rationale ==
>> >> >> Graph data(highly interconnected data) is very abundant and important
>> >> >> these days.
>> >> >> When users have a multitude of relationships, each with complex
>> >> >> properties associated with them, graph model is more intuitive and
>> >> >> efficient than tabular format(RDBMS).
>> >> >> There are many ASF projects that provide SQL layer, but there is no
>> >> >> ASF projects that provide scalable graph layer on existing hadoop
>> echo
>> >> >> system.
>> >> >> When graph data grows to trillion edge scale, the process of
>> >> >> traversing takes a long time and costly. However, with the benefit of
>> >> >> HBase`s scalable architecture, S2Graph can traverse large graph in
>> >> >> breadth first search manner efficiently.
>> >> >>
>> >> >> S2Graph also interoperates with several existing Apache
>> >> >> projects(HBase, Spark) to provide way to merge real time events and
>> >> >> batch processed data using property graph data model.
>> >> >>
>> >> >> Many developers are running their own domain specific API servers to
>> >> >> serve their data 

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Ted Dunning]

Yes.  It is very much like a hackathon.

And it has some benefits in that somebody in a small town who couldn't make
it to a hackathon in person but who happens to be near the right time zone
can still participate.


On Wed, Nov 11, 2015 at 2:07 PM, Pierre Smits 
wrote:

> In that respect it is just like a hackathon.
>
> Best regards,
>
> Pierre Smits
>
> *OFBiz Extensions Marketplace*
> http://oem.ofbizci.net/oci-2/
>
>
> On Wed, Nov 11, 2015 at 11:03 PM, Ted Dunning 
> wrote:
>
> > Actually, I have seen some real benefits of on-line conferencing.  These
> > benefits are similar to conferences and meetups.
> >
> > It is clear that the way you have to do these things is *in*addition* to
> > the normal email discipline, but the addition can really be positive in
> > that quiet lurkers on the mailing list can sometimes be interactive in an
> > online conference and be encouraged. That leads to better involvement in
> > other aspects of the project.
> >
> > I do think that a bit of diversity in *when* the on-line conferencing is
> > done can be very helpful for time zone inclusiveness.
> >
> >
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Ted Dunning]

Actually, I have seen some real benefits of on-line conferencing.  These
benefits are similar to conferences and meetups.

It is clear that the way you have to do these things is *in*addition* to
the normal email discipline, but the addition can really be positive in
that quiet lurkers on the mailing list can sometimes be interactive in an
online conference and be encouraged. That leads to better involvement in
other aspects of the project.

I do think that a bit of diversity in *when* the on-line conferencing is
done can be very helpful for time zone inclusiveness.




On Wed, Nov 11, 2015 at 10:16 AM, Joe Witt  wrote:

> "Trust is the basis of a healthy community"
>
> -- For sure.
>
> "and RTC (via Jira or otherwise) just screams "we don't trust you. we
> must review all commits first.""
>
> -- I disagree.  RTC has merit independent of concerns of trust.  If
> trust issues are present in a community then any number of challenges
> will exist and all processes will suffer.  Keep in mind RTC applies to
> everyone (PMC, committer, contributor).  So it isn't about trust at
> all.  It is about community.
>
> Not wanting to sidetrack this thread but also didn't want that comment
> to go without a counter.
>
> Thanks
> Joe
>
> On Wed, Nov 11, 2015 at 12:59 PM, Greg Stein  wrote:
> > On Wed, Nov 11, 2015 at 6:27 AM, Steve Loughran 
> > wrote:
> >
> >>
> >> > On 11 Nov 2015, at 09:38, Bertrand Delacretaz  >
> >> wrote:
> >> >
> >> > Hi Steve,
> >> >
> >> > On Tue, Nov 10, 2015 at 9:31 PM, Steve Loughran <
> ste...@hortonworks.com>
> >> wrote:
> >> >> ...is JIRA-first development conducive to developing a community?...
> >> >
> >> > I don't think so, as you say this breaks the project into very small
> >> > buckets and it's very hard for someone new to get the overview of
> >> > what's going on and what the big ideas and visions are.
> >>
> >
> > Agreed.
> >
> > I also find it sad that work is *gated* by using Jira first. We should be
> > trusting our peers, let them commit changes necessary, and review their
> > work afterwards. Trust is the basis of a healthy community, and RTC (via
> > Jira or otherwise) just screams "we don't trust you. we must review all
> > commits first."
> >
> >>...
> >
> >> One of the troublespots is those "minor" patches which have traumatic
> >> consequences; you don't notice when the issue is created, don't watch
> it,
> >> and then, when its merged in, you discover that things now behave
> >> differently. Anything related to specific dependency updates are things
> to
> >> watch there (guava, jackson, jersey), but it could be something more
> subtle
> >> like a change in the concurrency model of some bit of code. It's only
> later
> >> that you find your code has stopped working and you are left trying to
> work
> >> out what happened and why.
> >>
> >
> > I'm not sure what the above has to do with issues/Jira. Any commit can
> have
> > this effect, whether it was done directly or via an issue. It's just a
> > typical problem with development.
> >
> > (and yeah, it leads into a whole separate conversation about testing and
> CI)
> >
> >>...
> >
> >> Noted, but we're going to try it in the slider dev group anyway, so we
> can
> >> do some more detailed code review of various complex things more
> >> interactively. I know it excludes people who can't be there, but its
> still
> >> more inclusive of
> >>
> >
> > I see no problem doing code reviews this way, as other devs can still
> > comment/review whatever output gets committed. They're only "shut out" of
> > the first review, not ALL review.
> >
> > Using them for initial code development or decisions? Not so much.
> >
> > Using them to reach a consensus among a subset of the community? Sure,
> and
> > bring that result to the dev@ list to reach full community consensus. We
> > see this done all the time with hackathons: the group at the 'thon come
> up
> > with some idea they all like, and bring that to the dev@ list. 10 people
> > think it is the right approach and share it, then rope in the other 10.
> >
> >>...
> >
> > Cheers,
> > -g
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Pierre Smits]

In that respect it is just like a hackathon.

Best regards,

Pierre Smits

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

On Wed, Nov 11, 2015 at 11:03 PM, Ted Dunning  wrote:

> Actually, I have seen some real benefits of on-line conferencing.  These
> benefits are similar to conferences and meetups.
>
> It is clear that the way you have to do these things is *in*addition* to
> the normal email discipline, but the addition can really be positive in
> that quiet lurkers on the mailing list can sometimes be interactive in an
> online conference and be encouraged. That leads to better involvement in
> other aspects of the project.
>
> I do think that a bit of diversity in *when* the on-line conferencing is
> done can be very helpful for time zone inclusiveness.
>
>
>
>
> On Wed, Nov 11, 2015 at 10:16 AM, Joe Witt  wrote:
>
> > "Trust is the basis of a healthy community"
> >
> > -- For sure.
> >
> > "and RTC (via Jira or otherwise) just screams "we don't trust you. we
> > must review all commits first.""
> >
> > -- I disagree.  RTC has merit independent of concerns of trust.  If
> > trust issues are present in a community then any number of challenges
> > will exist and all processes will suffer.  Keep in mind RTC applies to
> > everyone (PMC, committer, contributor).  So it isn't about trust at
> > all.  It is about community.
> >
> > Not wanting to sidetrack this thread but also didn't want that comment
> > to go without a counter.
> >
> > Thanks
> > Joe
> >
> > On Wed, Nov 11, 2015 at 12:59 PM, Greg Stein  wrote:
> > > On Wed, Nov 11, 2015 at 6:27 AM, Steve Loughran <
> ste...@hortonworks.com>
> > > wrote:
> > >
> > >>
> > >> > On 11 Nov 2015, at 09:38, Bertrand Delacretaz <
> bdelacre...@apache.org
> > >
> > >> wrote:
> > >> >
> > >> > Hi Steve,
> > >> >
> > >> > On Tue, Nov 10, 2015 at 9:31 PM, Steve Loughran <
> > ste...@hortonworks.com>
> > >> wrote:
> > >> >> ...is JIRA-first development conducive to developing a
> community?...
> > >> >
> > >> > I don't think so, as you say this breaks the project into very small
> > >> > buckets and it's very hard for someone new to get the overview of
> > >> > what's going on and what the big ideas and visions are.
> > >>
> > >
> > > Agreed.
> > >
> > > I also find it sad that work is *gated* by using Jira first. We should
> be
> > > trusting our peers, let them commit changes necessary, and review their
> > > work afterwards. Trust is the basis of a healthy community, and RTC
> (via
> > > Jira or otherwise) just screams "we don't trust you. we must review all
> > > commits first."
> > >
> > >>...
> > >
> > >> One of the troublespots is those "minor" patches which have traumatic
> > >> consequences; you don't notice when the issue is created, don't watch
> > it,
> > >> and then, when its merged in, you discover that things now behave
> > >> differently. Anything related to specific dependency updates are
> things
> > to
> > >> watch there (guava, jackson, jersey), but it could be something more
> > subtle
> > >> like a change in the concurrency model of some bit of code. It's only
> > later
> > >> that you find your code has stopped working and you are left trying to
> > work
> > >> out what happened and why.
> > >>
> > >
> > > I'm not sure what the above has to do with issues/Jira. Any commit can
> > have
> > > this effect, whether it was done directly or via an issue. It's just a
> > > typical problem with development.
> > >
> > > (and yeah, it leads into a whole separate conversation about testing
> and
> > CI)
> > >
> > >>...
> > >
> > >> Noted, but we're going to try it in the slider dev group anyway, so we
> > can
> > >> do some more detailed code review of various complex things more
> > >> interactively. I know it excludes people who can't be there, but its
> > still
> > >> more inclusive of
> > >>
> > >
> > > I see no problem doing code reviews this way, as other devs can still
> > > comment/review whatever output gets committed. They're only "shut out"
> of
> > > the first review, not ALL review.
> > >
> > > Using them for initial code development or decisions? Not so much.
> > >
> > > Using them to reach a consensus among a subset of the community? Sure,
> > and
> > > bring that result to the dev@ list to reach full community consensus.
> We
> > > see this done all the time with hackathons: the group at the 'thon come
> > up
> > > with some idea they all like, and bring that to the dev@ list. 10
> people
> > > think it is the right approach and share it, then rope in the other 10.
> > >
> > >>...
> > >
> > > Cheers,
> > > -g
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Ted Dunning]

Alex,

Yes.  Pretty much any project that has significant commercial applications
will have cadres of developers from companies involved.  Those companies
will be managing those developers time and efforts to meet the company
goals.

This can definitely be pernicious, especially since a company may be making
decisions about which general areas they want to be pushing off-line. This
affects the project majorly even if the technical and coding decisions are
made in good fashion.

Another problem is that when some developers are working 40 hours per week
plus on a project, volunteer developers often have a very hard time keeping
up with the pace of change.  Building safe havens not only for different
timezones but also for different time rates is an architectural challenge
that is well worth doing. One way to do this is with very clean
user-defined-function sorts of architectures.  That can help moderate the
rate of change.


On Wed, Nov 11, 2015 at 10:16 AM, Joe Witt  wrote:

> "Trust is the basis of a healthy community"
>
> -- For sure.
>
> "and RTC (via Jira or otherwise) just screams "we don't trust you. we
> must review all commits first.""
>
> -- I disagree.  RTC has merit independent of concerns of trust.  If
> trust issues are present in a community then any number of challenges
> will exist and all processes will suffer.  Keep in mind RTC applies to
> everyone (PMC, committer, contributor).  So it isn't about trust at
> all.  It is about community.
>
> Not wanting to sidetrack this thread but also didn't want that comment
> to go without a counter.
>
> Thanks
> Joe
>
> On Wed, Nov 11, 2015 at 12:59 PM, Greg Stein  wrote:
> > On Wed, Nov 11, 2015 at 6:27 AM, Steve Loughran 
> > wrote:
> >
> >>
> >> > On 11 Nov 2015, at 09:38, Bertrand Delacretaz  >
> >> wrote:
> >> >
> >> > Hi Steve,
> >> >
> >> > On Tue, Nov 10, 2015 at 9:31 PM, Steve Loughran <
> ste...@hortonworks.com>
> >> wrote:
> >> >> ...is JIRA-first development conducive to developing a community?...
> >> >
> >> > I don't think so, as you say this breaks the project into very small
> >> > buckets and it's very hard for someone new to get the overview of
> >> > what's going on and what the big ideas and visions are.
> >>
> >
> > Agreed.
> >
> > I also find it sad that work is *gated* by using Jira first. We should be
> > trusting our peers, let them commit changes necessary, and review their
> > work afterwards. Trust is the basis of a healthy community, and RTC (via
> > Jira or otherwise) just screams "we don't trust you. we must review all
> > commits first."
> >
> >>...
> >
> >> One of the troublespots is those "minor" patches which have traumatic
> >> consequences; you don't notice when the issue is created, don't watch
> it,
> >> and then, when its merged in, you discover that things now behave
> >> differently. Anything related to specific dependency updates are things
> to
> >> watch there (guava, jackson, jersey), but it could be something more
> subtle
> >> like a change in the concurrency model of some bit of code. It's only
> later
> >> that you find your code has stopped working and you are left trying to
> work
> >> out what happened and why.
> >>
> >
> > I'm not sure what the above has to do with issues/Jira. Any commit can
> have
> > this effect, whether it was done directly or via an issue. It's just a
> > typical problem with development.
> >
> > (and yeah, it leads into a whole separate conversation about testing and
> CI)
> >
> >>...
> >
> >> Noted, but we're going to try it in the slider dev group anyway, so we
> can
> >> do some more detailed code review of various complex things more
> >> interactively. I know it excludes people who can't be there, but its
> still
> >> more inclusive of
> >>
> >
> > I see no problem doing code reviews this way, as other devs can still
> > comment/review whatever output gets committed. They're only "shut out" of
> > the first review, not ALL review.
> >
> > Using them for initial code development or decisions? Not so much.
> >
> > Using them to reach a consensus among a subset of the community? Sure,
> and
> > bring that result to the dev@ list to reach full community consensus. We
> > see this done all the time with hackathons: the group at the 'thon come
> up
> > with some idea they all like, and bring that to the dev@ list. 10 people
> > think it is the right approach and share it, then rope in the other 10.
> >
> >>...
> >
> > Cheers,
> > -g
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Incubator Wiki Request

[Marvin Humphrey]

On Wed, Nov 11, 2015 at 11:49 AM,   wrote:
> Please add wiki username DavidFallside to the Contributors Group so that I
> may put forward a new proposal.

Done.

Marvin Humphrey

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