commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gangumalla, Uma" <uma.ganguma...@intel.com>
Subject Re: [crypto][chimera] Next steps
Date Tue, 08 Mar 2016 01:20:21 GMT
Dear all, Sorry for the delay. Working out on the proposal document, we
will get it posted here soon.

Regards,
Uma


On 2/26/16, 1:26 PM, "Gary Gregory" <garydgregory@gmail.com> wrote:

>I take it the Crypto squared is a typo and that you wanted to close the
>quote.
>
>G
>
>On Fri, Feb 26, 2016 at 12:47 PM, Gangumalla, Uma
><uma.gangumalla@intel.com>
>wrote:
>
>>
>> Ok. Thanks Benedikt. We would get the proposal document ready soon.
>> Also one question, shall we rename the package to org.apache.* in
>>Chimera
>> git project first before pushing the code to Apache Commons? Or we can
>> work here once moved the code?
>> What do you suggest? For making package rename, component name should be
>> finalized I think.
>>
>> Does every one ok with "Apache Commons Crypto² ?
>>
>> Regards,
>> Uma
>>
>> On 2/26/16, 5:11 AM, "Benedikt Ritter" <britter@apache.org> wrote:
>>
>> >Okay, so I think the only thing missing before we start the
>>integration of
>> >the component is a PROPOSAL document, describing the scope of the
>> >component
>> >and a list of initial commiters/contributors.
>> >
>> >2016-02-26 3:24 GMT+01:00 Chen, Haifeng <haifeng.chen@intel.com>:
>> >
>> >> Come back to clear out the codebase and IP concerns.
>> >>
>> >> [Benedikt] I still have concerns about the IP, since this seems to
>>be an
>> >> Intel 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
>> >> Apache 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
>> >> original planned to use org.apache.chimera prefix. But we found that
>>we
>> >> couldnot publish org.apache. grouped artifacts to maven central
>> >>repository,
>> >> which 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
>> >> github as final.
>> >>
>> >> Thanks,
>> >> Haifeng
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Chen, Haifeng [mailto:haifeng.chen@intel.com]
>> >> 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
>> >> available.
>> >>
>> >> [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
>> >> community that comes with it / forms around it. A strong community
>>can
>> >>fix
>> >> code 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
>> >> (for 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
>> >> codebase. I do not have the necessary experience to say what would be
>> >>the
>> >> right way here. My gut feeling tells me, that we should go through
>>the
>> >> incubator. WDYT?
>> >> 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
>> >>
>> >>
>> >> 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
>> >> >>>or she  want's the see Chimera/crypto joining Apache Commons,
yet
>> >> >>>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
>> >> >>>Apache  Commons. Do we need a vote for that?
>> >> >>
>> >> >> Yes, of course.
>> >> >>
>> >> >> However that decision clearly depends on at least some of the
>>design
>> >> >> aspects of the code.
>> >> >> If it were written entirely in C or Fortran, it would not be a
>> >> >> suitable candidate.
>> >> >>
>> >> >>> 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.
>> >> >>
>> >> >> Some design details impact on the decision.
>> >> >>
>> >> >> Indeed even for pure Java code the code quality has a bearing on
>> >> >> whether Commons would/could want to take it.
>> >> >> Would we want a large code base with no unit-tests, no build
>> >> >> mechanism, and no comments?
>> >> >
>> >> >It depends. I care less about the quality of the code than I do
>>about
>> >> >the community that comes with it / forms around it. A strong
>>community
>> >> >can fix code issues. Great code can't save a weak community.
>> >> >
>> >> >How about creating a new sandbox component, let folks start work and
>> >> >see how the community develops?
>> >> >
>> >> >Mark
>> >> >
>> >> >
>> >> >>
>> >> >>> 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
>> >> >>>> Hadoop and/or Spark, to prevent version skew problems between
>> >> >>>> Hadoop and Spark like we have had in the past.
>> >> >>>>
>> >> >>>> What is the strategy for handling JNI components?  I think
at a
>> >> >>>> minimum, we should include the version number in the native
>>library
>> >> >>>> name to avoid problems when deploying multiple versions
of
>>Chimera.
>> >> >>>> This is something that has been problematic in Hadoop with
>> >> >>>> libhadoop.so.
>> >> >>>>
>> >> >>>> Is this library going to have Scala interfaces as well
as Java
>> >> >>>> ones, or just Java?
>> >> >>>>
>> >> >>>> cheers,
>> >> >>>> Colin
>> >> >>>>
>> >> >>>> On Sat, Feb 20, 2016 at 3:15 AM, Benedikt Ritter
>> >> >>>> <britter@apache.org>
>> >> >>>> wrote:
>> >> >>>>> Hi,
>> >> >>>>>
>> >> >>>>> I'd like to discuss the next steps for moving the Chimera
>> >> >>>>>component to  Apache Commons. So far, none of the other
PMC
>>members
>> >> >>>>>has expressed his
>> >> >>>> or
>> >> >>>>> her thoughts about this. If nobody brings up objections
about
>> >> >>>>>moving the  component to Apache Commons, I'm assuming
lazy
>> >> >>>>>consensus about this.
>> >> >>>>>
>> >> >>>>> So the next steps would be:
>> >> >>>>> - decide on a name for the new component (my proposal
was
>>Apache
>> >> >>>>>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
>> >> >>
>> >> >> 
>>---------------------------------------------------------------------
>> >> >> 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
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>-- 
>E-Mail: garydgregory@gmail.com | ggregory@apache.org
>Java Persistence with Hibernate, Second Edition
><http://www.manning.com/bauer3/>
>JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>Spring Batch in Action <http://www.manning.com/templier/>
>Blog: http://garygregory.wordpress.com
>Home: http://garygregory.com/
>Tweet! http://twitter.com/GaryGregory


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