Re: First draft of slides for ApacheCon
Hi Benson, if you need a keynote slide looking like the image here: http://incubator.apache.org/incubation/Process_Description.html pls let me know. I gladly send it to you. Cheers Christian On Sat, Feb 16, 2013 at 7:54 PM, Benson Margulies wrote: > https://docs.google.com/presentation/d/1XSqXy9rz-RDcE-P2cK7dEmyjGGHvK8--mR4k_E-qAL4/edit?usp=sharing > > I've made my first pass at the slides for the talk I'm giving on the > incubator in Portland. > > If anyone is really allergic to Google Docs, I can export it and put > it somewhere otherwise accessible. > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: First draft of slides for ApacheCon
Hi Benson, Looking really good! You may consider adding a flow chart/diagram showing the Incubator process but other than that, I don't have any suggestions. Wonderful! Cheers, Chris On 2/16/13 10:54 AM, "Benson Margulies" wrote: >https://docs.google.com/presentation/d/1XSqXy9rz-RDcE-P2cK7dEmyjGGHvK8--mR >4k_E-qAL4/edit?usp=sharing > >I've made my first pass at the slides for the talk I'm giving on the >incubator in Portland. > >If anyone is really allergic to Google Docs, I can export it and put >it somewhere otherwise accessible. > >- >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: First draft of slides for ApacheCon
Ross, thanks. All of these are useful. The first one I'll just take your suggestions as is, for the others I need to think a bit about how to capture your nuance. On Sat, Feb 16, 2013 at 3:08 PM, Ross Gardler wrote: > Great slides. A few comments for you to take on board or ignore at your > pleasure (they are opinion not fact so you may not agree)... > > Slide 5: personally I avoid 'viral' and still k to 'reciprocal' no need to > further alienate those who have a preference for reciprocal licences (I.e > use passive rather than aggressive language). By the same token I'd say > "not only about" as opposed to "not about". Personally I prefer things to > be free, but I'm pragmatic and recognise that sometimes freedom will need > to be compromised. Our licence is ideal for this, it provides choice and > uses economics to drive freedom. right. > > Slide 9: I guess it depends on how you deliver this slide whether I agree > or not. The foundation will provide any "exotic" infrastructure that can be > justified. I remember telling a podling they couldn't have Git, for > example. I immediately went to infra and with the support of Jukka we got > permission for that podling to be the first one to adopt Git. Perhaps just > add the word "unjustified", it's. Less final. Right. I'm trying to convey 'don't show up and expect Infra to roll over and deliver all kinds of new stuff just because you ask for it.' It's not so much a question of 'justification' as process and economy of scale. I'm sure I'll some up with something. > > Slide 19: To graduate a project must demonstrate the ability to grow, not > necessarily to have grown. Therefore I think this slide is too absolute in > its "grow or retire" message. Got it. > > This looks great, the above points are all minor and you should feel free > to ignore or adapt as you see fit. > > Ross > > Sent from a mobile device, please excuse mistakes and brevity > On 16 Feb 2013 18:55, "Benson Margulies" wrote: > >> >> https://docs.google.com/presentation/d/1XSqXy9rz-RDcE-P2cK7dEmyjGGHvK8--mR4k_E-qAL4/edit?usp=sharing >> >> I've made my first pass at the slides for the talk I'm giving on the >> incubator in Portland. >> >> If anyone is really allergic to Google Docs, I can export it and put >> it somewhere otherwise accessible. >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: First draft of slides for ApacheCon
Great slides. A few comments for you to take on board or ignore at your pleasure (they are opinion not fact so you may not agree)... Slide 5: personally I avoid 'viral' and still k to 'reciprocal' no need to further alienate those who have a preference for reciprocal licences (I.e use passive rather than aggressive language). By the same token I'd say "not only about" as opposed to "not about". Personally I prefer things to be free, but I'm pragmatic and recognise that sometimes freedom will need to be compromised. Our licence is ideal for this, it provides choice and uses economics to drive freedom. Slide 9: I guess it depends on how you deliver this slide whether I agree or not. The foundation will provide any "exotic" infrastructure that can be justified. I remember telling a podling they couldn't have Git, for example. I immediately went to infra and with the support of Jukka we got permission for that podling to be the first one to adopt Git. Perhaps just add the word "unjustified", it's. Less final. Slide 19: To graduate a project must demonstrate the ability to grow, not necessarily to have grown. Therefore I think this slide is too absolute in its "grow or retire" message. This looks great, the above points are all minor and you should feel free to ignore or adapt as you see fit. Ross Sent from a mobile device, please excuse mistakes and brevity On 16 Feb 2013 18:55, "Benson Margulies" wrote: > > https://docs.google.com/presentation/d/1XSqXy9rz-RDcE-P2cK7dEmyjGGHvK8--mR4k_E-qAL4/edit?usp=sharing > > I've made my first pass at the slides for the talk I'm giving on the > incubator in Portland. > > If anyone is really allergic to Google Docs, I can export it and put > it somewhere otherwise accessible. > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: First draft of slides for ApacheCon
For gathering wide area comments, gdocs rule. On Sat, Feb 16, 2013 at 11:54 AM, Benson Margulies wrote: > > https://docs.google.com/presentation/d/1XSqXy9rz-RDcE-P2cK7dEmyjGGHvK8--mR4k_E-qAL4/edit?usp=sharing > > I've made my first pass at the slides for the talk I'm giving on the > incubator in Portland. > > If anyone is really allergic to Google Docs, I can export it and put > it somewhere otherwise accessible. > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Accept Apache Knox Hadoop Gateway Project into the Incubator
+1. Alan. On Feb 15, 2013, at 5:03 PM, Owen O'Malley wrote: > +1 > > > On Fri, Feb 15, 2013 at 11:22 AM, Devaraj Das wrote: > >> Hi Folks, >> >> Thanks for participating in the discussion. I'd like to call a VOTE >> for acceptance of Apache Knox Hadoop Gateway Project into the >> Incubator. The vote will close on Feb 22 at 6:00 p.m. >> >> [ ] +1 Accept Apache Knox Hadoop Gateway Project into the Incubator >> [ ] +0 Don't care. >> [ ] -1 Don't accept Apache Knox Hadoop Gateway Project into the >> Incubator because... >> >> Full proposal is pasted at the bottom of this email, and the >> corresponding wiki is http://wiki.apache.org/incubator/knox. Only >> VOTEs from Incubator PMC members are binding. >> >> Here's my +1 (binding). >> >> Thanks, >> Devaraj. >> >> - >> >> Knox Gateway Proposal >> >> Abstract >> >> Knox Gateway is a system that provides a single point of secure access >> for Apache Hadoop clusters. >> >> Proposal >> >> The Knox Gateway (“Gateway” or “Knox”) is a system that provides a >> single point of authentication and access for Apache Hadoop services >> in a cluster. The goal is to simplify Hadoop security for both users >> (i.e. who access the cluster data and execute jobs) and operators >> (i.e. who control access and manage the cluster). The Gateway runs as >> a server (or cluster of servers) that serve one or more Hadoop >> clusters. >> >> Provide perimeter security to make Hadoop security setup easier >> Support authentication and token verification security scenarios >> Deliver users a single cluster end-point that aggregates capabilities >> for data and jobs >> Enable integration with enterprise and cloud identity management >> environments >> >> Background >> >> An Apache Hadoop cluster is presented to consumers as a loose >> collection of independent services. This makes it difficult for users >> to interact with Hadoop since each service maintains it’s own method >> of access and security. As well, for operators, configuration and >> administration of a secure Hadoop cluster is a complex and many Hadoop >> clusters are insecure as a result. >> >> The goal of the project is to provide coverage for all existing Hadoop >> ecosystem projects. In addition, the project will be extensible to >> allow for new and/or proprietary Hadoop components without requiring >> changes to the gateway source code. The gateway is expected to run in >> a DMZ environment where it will provide controlled access to these >> Hadoop services. In this way Hadoop clusters can be protected by a >> firewall and only limited access provided through the firewall for the >> gateway. The authentication components of the gateway will be modular >> and extensible such that it can be integrated with existing security >> infrastructure. >> >> Rationale >> >> Organizations that are struggling with Hadoop cluster security result >> in a) running Hadoop without security or b) slowing adoption of >> Hadoop. The Gateway aims to provide perimeter security that integrates >> more easily into existing organizations’ security infrastructure. >> Doing so will simplify security for these organizations and benefit >> all Hadoop stakeholders (i.e. users and operators). Additionally, >> making a dedicated perimeter security project part of the Apache >> Hadoop ecosystem will prevent fragmentation in this area and further >> increase the value of Hadoop as a data platform. >> >> Current Status >> >> Prototype available, developed by the list of initial committers. >> >> Meritocracy >> >> We desire to build a diverse developer community around Gateway >> following the Apache Way. We want to make the project open source and >> will encourage contributors from multiple organizations following the >> Apache meritocracy model. >> >> Community >> >> We hope to extend the user and developer base in the future and build >> a solid open source community around Gateway. Apache Hadoop has a >> large ecosystem of open source projects, each with a strong community >> of contributors. All project communities in this ecosystem have an >> opportunity to participate in the advancement of the Gateway project >> because ultimately, Gateway will enable the security capabilities of >> their project to be more enterprise friendly. >> >> Core Developers >> >> Gateway is currently being developed by several engineers from >> Hortonworks - Kevin Minder, Larry McCay, John Speidel, Tom Beerbower >> and Sumit Mohanty. All the engineers have deep expertise in >> middleware, security & identity systems and are quite familiar with >> the Hadoop ecosystem. >> >> Alignment >> >> The ASF is a natural host for Gateway given that it is already the >> home of Hadoop, Hive, Pig, HBase, Oozie and other emerging big data >> software projects. Gateway is designed to solve the security >> challenges familiar to the Hadoop ecosystem family of projects. >> >> Known Risks >> >> Orphaned products & Reliance on Salaried Develop
First draft of slides for ApacheCon
https://docs.google.com/presentation/d/1XSqXy9rz-RDcE-P2cK7dEmyjGGHvK8--mR4k_E-qAL4/edit?usp=sharing I've made my first pass at the slides for the talk I'm giving on the incubator in Portland. If anyone is really allergic to Google Docs, I can export it and put it somewhere otherwise accessible. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT] [VOTE] Accept Apache Open Climate Workbench into the Incubator
+1 (binding) On Thu, Feb 14, 2013 at 9:06 PM, Mattmann, Chris A (388J) < chris.a.mattm...@jpl.nasa.gov> wrote: > Hi Everyone, > > This VOTE has passed with the following tallies: > > +1 > > Chris Mattmann* > Andrew Hart* > Daniel Gruno > Paul Ramirez* > Gary Martin > Ross Gardler* > Ted Dunning* > Alexei Fedotov > Dave Fisher* > Suresh Marru* > Tommaso Teofili* > Andrea Pescetti > Chris Douglas* > Emmanuel Lécharny* > Tsengdar Lee > > * - indicates IPMC > > I'll get started creating the infrastructure tickets, and thanks to > everyone for VOTE'ing! > > Cheers, > Chris > > > On 2/5/13 8:18 AM, "Mattmann, Chris A (388J)" > wrote: > > >Hi Folks, > > > >OK, now that discussion has settled down, I'd like to call a VOTE for > >acceptance of Apache Open Climate Workbench into the Incubator. > >I'll leave the VOTE open the rest of the week and close it out next > >Monday, February 11th early am PT. > > > >[ ] +1 Accept Apache Open Climate Workbench into the Incubator > >[ ] +0 Don't care. > >[ ] -1 Don't accept Apache Open Climate Workbench into the Incubator > >because... > > > >Full proposal is pasted at the bottom of this email. Only VOTEs from > >Incubator PMC members are binding, but all are welcome to express their > >thoughts. > > > >Thank you! > > > >Cheers, > >Chris > > > >P.S. Here's my +1 (binding) > > > >- > >= Apache Open Climate Workbench, tool for scalable comparison of remote > >sensing observations to climate model outputs, regionally and globally. = > >=== Abstract === > >The Apache Open Climate Workbench proposal desires to contribute an > >existing community of software related to the analysis and evaluation of > >climate models, and related to the use of remote sensing data in that > >process. > > > >Specifically, we will bring a fundamental software toolkit for analysis > >and evaluation of climate model output against remote sensing data. The > >toolkit is called the [[http://rcmes.jpl.nasa.gov|Regional Climate Model > >Evaluation System (RCMES)]]. RCMES provides two fundamental components for > >the easy, intuitive comparison of climate model output against remote > >sensing data. The first component called RCMED (for "Regional Climate > >Model Evaluation Database") is a scalable cloud database that decimates > >remote sensing data and renalysis data related to climate using Apache > >OODT extractors, Apache Tika, etc. These transformations make > >traditionally heterogeneous upstream remote sensing data and climate model > >output homogeneous and unify them into a data point model of the form > >(lat, lng, time, value, height) on a per parameter basis. Latitude (lat) > >and Longitude (lng) are in WGS84 format, but can be reformatted on the > >fly. time is in ISO 8601 format, a string sortable format independent of > >underlying store. value carries with it units, related to interpretation > >and height allows for different values for different atmospheric vertical > >levels. All of RCMES is built on Apache OODT, Apache Sqoop/Apache Hadoop > >and Apache Hive, along with hooks to PostGIS and MySQL (traditional > >relational databases). The second component of the system, RCMET (for > >"Regional Climate Model Evaluation Toolkit") provides facilities for > >connecting to RCMED, dynamically obtaining remote sensing data for a > >space/time region of interest, grabbing associated model output (that the > >user brings, or from the Earth System Grid Federation) of the same form, > >and then regridding the remote sensing data to be on the model output > >grid, or the model output to be on the remote sensing data grid. The > >regridded data spatially is then temporally regridded using techniques > >including seasonal cycle compositing (e.g., all summer months, all > >Januaries, etc.), or by daily, monthly, etc. The uniform model output and > >remote sensing data are then analyzed using pluggable metrics, e.g., > >Probability Distribution Functions (PDFs), Root Mean Squared Error (RMSE), > >Bias, and other (possibly user-defined) techniques, computing an analyzed > >comparison or evaluation. This evaluation is then visualized by plugging > >in to the NCAR NCL library for producing static plots (histograms, time > >series, etc.) > > > >We also have performed a great deal of work in packaging RCMES to make the > >system easy to deploy. We have working Virtual Machines (VMWare VMX and > >Virtual Box OVA compatible formats) and we also have an installer built on > >Python Buildout (http://buildout.org/) called "Easy RCMET" for > dynamically > >constructing the RCMET toolkit. > > > >RCMES is currently supporting a number of recognized climate projects of > >(inter-)national significance. In particular, RCMES is supporting the > >[[http://www.globalchange.gov/what-we-do/assessment|U.S. National Climate > >Assessment (NCA) activities]] on behalf of NASA's contribution to the NCA; > >is working with the [[http://www.narccap.ucar.edu/|North American > Regional > >Climate Change Assessment P
Re: [VOTE] Accept Apache Knox Hadoop Gateway Project into the Incubator
+1 (binding) On Sat, Feb 16, 2013 at 4:08 AM, Arun C Murthy wrote: > +1 (binding) > > Arun > > On Feb 14, 2013, at 5:26 PM, Devaraj Das wrote: > > > Hi Folks, > > > > Thanks for participating in the discussion. I'd like to call a VOTE > > for acceptance of Apache Knox Hadoop Gateway Project into the > > Incubator. The vote will close on Feb 21 at 6:00 p.m. > > > > [ ] +1 Accept Apache Open Climate Workbench into the Incubator > > [ ] +0 Don't care. > > [ ] -1 Don't accept Apache Open Climate Workbench into the Incubator > because... > > > > Full proposal is pasted at the bottom of this email, and the > > corresponding wiki is http://wiki.apache.org/incubator/knox. Only > > VOTEs from Incubator PMC members are binding. > > > > Here's my +1 (binding). > > > > Thanks, > > Devaraj. > > > > p.s. In the last day, Tom White has been added as a mentor, and > > Venkatesh Seetharam has been added in the list of initial committers. > > > > > > Knox Gateway Proposal > > > > Abstract > > > > Knox Gateway is a system that provides a single point of secure access > > for Apache Hadoop clusters. > > > > Proposal > > > > The Knox Gateway (“Gateway” or “Knox”) is a system that provides a > > single point of authentication and access for Apache Hadoop services > > in a cluster. The goal is to simplify Hadoop security for both users > > (i.e. who access the cluster data and execute jobs) and operators > > (i.e. who control access and manage the cluster). The Gateway runs as > > a server (or cluster of servers) that serve one or more Hadoop > > clusters. > > > > Provide perimeter security to make Hadoop security setup easier > > Support authentication and token verification security scenarios > > Deliver users a single cluster end-point that aggregates capabilities > > for data and jobs > > Enable integration with enterprise and cloud identity management > environments > > > > Background > > > > An Apache Hadoop cluster is presented to consumers as a loose > > collection of independent services. This makes it difficult for users > > to interact with Hadoop since each service maintains it’s own method > > of access and security. As well, for operators, configuration and > > administration of a secure Hadoop cluster is a complex and many Hadoop > > clusters are insecure as a result. > > > > The goal of the project is to provide coverage for all existing Hadoop > > ecosystem projects. In addition, the project will be extensible to > > allow for new and/or proprietary Hadoop components without requiring > > changes to the gateway source code. The gateway is expected to run in > > a DMZ environment where it will provide controlled access to these > > Hadoop services. In this way Hadoop clusters can be protected by a > > firewall and only limited access provided through the firewall for the > > gateway. The authentication components of the gateway will be modular > > and extensible such that it can be integrated with existing security > > infrastructure. > > > > Rationale > > > > Organizations that are struggling with Hadoop cluster security result > > in a) running Hadoop without security or b) slowing adoption of > > Hadoop. The Gateway aims to provide perimeter security that integrates > > more easily into existing organizations’ security infrastructure. > > Doing so will simplify security for these organizations and benefit > > all Hadoop stakeholders (i.e. users and operators). Additionally, > > making a dedicated perimeter security project part of the Apache > > Hadoop ecosystem will prevent fragmentation in this area and further > > increase the value of Hadoop as a data platform. > > > > Current Status > > > > Prototype available, developed by the list of initial committers. > > > > Meritocracy > > > > We desire to build a diverse developer community around Gateway > > following the Apache Way. We want to make the project open source and > > will encourage contributors from multiple organizations following the > > Apache meritocracy model. > > > > Community > > > > We hope to extend the user and developer base in the future and build > > a solid open source community around Gateway. Apache Hadoop has a > > large ecosystem of open source projects, each with a strong community > > of contributors. All project communities in this ecosystem have an > > opportunity to participate in the advancement of the Gateway project > > because ultimately, Gateway will enable the security capabilities of > > their project to be more enterprise friendly. > > > > Core Developers > > > > Gateway is currently being developed by several engineers from > > Hortonworks - Kevin Minder, Larry McCay, John Speidel, Tom Beerbower > > and Sumit Mohanty. All the engineers have deep expertise in > > middleware, security & identity systems and are quite familiar with > > the Hadoop ecosystem. > > > > Alignment > > > > The ASF is a natural host for Gateway given that it is already the > > home of Hadoop, Hive, Pig, HBase, Oozie and other emer
