commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [crypto][chimera] Next steps
Date Fri, 26 Feb 2016 21:26:24 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message