Re: [DISCUSS] [VOTE] HCatalog to Graduate and become part of Apache Hive
Thanks for the clarification, Roy. Cheers, Chris P.S. Almost want them to change to lazy consensus, bc you laying smack down is full of win. On 2/14/13 11:38 AM, "Roy T. Fielding" wrote: >It is a majority decision. In theory, the PMC could decide to >create special bylaws that would change that to a lazy consensus >decision, but then I would have to lay the smack down about why >it is that the US government sucks because supermajorities are >designed to deny proper governance. > >In the absence of specific rules (like our lazy consensus rule >on code change voting), you can assume that lazy majority decisions >are the way that decisions are made at Apache (like releases). > >Roy > >On Feb 14, 2013, at 9:58 AM, Mattmann, Chris A (388J) wrote: > >> Hey Alan, >> >> Great point -- thanks for highlighting the concern, and yes, Benson, I'd >> like the Incubator PMC to request this clarification from the board. >>BTW, >> not frustrated with you guys at all and wish you the best. Just trying >>to >> help (even if it didn't seem like it) based on my existing experience >>with >> several of Apache's largest umbrella projects :/ >> >> Cheers, >> Chris >> >> On 2/14/13 8:31 AM, "Alan Gates" wrote: >> >>> I'd like second and extend Benson's point about clarifying how these >>> things should work. In addition to clarifying what it means to >>>graduate >>> into a subproject now that that is frowned upon, clarifying how these >>> votes work would help. I think Chris felt that we ignored his vote and >>> pushed ahead. From my reading of the docs it was supposed to be a >>> majority vote and thus to view the -1s as a veto would be to improperly >>> ignore the 5 +1s. If the rules were clear in advance for the next >>>group >>> that faces this situation it will help to avoid these misunderstandings >>> and frustrations. >>> >>> Alan. >>> >>> On Feb 14, 2013, at 3:29 AM, Benson Margulies wrote: >>> I'm not so much opinionated as confused here, perhaps because I have a very linear view of governance. I like to know how a vote fits into a governance structure or process, and I've felt for some time that this case (podling goes to existing TLP) is not well-explained by our structure. Back in the days when subprojects were normal and valid, the incubator had a role on behalf of' an existing TLP in supervising IP and community behavior. Graduation meant: "OK, umbrella, we certify that these people can behave like a project and have clean IP." And, perhaps, the board actually established subprojects? It's all before my time. Now that subprojects are no longer in the picture, I don't even know why the IPMC should ever incubate a podling *if the plan, from the start, is to be part of some existing TLP.* So I have assumed that HCatalog started out with the intention to grow into an entire TLP, and came up with the Hive plan as a fallback. To try to make this long story shorter, I think that we should make a proposal to the board with a schema for handling this case that makes sense in current conditions. I'm happy for it to be your schema, which amounts, as I see it, to the board having a supervisory moment when this happens, with an IPMC vote providing the same sort of strong recommendation one way or the other that it does for establishing a TLP. On Thu, Feb 14, 2013 at 12:49 AM, Mattmann, Chris A (388J) wrote: > Hi Benson, > > I saw your later email(s) and Incubator board report. It's fine and I > think the message of my objection comes across. > So thanks for that. > > One thing I wanted to comment on: > > On 2/13/13 4:10 AM, "Benson Margulies" wrote: > >> Chris, >> >> The obvious compromise is to ask them to report the vote result as >>it >> happened, it seems to me, -1's and all. But where do you think that >> they are reporting anything? There's nothing happening here at the >> board level. There's no board resolution needed for a Hive committer >> to type 'svn cp' on the hcatalog tree, > > Not by my counts. There's a *community* resolution and a > recommendation to > be made by the IPMC, nonetheless. > Otherwise, the IPMC is pretty useless IMO, and more importantly, so >is > the > Incubator. > > Why bother even incubating HCatalog? Hive could have simply svn cp'ed > whatever code came in, or whatever code the podling arrived at, and > Incubation would have stopped then. But we both know that's not the > way it > works. Even if a podling graduates to an existing TLP, go check out >the > past resolutions. You'll note there's a section in there that > discharges > the responsibility of the IPMC for the podling. So, yes, the IPMC >*is* > involved. And yes, the IPMC vote matter
[RESULT] [VOTE] Accept Apache Open Climate Workbench into the Incubator
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 Program (NARCCAP)]]; and is also working with >the International [[http://wcrp-cordex.ipsl.jussieu.fr/|Coordinated >Regional Downscaling Experiment (CORDEX)]]. > >=== Proposal === >We propose to transition the RCMES software community, which includes >developers of the RCMET and RCMED software, along with users of RCMES in >the CORDE
Re: [VOTE] Apache cTAKES 3.0.0-incubating RC7 release
Hi Guys, +1 from me. SIGS pass: [chipotle:~/tmp/apache-ctakes-3.0.0-incubating-rc7] mattmann% $HOME/bin/verify_gpg_sigs Verifying Signature for file apache-ctakes-3.0.0-incubating-src.tar.gz.asc gpg: Signature made Wed Feb 6 14:06:28 2013 PST using RSA key ID D218BB0A gpg: Good signature from "Pei Chen (CODE SIGNING KEY2) " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: FECC 654C 4AC3 5DEC 0027 2792 F97C 492F D218 BB0A [chipotle:~/tmp/apache-ctakes-3.0.0-incubating-rc7] mattmann% CHECKSUMS pass: [chipotle:~/tmp/apache-ctakes-3.0.0-incubating-rc7] mattmann% verify_md5_checksums md5sum: stat '*.bz2': No such file or directory md5sum: stat '*.zip': No such file or directory apache-ctakes-3.0.0-incubating-src.tar.gz: OK [chipotle:~/tmp/apache-ctakes-3.0.0-incubating-rc7] mattmann% Cheers, Chris On 2/11/13 9:03 AM, "Chen, Pei" wrote: >Hi, > >This is a call for a vote on releasing the following candidate as Apache >cTAKES 3.0.0-incubating. This will be our first release. >Thanks for all of your comments from the previous candidate. Based on >the feedback and discussions, we removed the binary models from the >source and binary distributions in this release candidate. > >The vote for this RC on ctakes-dev@ is not concluded yet but earlier ones >were and this is nearly simultaneous: >http://mail-archives.apache.org/mod_mbox/incubator-ctakes-dev/201302.mbox/ >browser > >For more detailed information on the changes/release notes, please visit: >https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313621&; >version=12322969 > >The release was made using the cTAKES release process documented here: >http://incubator.apache.org/ctakes/ctakes-release-guide.html > >The candidate is available at: >http://people.apache.org/~chenpei/ctakes-3.0.0-incubating/rc7/target/apach >e-ctakes-3.0.0-incubating-src.tar.gz /.zip > >The binary is: >http://people.apache.org/~chenpei/ctakes-3.0.0-incubating/rc7/target/apach >e-ctakes-3.0.0-incubating-bin.tar.gz /.zip > >The tag to be voted on: >http://svn.apache.org/repos/asf/incubator/ctakes/tags/ctakes-3.0.0-incubat >ing-rc7/ > >The MD5 checksum of the tarball can be found at: >http://people.apache.org/~chenpei/ctakes-3.0.0-incubating/rc7/target/apach >e-ctakes-3.0.0-incubating-bin.tar.gz.md5 /.zip.md5 > >The signature of the tarball can be found at: >http://people.apache.org/~chenpei/ctakes-3.0.0-incubating/rc7/target/apach >e-ctakes-3.0.0-incubating-bin.tar.gz.asc /.zip.asc > >Apache cTAKES' KEYS file, containing the PGP keys used to sign the >release: >http://svn.apache.org/repos/asf/incubator/ctakes/tags/ctakes-3.0.0-incubat >ing-rc7/KEYS > >Please vote on releasing these packages as Apache cTAKES >3.0.0-incubating. The vote is open for at least the next 72 hours. >Only votes from Incubator PMC are binding, but folks are welcome to check >the release candidate and voice their approval or disapproval. The vote >passes if at least three binding +1 votes are cast. > >[ ] +1 Release the packages as Apache cTAKES 3.0.0-incubating >[ ] -1 Do not release the packages because... >Thanks! >Pei >P.S. Here is my +1. > >- >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: [VOTE] Accept Apache Knox Hadoop Gateway Project into the Incubator
s/Apache Open Climate Workbench/Apache Knox Hadoop Gateway/ :) May want to resend the [VOTE] thread. On 2/14/13 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 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 Developers > >The core developers plan to work full time on the project. We believe >that this project will be
[VOTE] Accept Apache Knox Hadoop Gateway Project into the Incubator
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 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 Developers The core developers plan to work full time on the project. We believe that this project will be of general interest to many Hadoop users and will attract a diverse set of contributors. We intend to demonstrate this by having contributors from several organizations recognized as committers by the time Knox graduates from incubation. Inexperience with Open Source
Re: [DISCUSS] [VOTE] HCatalog to Graduate and become part of Apache Hive
It is a majority decision. In theory, the PMC could decide to create special bylaws that would change that to a lazy consensus decision, but then I would have to lay the smack down about why it is that the US government sucks because supermajorities are designed to deny proper governance. In the absence of specific rules (like our lazy consensus rule on code change voting), you can assume that lazy majority decisions are the way that decisions are made at Apache (like releases). Roy On Feb 14, 2013, at 9:58 AM, Mattmann, Chris A (388J) wrote: > Hey Alan, > > Great point -- thanks for highlighting the concern, and yes, Benson, I'd > like the Incubator PMC to request this clarification from the board. BTW, > not frustrated with you guys at all and wish you the best. Just trying to > help (even if it didn't seem like it) based on my existing experience with > several of Apache's largest umbrella projects :/ > > Cheers, > Chris > > On 2/14/13 8:31 AM, "Alan Gates" wrote: > >> I'd like second and extend Benson's point about clarifying how these >> things should work. In addition to clarifying what it means to graduate >> into a subproject now that that is frowned upon, clarifying how these >> votes work would help. I think Chris felt that we ignored his vote and >> pushed ahead. From my reading of the docs it was supposed to be a >> majority vote and thus to view the -1s as a veto would be to improperly >> ignore the 5 +1s. If the rules were clear in advance for the next group >> that faces this situation it will help to avoid these misunderstandings >> and frustrations. >> >> Alan. >> >> On Feb 14, 2013, at 3:29 AM, Benson Margulies wrote: >> >>> I'm not so much opinionated as confused here, perhaps because I have a >>> very linear view of governance. >>> >>> I like to know how a vote fits into a governance structure or process, >>> and I've felt for some time that this case (podling goes to existing >>> TLP) is not well-explained by our structure. >>> >>> Back in the days when subprojects were normal and valid, the incubator >>> had a role on behalf of' an existing TLP in supervising IP and >>> community behavior. Graduation meant: "OK, umbrella, we certify that >>> these people can behave like a project and have clean IP." And, >>> perhaps, the board actually established subprojects? It's all before >>> my time. >>> >>> Now that subprojects are no longer in the picture, I don't even know >>> why the IPMC should ever incubate a podling *if the plan, from the >>> start, is to be part of some existing TLP.* So I have assumed that >>> HCatalog started out with the intention to grow into an entire TLP, >>> and came up with the Hive plan as a fallback. >>> >>> To try to make this long story shorter, I think that we should make a >>> proposal to the board with a schema for handling this case that makes >>> sense in current conditions. I'm happy for it to be your schema, which >>> amounts, as I see it, to the board having a supervisory moment when >>> this happens, with an IPMC vote providing the same sort of strong >>> recommendation one way or the other that it does for establishing a >>> TLP. >>> >>> >>> >>> >>> >>> On Thu, Feb 14, 2013 at 12:49 AM, Mattmann, Chris A (388J) >>> wrote: Hi Benson, I saw your later email(s) and Incubator board report. It's fine and I think the message of my objection comes across. So thanks for that. One thing I wanted to comment on: On 2/13/13 4:10 AM, "Benson Margulies" wrote: > Chris, > > The obvious compromise is to ask them to report the vote result as it > happened, it seems to me, -1's and all. But where do you think that > they are reporting anything? There's nothing happening here at the > board level. There's no board resolution needed for a Hive committer > to type 'svn cp' on the hcatalog tree, Not by my counts. There's a *community* resolution and a recommendation to be made by the IPMC, nonetheless. Otherwise, the IPMC is pretty useless IMO, and more importantly, so is the Incubator. Why bother even incubating HCatalog? Hive could have simply svn cp'ed whatever code came in, or whatever code the podling arrived at, and Incubation would have stopped then. But we both know that's not the way it works. Even if a podling graduates to an existing TLP, go check out the past resolutions. You'll note there's a section in there that discharges the responsibility of the IPMC for the podling. So, yes, the IPMC *is* involved. And yes, the IPMC vote matters. Cheers, Chris - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org >>> >>> -
Re: [DISCUSS] [VOTE] HCatalog to Graduate and become part of Apache Hive
Hey Alan, Great point -- thanks for highlighting the concern, and yes, Benson, I'd like the Incubator PMC to request this clarification from the board. BTW, not frustrated with you guys at all and wish you the best. Just trying to help (even if it didn't seem like it) based on my existing experience with several of Apache's largest umbrella projects :/ Cheers, Chris On 2/14/13 8:31 AM, "Alan Gates" wrote: >I'd like second and extend Benson's point about clarifying how these >things should work. In addition to clarifying what it means to graduate >into a subproject now that that is frowned upon, clarifying how these >votes work would help. I think Chris felt that we ignored his vote and >pushed ahead. From my reading of the docs it was supposed to be a >majority vote and thus to view the -1s as a veto would be to improperly >ignore the 5 +1s. If the rules were clear in advance for the next group >that faces this situation it will help to avoid these misunderstandings >and frustrations. > >Alan. > >On Feb 14, 2013, at 3:29 AM, Benson Margulies wrote: > >> I'm not so much opinionated as confused here, perhaps because I have a >> very linear view of governance. >> >> I like to know how a vote fits into a governance structure or process, >> and I've felt for some time that this case (podling goes to existing >> TLP) is not well-explained by our structure. >> >> Back in the days when subprojects were normal and valid, the incubator >> had a role on behalf of' an existing TLP in supervising IP and >> community behavior. Graduation meant: "OK, umbrella, we certify that >> these people can behave like a project and have clean IP." And, >> perhaps, the board actually established subprojects? It's all before >> my time. >> >> Now that subprojects are no longer in the picture, I don't even know >> why the IPMC should ever incubate a podling *if the plan, from the >> start, is to be part of some existing TLP.* So I have assumed that >> HCatalog started out with the intention to grow into an entire TLP, >> and came up with the Hive plan as a fallback. >> >> To try to make this long story shorter, I think that we should make a >> proposal to the board with a schema for handling this case that makes >> sense in current conditions. I'm happy for it to be your schema, which >> amounts, as I see it, to the board having a supervisory moment when >> this happens, with an IPMC vote providing the same sort of strong >> recommendation one way or the other that it does for establishing a >> TLP. >> >> >> >> >> >> On Thu, Feb 14, 2013 at 12:49 AM, Mattmann, Chris A (388J) >> wrote: >>> Hi Benson, >>> >>> I saw your later email(s) and Incubator board report. It's fine and I >>> think the message of my objection comes across. >>> So thanks for that. >>> >>> One thing I wanted to comment on: >>> >>> On 2/13/13 4:10 AM, "Benson Margulies" wrote: >>> Chris, The obvious compromise is to ask them to report the vote result as it happened, it seems to me, -1's and all. But where do you think that they are reporting anything? There's nothing happening here at the board level. There's no board resolution needed for a Hive committer to type 'svn cp' on the hcatalog tree, >>> >>> Not by my counts. There's a *community* resolution and a >>>recommendation to >>> be made by the IPMC, nonetheless. >>> Otherwise, the IPMC is pretty useless IMO, and more importantly, so is >>>the >>> Incubator. >>> >>> Why bother even incubating HCatalog? Hive could have simply svn cp'ed >>> whatever code came in, or whatever code the podling arrived at, and >>> Incubation would have stopped then. But we both know that's not the >>>way it >>> works. Even if a podling graduates to an existing TLP, go check out the >>> past resolutions. You'll note there's a section in there that >>>discharges >>> the responsibility of the IPMC for the podling. So, yes, the IPMC *is* >>> involved. And yes, the IPMC vote matters. >>> >>> Cheers, >>> Chris >>> >>> >>> - >>> 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 >> > > >- >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: [DISCUSS] [VOTE] HCatalog to Graduate and become part of Apache Hive
I'd like second and extend Benson's point about clarifying how these things should work. In addition to clarifying what it means to graduate into a subproject now that that is frowned upon, clarifying how these votes work would help. I think Chris felt that we ignored his vote and pushed ahead. From my reading of the docs it was supposed to be a majority vote and thus to view the -1s as a veto would be to improperly ignore the 5 +1s. If the rules were clear in advance for the next group that faces this situation it will help to avoid these misunderstandings and frustrations. Alan. On Feb 14, 2013, at 3:29 AM, Benson Margulies wrote: > I'm not so much opinionated as confused here, perhaps because I have a > very linear view of governance. > > I like to know how a vote fits into a governance structure or process, > and I've felt for some time that this case (podling goes to existing > TLP) is not well-explained by our structure. > > Back in the days when subprojects were normal and valid, the incubator > had a role on behalf of' an existing TLP in supervising IP and > community behavior. Graduation meant: "OK, umbrella, we certify that > these people can behave like a project and have clean IP." And, > perhaps, the board actually established subprojects? It's all before > my time. > > Now that subprojects are no longer in the picture, I don't even know > why the IPMC should ever incubate a podling *if the plan, from the > start, is to be part of some existing TLP.* So I have assumed that > HCatalog started out with the intention to grow into an entire TLP, > and came up with the Hive plan as a fallback. > > To try to make this long story shorter, I think that we should make a > proposal to the board with a schema for handling this case that makes > sense in current conditions. I'm happy for it to be your schema, which > amounts, as I see it, to the board having a supervisory moment when > this happens, with an IPMC vote providing the same sort of strong > recommendation one way or the other that it does for establishing a > TLP. > > > > > > On Thu, Feb 14, 2013 at 12:49 AM, Mattmann, Chris A (388J) > wrote: >> Hi Benson, >> >> I saw your later email(s) and Incubator board report. It's fine and I >> think the message of my objection comes across. >> So thanks for that. >> >> One thing I wanted to comment on: >> >> On 2/13/13 4:10 AM, "Benson Margulies" wrote: >> >>> Chris, >>> >>> The obvious compromise is to ask them to report the vote result as it >>> happened, it seems to me, -1's and all. But where do you think that >>> they are reporting anything? There's nothing happening here at the >>> board level. There's no board resolution needed for a Hive committer >>> to type 'svn cp' on the hcatalog tree, >> >> Not by my counts. There's a *community* resolution and a recommendation to >> be made by the IPMC, nonetheless. >> Otherwise, the IPMC is pretty useless IMO, and more importantly, so is the >> Incubator. >> >> Why bother even incubating HCatalog? Hive could have simply svn cp'ed >> whatever code came in, or whatever code the podling arrived at, and >> Incubation would have stopped then. But we both know that's not the way it >> works. Even if a podling graduates to an existing TLP, go check out the >> past resolutions. You'll note there's a section in there that discharges >> the responsibility of the IPMC for the podling. So, yes, the IPMC *is* >> involved. And yes, the IPMC vote matters. >> >> Cheers, >> Chris >> >> >> - >> 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 > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: pulse.apache.org down
Thanks Bertrand! Hopefully will be back one day :) just taking the chance to restate the utility of this service IMHO (overall for podlings :)) Regards Antonio On Feb 14, 2013, at 5:26 PM, Bertrand Delacretaz wrote: > Hi Antonio, > > On Thu, Feb 14, 2013 at 5:08 PM, Antonio Sanso wrote: >> ...this might seems a bit off topic here but I have noticed that >> http://pulse.apache.org/ is not working anymore >> (and when it was working it was out of date) > > That's a known issue, I have just created > https://issues.apache.org/jira/browse/INFRA-5861 to document it. > > -Bertrand > > - > 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: pulse.apache.org down
Hi Antonio, On Thu, Feb 14, 2013 at 5:08 PM, Antonio Sanso wrote: > ...this might seems a bit off topic here but I have noticed that > http://pulse.apache.org/ is not working anymore > (and when it was working it was out of date) That's a known issue, I have just created https://issues.apache.org/jira/browse/INFRA-5861 to document it. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
pulse.apache.org down
Hi *, this might seems a bit off topic here but I have noticed that http://pulse.apache.org/ is not working anymore (and when it was working it was out of date). The reason why I write this here (I will probably open some INFRA ticket as well) is because I believe this site was really useful for me when Apache Oltu (formerly Amber) was incubating to check the "popularity" of the project. I know that this can be achieved in other ways as well but this was the easiest. It would be nice to have it work again :) since IMHO (overall) podlings can benefit from it. Regards Antonio - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Report verbiage
Yups! :-) On Feb 14, 2013 6:11 AM, "Ross Gardler" wrote: > Absolutely, that's the right thing to do. I, and I believe Greg, were > answering Matt's question rather than you actions ;-) > > Sent from a mobile device, please excuse mistakes and brevity > On 14 Feb 2013 01:15, "Benson Margulies" wrote: > > > The chair here is trying to lure others into helping to characterize > > the overall state of things so as to avoid an overly one-sided view. > > > > > > On Wed, Feb 13, 2013 at 8:06 PM, Ross Gardler > > wrote: > > > +1 > > > > > > The incubator is a project like any other. Its report should > communicate > > > the health or otherwise of the projects community and should > communicate > > > any information. The board should know about and make any requests for > > > assistance from the board. > > > > > > Assuming the IPMC considers the Incubator to be in good shape the > actual > > > line by line podling reports are unimportant other than being the > outputs > > > of the incubator project. > > > > > > Sent from a mobile device, please excuse mistakes and brevity > > > On 13 Feb 2013 23:40, "Greg Stein" wrote: > > > > > >> On Feb 13, 2013 3:39 PM, "Matt Franklin" > > wrote: > > >> > > > >> > On Tue, Feb 12, 2013 at 11:45 AM, Benson Margulies > > >> > wrote: > > >> > > Does anyone feel inclined to communicate anything to the board > > except > > >> > > 'here's the usual podling-by-podling report' > > >> > > > >> > Do any of the directors on this list want additional information > aside > > >> > from the podling-by-podling report? Are rollup metrics/statements > of > > >> > use? > > >> > > >> Most definitely. > > >> > > >> We want a report about the Incubator. There is more going on than just > > >> podlings. > > >> > > >> Cheers, > > >> -g > > >> > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > >
Re: Report verbiage
Absolutely, that's the right thing to do. I, and I believe Greg, were answering Matt's question rather than you actions ;-) Sent from a mobile device, please excuse mistakes and brevity On 14 Feb 2013 01:15, "Benson Margulies" wrote: > The chair here is trying to lure others into helping to characterize > the overall state of things so as to avoid an overly one-sided view. > > > On Wed, Feb 13, 2013 at 8:06 PM, Ross Gardler > wrote: > > +1 > > > > The incubator is a project like any other. Its report should communicate > > the health or otherwise of the projects community and should communicate > > any information. The board should know about and make any requests for > > assistance from the board. > > > > Assuming the IPMC considers the Incubator to be in good shape the actual > > line by line podling reports are unimportant other than being the outputs > > of the incubator project. > > > > Sent from a mobile device, please excuse mistakes and brevity > > On 13 Feb 2013 23:40, "Greg Stein" wrote: > > > >> On Feb 13, 2013 3:39 PM, "Matt Franklin" > wrote: > >> > > >> > On Tue, Feb 12, 2013 at 11:45 AM, Benson Margulies > >> > wrote: > >> > > Does anyone feel inclined to communicate anything to the board > except > >> > > 'here's the usual podling-by-podling report' > >> > > >> > Do any of the directors on this list want additional information aside > >> > from the podling-by-podling report? Are rollup metrics/statements of > >> > use? > >> > >> Most definitely. > >> > >> We want a report about the Incubator. There is more going on than just > >> podlings. > >> > >> Cheers, > >> -g > >> > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [DISCUSS] [VOTE] HCatalog to Graduate and become part of Apache Hive
I'm not so much opinionated as confused here, perhaps because I have a very linear view of governance. I like to know how a vote fits into a governance structure or process, and I've felt for some time that this case (podling goes to existing TLP) is not well-explained by our structure. Back in the days when subprojects were normal and valid, the incubator had a role on behalf of' an existing TLP in supervising IP and community behavior. Graduation meant: "OK, umbrella, we certify that these people can behave like a project and have clean IP." And, perhaps, the board actually established subprojects? It's all before my time. Now that subprojects are no longer in the picture, I don't even know why the IPMC should ever incubate a podling *if the plan, from the start, is to be part of some existing TLP.* So I have assumed that HCatalog started out with the intention to grow into an entire TLP, and came up with the Hive plan as a fallback. To try to make this long story shorter, I think that we should make a proposal to the board with a schema for handling this case that makes sense in current conditions. I'm happy for it to be your schema, which amounts, as I see it, to the board having a supervisory moment when this happens, with an IPMC vote providing the same sort of strong recommendation one way or the other that it does for establishing a TLP. On Thu, Feb 14, 2013 at 12:49 AM, Mattmann, Chris A (388J) wrote: > Hi Benson, > > I saw your later email(s) and Incubator board report. It's fine and I > think the message of my objection comes across. > So thanks for that. > > One thing I wanted to comment on: > > On 2/13/13 4:10 AM, "Benson Margulies" wrote: > >>Chris, >> >>The obvious compromise is to ask them to report the vote result as it >>happened, it seems to me, -1's and all. But where do you think that >>they are reporting anything? There's nothing happening here at the >>board level. There's no board resolution needed for a Hive committer >>to type 'svn cp' on the hcatalog tree, > > Not by my counts. There's a *community* resolution and a recommendation to > be made by the IPMC, nonetheless. > Otherwise, the IPMC is pretty useless IMO, and more importantly, so is the > Incubator. > > Why bother even incubating HCatalog? Hive could have simply svn cp'ed > whatever code came in, or whatever code the podling arrived at, and > Incubation would have stopped then. But we both know that's not the way it > works. Even if a podling graduates to an existing TLP, go check out the > past resolutions. You'll note there's a section in there that discharges > the responsibility of the IPMC for the podling. So, yes, the IPMC *is* > involved. And yes, the IPMC vote matters. > > Cheers, > Chris > > > - > 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
