Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
From: "Chen, Haifeng" <haifeng.chen@intel.com>
To: Commons Developers List <dev@commons.apache.org>
CC: "common-dev@hadoop.apache.org" <common-dev@hadoop.apache.org>
Subject: RE: [crypto][chimera] Next steps
Thread-Topic: [crypto][chimera] Next steps
Thread-Index: 
 AQHRa9ACQA5pbKN60EKP+imQynGD8p83zyoAgACQBICAAFxdAIAAG1yAgAABkICAAMfEAIABAaiQgALyhVA=
Date: Fri, 26 Feb 2016 02:24:45 +0000
Message-ID: 
 <3E657120E422654A9EB626F537B8AA911410A0ED@shsmsx102.ccr.corp.intel.com>
References: 
 <CAB917RKp_Nk=rVVSG0VAkHuoxeN8aZ0iJegY29eVCHAnH_rhHw@mail.gmail.com>
 <CA+qbEUPODqyMc9UXRG=JFx0Qk8UXgQCbHcFs3HqpU7VUqgKWQA@mail.gmail.com>
 <17B91B6B0D9BBC44A1682DABC201C53503EBF6C1@SHSMSX103.ccr.corp.intel.com>
 <CAB917RKmWsUPMXYJG-ok1w4zZ1ePqP=4t+c638Kp=gMUJp40oQ@mail.gmail.com>
 <CAOGo0Vb4tgsQTzkDwsQgjkyUfPQ6vZLFP1neyuSv26NcL7NCQg@mail.gmail.com>
 <56CC23CD.4020804@apache.org> <D2F20519.136E0%uma.gangumalla@intel.com>
 <3E657120E422654A9EB626F537B8AA9114108EEC@shsmsx102.ccr.corp.intel.com>
In-Reply-To: 
 <3E657120E422654A9EB626F537B8AA9114108EEC@shsmsx102.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Come back to clear out the codebase and IP concerns.

[Benedikt] I still have concerns about the IP, since this seems to be an In=
tel codebase.
I have checked this. Chimera was developed as Apache 2 License from ground =
up. Agree with Jochen that the license matters.
Internally, this was approved as part of larger open source efforts on Apac=
he Hadoop and related projects in Intel. We have IP plan considered as part=
 the open source process.

As to the codebase, such as the package name is com.intel prefixed, it was =
technical decision when using com.intel.chimera as the package prefix. We o=
riginal planned to use org.apache.chimera prefix. But we found that we coul=
dnot publish org.apache. grouped artifacts to maven central repository, whi=
ch needs to somewhat ownership for org.apache domain.

To resolve the codebase problem, once all things are ready from Commons, we=
 rename in a branch. And the branched code can be copied into Commons githu=
b as final.=20

Thanks,
Haifeng


-----Original Message-----
From: Chen, Haifeng [mailto:haifeng.chen@intel.com]=20
Sent: Wednesday, February 24, 2016 12:40 PM
To: Commons Developers List <dev@commons.apache.org>
Cc: common-dev@hadoop.apache.org
Subject: RE: [crypto][chimera] Next steps

>> The same should be there with Chimera/Apache Crypto.
Yes, current implementation will fallback to JCE Cipher if native is not av=
ailable.

[Uma] we would fix up IP issues if any sooner. If you see all the code file=
 license header is with Apache License files.
The current repo and package structure there with name Intel. I will check =
with Haifeng on resolution of this.
I will work with this ASAP for clear this out.

Thanks,
Haifeng

-----Original Message-----
From: Gangumalla, Uma [mailto:uma.gangumalla@intel.com]
Sent: Wednesday, February 24, 2016 5:13 AM
To: Commons Developers List <dev@commons.apache.org>
Cc: common-dev@hadoop.apache.org
Subject: Re: [crypto][chimera] Next steps

Thanks all for the valuable feedbacks and discussions.
Here are my replies for some of the questions..
[Mark wrote]
It depends. I care less about the quality of the code than I do about the c=
ommunity that comes with it / forms around it. A strong community can fix c=
ode issues. Great code can't save a weak community.
[uma] Nice point. Fully agreed to it.


[Jochen wrote]
Therefore, I suggest that you provide at least fallback implementations in =
pure Java, which are being used, if the JNI based stuff is not available (f=
or whatever reason).
[Uma] Thank you for the suggestion Jochen, If I understand your point right=
,  Yes its there in Hadoop when we develop.
Here is the JIRA HADOOP-10735 : Fall back AesCtrCryptoCodec implementation =
from OpenSSL to JCE if non native support.

The same should be there with Chimera/Apache Crypto.


[Benedikt]
I still have concerns about the IP, since this seems to be an Intel codebas=
e. I do not have the necessary experience to say what would be the right wa=
y here. My gut feeling tells me, that we should go through the incubator. W=
DYT?
And [Jochen wrote]
"An Intel codebase" is not a problem as such. Question is: "Available under=
 what license?"

[Uma] we would fix up IP issues if any sooner. If you see all the code file=
 license header is with Apache License files.
The current repo and package structure there with name Intel. I will check =
with Haifeng on resolution of this.


[Jochen wrote]
So, have the Chimera project attempt to resolve them quickly. If
possible: Fine. If not: We still have the Incubator as a possibility.
[Uma] Agree. We would resolve on this points in sooner.


Regards,
Uma

=20
On 2/23/16, 1:18 AM, "Mark Thomas" <markt@apache.org> wrote:

>On 23/02/2016 09:12, sebb wrote:
>> On 23 February 2016 at 07:34, Benedikt Ritter <britter@apache.org>
>>wrote:
>>> I'm confused. None of the other PMC members has expressed whether he=20
>>>or she  want's the see Chimera/crypto joining Apache Commons, yet=20
>>>we're already  discussing how JNI bindings should be handled.
>>>
>>> I'd like to see:
>>> 1) a clear statement whether Chimera/crypto should become part of=20
>>>Apache  Commons. Do we need a vote for that?
>>=20
>> Yes, of course.
>>=20
>> However that decision clearly depends on at least some of the design=20
>> aspects of the code.
>> If it were written entirely in C or Fortran, it would not be a=20
>> suitable candidate.
>>=20
>>> 2) Discuss a plan on how to do that (I've described a possible plan
>>>[1])
>>> 3) After that is clear: discuss design details regarding the component.
>>=20
>> Some design details impact on the decision.
>>=20
>> Indeed even for pure Java code the code quality has a bearing on=20
>> whether Commons would/could want to take it.
>> Would we want a large code base with no unit-tests, no build=20
>> mechanism, and no comments?
>
>It depends. I care less about the quality of the code than I do about=20
>the community that comes with it / forms around it. A strong community=20
>can fix code issues. Great code can't save a weak community.
>
>How about creating a new sandbox component, let folks start work and=20
>see how the community develops?
>
>Mark
>
>
>>=20
>>> Thanks! :-)
>>> Benedikt
>>>
>>> [1] http://markmail.org/message/74j4el6bpfpt4evs
>>>
>>> 2016-02-23 3:03 GMT+01:00 Xu, Cheng A <cheng.a.xu@intel.com>:
>>>
>>>> At this point, it has just Java interfaces only.
>>>>
>>>> -----Original Message-----
>>>> From: Colin P. McCabe [mailto:cmccabe@apache.org]
>>>> Sent: Tuesday, February 23, 2016 1:29 AM
>>>> To: Hadoop Common
>>>> Cc: Commons Developers List
>>>> Subject: Re: [crypto][chimera] Next steps
>>>>
>>>> I would highly recommend shading this library when it is used in=20
>>>> Hadoop and/or Spark, to prevent version skew problems between=20
>>>> Hadoop and Spark like we have had in the past.
>>>>
>>>> What is the strategy for handling JNI components?  I think at a=20
>>>> minimum, we should include the version number in the native library=20
>>>> name to avoid problems when deploying multiple versions of Chimera.
>>>> This is something that has been problematic in Hadoop with=20
>>>> libhadoop.so.
>>>>
>>>> Is this library going to have Scala interfaces as well as Java=20
>>>> ones, or just Java?
>>>>
>>>> cheers,
>>>> Colin
>>>>
>>>> On Sat, Feb 20, 2016 at 3:15 AM, Benedikt Ritter=20
>>>> <britter@apache.org>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> I'd like to discuss the next steps for moving the Chimera=20
>>>>>component to  Apache Commons. So far, none of the other PMC members=20
>>>>>has expressed his
>>>> or
>>>>> her thoughts about this. If nobody brings up objections about=20
>>>>>moving the  component to Apache Commons, I'm assuming lazy=20
>>>>>consensus about this.
>>>>>
>>>>> So the next steps would be:
>>>>> - decide on a name for the new component (my proposal was Apache=20
>>>>>Commons
>>>>> Crypto)
>>>>> - move code to an Apache repo (probably git?!)
>>>>> - request a Jira project
>>>>> - setup maven build
>>>>> - setup project website
>>>>> - work on an initial release under Apache Commons coordinates
>>>>>
>>>>> Anything missing?
>>>>>
>>>>> Regards,
>>>>> Benedikt
>>>>>
>>>>> --
>>>>> http://home.apache.org/~britter/
>>>>> http://twitter.com/BenediktRitter
>>>>> http://github.com/britter
>>>>
>>>> -------------------------------------------------------------------
>>>> -- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> http://home.apache.org/~britter/
>>> http://twitter.com/BenediktRitter
>>> http://github.com/britter
>>=20
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>=20
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>For additional commands, e-mail: dev-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org