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.c...@intel.com] Sent: Wednesday, February 24, 2016 12:40 PM To: Commons Developers List <d...@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.ganguma...@intel.com] Sent: Wednesday, February 24, 2016 5:13 AM To: Commons Developers List <d...@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" <ma...@apache.org> wrote: >On 23/02/2016 09:12, sebb wrote: >> On 23 February 2016 at 07:34, Benedikt Ritter <brit...@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...@intel.com>: >>> >>>> At this point, it has just Java interfaces only. >>>> >>>> -----Original Message----- >>>> From: Colin P. McCabe [mailto:cmcc...@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 >>>> <brit...@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-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >>> >>> -- >>> http://home.apache.org/~britter/ >>> http://twitter.com/BenediktRitter >>> http://github.com/britter >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
