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.c...@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.c...@intel.com] > Sent: Wednesday, February 24, 2016 12:40 PM > To: Commons Developers List <dev@commons.apache.org> > Cc: common-...@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 <dev@commons.apache.org> > Cc: common-...@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 > > > --------------------------------------------------------------------- > 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
