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.ganguma...@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" <brit...@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.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 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@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
