[RESULT][VOTE] Accept MRQL into the Incubator
The VOTE has passed with 5 binding +1's and no -1s. I'll start the work to get the podling started. Thank you. On Sun, Mar 10, 2013 at 3:48 AM, Mattmann, Chris A (388J) wrote: > +1 from me (binding). > > Good luck! > > Cheers, > Chris > > > On 3/6/13 9:04 AM, "Leonidas Fegaras" wrote: > >>Dear ASF members, >>I would like to call for a VOTE for acceptance of MRQL into the >>Incubator. >>The vote will close on Monday March 11, 2013. >> >>[ ] +1 Accept MRQL into the Apache incubator >>[ ] +0 Don't care. >>[ ] -1 Don't accept MRQL into the incubator because... >> >>Full proposal is pasted below and the corresponding wiki is >> >>http://wiki.apache.org/incubator/MRQLProposal >> >>Only VOTEs from Incubator PMC members are binding, >>but all are welcome to express their thoughts. >>Sincerely, >>Leonidas Fegaras >> >> >>= Abstract = >> >>MRQL is a query processing and optimization system for large-scale, >>distributed data analysis, built on top of Apache Hadoop and Hama. >> >>= Proposal = >> >>MRQL (pronounced ''miracle'') is a query processing and optimization >>system for large-scale, distributed data analysis. MRQL (the MapReduce >>Query Language) is an SQL-like query language for large-scale data >>analysis on a cluster of computers. The MRQL query processing system >>can evaluate MRQL queries in two modes: in MapReduce mode on top of >>Apache Hadoop or in Bulk Synchronous Parallel (BSP) mode on top of >>Apache Hama. The MRQL query language is powerful enough to express >>most common data analysis tasks over many forms of raw ''in-situ'' >>data, such as XML and JSON documents, binary files, and CSV >>documents. MRQL is more powerful than other current high-level >>MapReduce languages, such as Hive and PigLatin, since it can operate >>on more complex data and supports more powerful query constructs, thus >>eliminating the need for using explicit MapReduce code. With MRQL, >>users will be able to express complex data analysis tasks, such as >>PageRank, k-means clustering, matrix factorization, etc, using >>SQL-like queries exclusively, while the MRQL query processing system >>will be able to compile these queries to efficient Java code. >> >>= Background = >> >>The initial code was developed at the University of Texas of Arlington >>(UTA) by a research team, led by Leonidas Fegaras. The software was >>first released in May 2011. The original goal of this project was to >>build a query processing system that translates SQL-like data analysis >>queries to efficient workflows of MapReduce jobs. A design goal was to >>use HDFS as the physical storage layer, without any indexing, data >>partitioning, or data normalization, and to use Hadoop (without >>extensions) as the run-time engine. The motivation behind this work >>was to build a platform to test new ideas on query processing and >>optimization techniques applicable to the MapReduce framework. >> >>A year ago, MRQL was extended to run on Hama. The motivation for this >>extension was that Hadoop MapReduce jobs were required to read their >>input and write their output on HDFS. This simplifies reliability and >>fault tolerance but it imposes a high overhead to complex MapReduce >>workflows and graph algorithms, such as PageRank, which require >>repetitive jobs. In addition, Hadoop does not preserve data in memory >>across consecutive MapReduce jobs. This restriction requires to read >>data at every step, even when the data is constant. BSP, on the other >>hand, does not suffer from this restriction, and, under certain >>circumstances, allows complex repetitive algorithms to run entirely in >>the collective memory of a cluster. Thus, the goal was to be able to >>run the same MRQL queries in both modes, MapReduce and BSP, without >>modifying the queries: If there are enough resources available, and >>low latency and speed are more important than resilience, queries may >>run in BSP mode; otherwise, the same queries may run in MapReduce >>mode. BSP evaluation was found to be a good choice when fault >>tolerance is not critical, data (both input and intermediate) can fit >>in the cluster memory, and data processing requires complex/repetitive >>steps. >> >>The research results of this ongoing work have already been published >>in conferences (WebDB'11, EDBT'12, and DataCloud'12) and the authors >>have already received positive feedback from researchers in academia >>and industry who were attending these conferences. >> >>= Rationale = >> >>* MRQL will be the first general-purpose, SQL-like query language for >>data analysis based on BSP. >>Currently, many programmers prefer to code their MapReduce >>applications in a higher-level query language, rather than an >>algorithmic language. For instance, Pig is used for 60% of Yahoo >>MapReduce jobs, while Hive is used for 90% of Facebook MapReduce >>jobs. This, we believe, will also be the trend for BSP applications, >>because, even though, in principle, the BSP model is very simple to >>understand, it is hard to deve
Re: [VOTE] Apache Ambari (incubating) 1.2.1 Release Candidate RC0.
On Mon, Mar 11, 2013 at 1:49 PM, Roman Shaposhnik wrote: > At least > in Hadoop ecosystem I know of no other project that provides a combined > bundle for the checksums. Have you looked at the Hadoop releases? http://www.us.apache.org/dist/hadoop/common/hadoop-1.1.2/ -- Owen
[VOTE] Graduation of EasyAnt into Ant
Hi, The EasyAnt community would like to graduate as an subproject of Ant. The Ant PMC has just accepted: http://mail-archives.apache.org/mod_mbox/ant-dev/201303.mbox/%3CBD5DB6B8-13BC-421F-800C-CE6CB21D7BF4%40hibnet.org%3E The goal is to make EasyAnt a subproject of Ant, just like Ivy and IvyDE are. - EasyAnt code will be brought into Ant's svn tree. - EasyAnt committers will become Ant committers but not part of the PMC (on 5 committers, 3 are already Ant ones, and 2 are part of Ant's PMC) - The Ant PMC will be responsible for the code, the community, the next releases of EasyAnt. Easyant has been incubating since 31/01/2011. A release has been done the 27/02/2013. Some usefull links: - the EasyAnt project incubator page: http://incubator.apache.org/projects/easyant.html - the archive of the mailing lists http://mail-archives.apache.org/mod_mbox/incubator-easyant-commits/ http://mail-archives.apache.org/mod_mbox/incubator-easyant-dev/ - the release http://www.apache.org/dist/incubator/easyant Please cast your votes over the graduation of Easyant as a subproject of Ant. cheers, Nicolas - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
New podling infra setup question
Hi Everyone, I was just wondering how long we should expect infra setup to take in general. I understand that this is all done by volunteers so I'm not complaining. I just want to: 1) make sure I'm not holding things up by doing things incorrectly 2) be able to plan what I'm going to work on over the next few weeks For context I'm asking this from the perspective of the Knox podling. We have an umbrella Jira (https://issues.apache.org/jira/browse/INFRA-5913) filed. Thanks! Kevin. P.S. I had sent this previously using an non-subscribed email address so I apologize for anyone getting this in duplicate.
Re: [RESULT][VOTE] Accept Apache Knox Hadoop Gateway Project into the Incubator
Just tagging the [RESULT] onto the subject so that the vote status gets updated. On 24.02.2013 04:36, Devaraj Das wrote: > Hi folks, > With 10 binding +1 votes, this vote has passed. Thanks to everyone who > voted. > Devaraj. > +1 (binding) > > On 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 >> cha
Re: [VOTE] Apache Ambari (incubating) 1.2.1 Release Candidate RC0.
On Tue, Mar 12, 2013 at 9:11 AM, Owen O'Malley wrote: > On Mon, Mar 11, 2013 at 1:49 PM, Roman Shaposhnik wrote: > >> At least >> in Hadoop ecosystem I know of no other project that provides a combined >> bundle for the checksums. > > > Have you looked at the Hadoop releases? > > http://www.us.apache.org/dist/hadoop/common/hadoop-1.1.2/ That's why I was very careful in phrasing my statement: "hadoop *ecosystem*" (*) since I didn't want to get into the argument around the fact that it may be beneficial for Apache Hadoop project itself to reconsider its release practices around producing message digest information. But regardless, there's no reason for a podling not to follow established practices that a majority of ASF release do follow. Thanks, Roman. (*) it is like saying Earth's ecosystem -- the planet itself doesn't count :-) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] MetaModel join the Apache Incubator
Hi Kasper, One suggestion is to remove the "Contributors with known interest if project is accepted in Incubator" section and only add contributors that really want to get the project going. I could see this could be very useful for projects like Apache Gora or pluggable query component for Apache Drill. I would like to volunteer to become mentor and initial committer for this project to get it rolling. Thanks, Henry On Mon, Mar 11, 2013 at 5:43 AM, Kasper Sørensen < kasper.soren...@humaninference.com> wrote: > Christian, your point regarding number of active contributors is valid and > this is in deed also something that we feel is a risk to the project. I > would say though that Human Inference is committed to continue the effort > even if I should personally stop committing to it - reason being that the > software stack we have here is highly dependent on MetaModel. Right now we > are simply in a situation where I am the key go-to-guy when there's > MetaModel related work involved. Often we pair program on these tasks, but > commit through my account. > > The other side of the story is that we have several testers that > contribute a lot in terms of bug reports and so on. But because we're a > closed company these reports are typically going first through our internal > bugtracker and then into the trac system. At that point in time it will > typically be me that enters the trac ticket. This is obviously a style of > closedness that won't work in an Apache situation, and we need to adapt to > that. But I also believe that we can manage that transition during > incubation. > > As for the "potential" contributors - one have indicated that it is > important to him that we move MetaModel out of the corporate setting for > him to sign a contributors agreement. The other (Sameer) actually just told > me that he would want to contribute anyways, but that the incubation would > be an additional incentive, because of Apache's brand value. I don't think > any of us wants a @apache.org email though! :) > > Hope that sheds a bit more light on the matter. And thanks for questioning > this, it gives us opportunity to explain things! > > -Original Message- > From: Christian Grobmeier [mailto:grobme...@gmail.com] > Sent: 11. marts 2013 11:43 > To: general@incubator.apache.org > Subject: Re: [PROPOSAL] MetaModel join the Apache Incubator > > I still think this is a nice project and it might fit right into the ASF. > Currently I am out of time, so I cannot champion this proposal nor can I be > the most active mentor. Unfortunately it seems nobody else in the IPMC has > an interest in helping this proposal. > > Looking at: > http://eobjects.org/trac/timeline > > It seems MetaModel is more or less a single-man with a little support from > two other devs. With less interest from the Incubator and a small dev > community I am not sure how this project will develop here. If Kasper stops > to commit, the project is dead. > > Two contributors are listed as "have an interest to commit if accepted to > the ASF". Why didn't they contribute before? It reads a bit like they want > to have an @apache.org e-mail address than a real interest in the project. > > Hopefully other IPMC'lers find some time to comment here too. > > > > > On Mon, Mar 11, 2013 at 10:04 AM, Kasper Sørensen < > kasper.soren...@humaninference.com> wrote: > > Just for reference, I'd add to Sameer's mail that the proposal is here: > > > > http://wiki.apache.org/incubator/MetaModelProposal > > > > We would very much appreciate if one or more apache champions will help > us to get further in the process. > > > > Kasper > > > > -Original Message- > > From: sameer arora [mailto:sameer11...@gmail.com] > > Sent: 10. marts 2013 05:50 > > To: general@incubator.apache.org > > Subject: RE: [PROPOSAL] MetaModel join the Apache Incubator > > > > Hi, > > > > I have been working on Metamodel as a developer for the last 1.5 > years.We are also working on adding Hbase support to Metamodel to cater the > needs of today. > > > > It would be great to see Metamodel accepted at Apache Incubator, surely > the efforts from us would gain some momentum. > > > > Sameer > > > > - > > 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 > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org >
How to handle 3rd party extensions
Hi all, I'd like to ask a quick question to know how 3rd party extensions are handled in other Apache projects. (Historically,) In JSPWiki, all the custom plugins, filters, templates, etc, made by non committers has been uploaded to a wiki page at www.jspwiki.org. Each author uploaded his/her extension to his/her page, taking care of the content of that page, linking it to relevant pages, etc. Due to some legal reasons [#1], www.jspwiki.org is/has been in read-only mode for a while and the need of hosting somewhere new extensions is beginning to arise. We're considering opneing jira tickets under a "extensions" component, to be able to track all these extensions, but most probably it makes much more sense to give people commit access, per request, to a specific svn repo folder (something similar to the commit policy followed by Jenkins). We were wondering if this approach could be feasible under Apache's svn or if it makes more sense to host these extensions outside Apache infra (a google code or github account). What have other projects done on this situation? thanks & br, juan pablo [#1]: https://issues.apache.org/jira/browse/JSPWIKI-739
Re: [VOTE] Graduation of EasyAnt into Ant
+1 ...ant On Tue, Mar 12, 2013 at 3:06 PM, Nicolas Lalevée wrote: > Hi, > > The EasyAnt community would like to graduate as an subproject of Ant. > > The Ant PMC has just accepted: > > http://mail-archives.apache.org/mod_mbox/ant-dev/201303.mbox/%3CBD5DB6B8-13BC-421F-800C-CE6CB21D7BF4%40hibnet.org%3E > > The goal is to make EasyAnt a subproject of Ant, just like Ivy and IvyDE > are. > - EasyAnt code will be brought into Ant's svn tree. > - EasyAnt committers will become Ant committers but not part of the PMC > (on 5 committers, 3 > are already Ant ones, and 2 are part of Ant's PMC) > - The Ant PMC will be responsible for the code, the community, the next > releases of EasyAnt. > > Easyant has been incubating since 31/01/2011. > A release has been done the 27/02/2013. > > Some usefull links: > - the EasyAnt project incubator page: > http://incubator.apache.org/projects/easyant.html > - the archive of the mailing lists > http://mail-archives.apache.org/mod_mbox/incubator-easyant-commits/ > http://mail-archives.apache.org/mod_mbox/incubator-easyant-dev/ > - the release > http://www.apache.org/dist/incubator/easyant > > Please cast your votes over the graduation of Easyant as a subproject of > Ant. > > cheers, > Nicolas > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: How to handle 3rd party extensions
On 12/03/2013 Juan Pablo Santos Rodríguez wrote: I'd like to ask a quick question to know how 3rd party extensions are handled in other Apache projects. Not that OpenOffice is a typical Apache project, but OpenOffice hosts its extensions at http://extensions.openoffice.org/ The site is officially considered a third-party site and hosts user-provided content under all kinds of licenses; it used to be hosted at Oracle and it is now hosted by SourceForge as a service to the OpenOffice community. Same for the templates site http://templates.openoffice.org/ Regards, Andrea. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: How to handle 3rd party extensions
On Tue, Mar 12, 2013 at 12:41 PM, Juan Pablo Santos Rodríguez wrote: > Hi all, > > I'd like to ask a quick question to know how 3rd party extensions are > handled in other Apache projects. (Historically,) In JSPWiki, all the > custom plugins, filters, templates, etc, made by non committers has been > uploaded to a wiki page at www.jspwiki.org. Each author uploaded his/her > extension to his/her page, taking care of the content of that page, linking > it to relevant pages, etc. > > Due to some legal reasons [#1], www.jspwiki.org is/has been in read-only > mode for a while and the need of hosting somewhere new extensions is > beginning to arise. We're considering opneing jira tickets under a > "extensions" component, to be able to track all these extensions, but most > probably it makes much more sense to give people commit access, per > request, to a specific svn repo folder (something similar to the commit > policy followed by Jenkins). > > We were wondering if this approach could be feasible under Apache's svn or > if it makes more sense to host these extensions outside Apache infra (a > google code or github account). > > What have other projects done on this situation? > > > thanks & br, > juan pablo > > > [#1]: https://issues.apache.org/jira/browse/JSPWIKI-739 Assuming the new templates are "Apache Licensed", you might have few options : - Contributors can submit/update artifacts via JIRA and a committer would update to the proper location - After submitting a CLA, a contributor is granted write access to 3rd party artifact area and can submit/update his Apache Licensed artifacts - Based on the type of contribution, evaluate the contributor and possible make him a committer, then problem solved... For non Apache Licensed artifacts, you might consider Apache Extras, but you probably wil only have a link saying something like "For other non Apache Licensed artifacts, see... " and point to apache extras. -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: How to handle 3rd party extensions
Hi! thanks for both inputs :-) Seems that Apache Extras is what I was looking for br, juan pablo On Tue, Mar 12, 2013 at 11:36 PM, Luciano Resende wrote: > On Tue, Mar 12, 2013 at 12:41 PM, Juan Pablo Santos Rodríguez > wrote: > > Hi all, > > > > I'd like to ask a quick question to know how 3rd party extensions are > > handled in other Apache projects. (Historically,) In JSPWiki, all the > > custom plugins, filters, templates, etc, made by non committers has been > > uploaded to a wiki page at www.jspwiki.org. Each author uploaded his/her > > extension to his/her page, taking care of the content of that page, > linking > > it to relevant pages, etc. > > > > Due to some legal reasons [#1], www.jspwiki.org is/has been in read-only > > mode for a while and the need of hosting somewhere new extensions is > > beginning to arise. We're considering opneing jira tickets under a > > "extensions" component, to be able to track all these extensions, but > most > > probably it makes much more sense to give people commit access, per > > request, to a specific svn repo folder (something similar to the commit > > policy followed by Jenkins). > > > > We were wondering if this approach could be feasible under Apache's svn > or > > if it makes more sense to host these extensions outside Apache infra (a > > google code or github account). > > > > What have other projects done on this situation? > > > > > > thanks & br, > > juan pablo > > > > > > [#1]: https://issues.apache.org/jira/browse/JSPWIKI-739 > > Assuming the new templates are "Apache Licensed", you might have few > options : >- Contributors can submit/update artifacts via JIRA and a committer > would update to the proper location >- After submitting a CLA, a contributor is granted write access to > 3rd party artifact area and can submit/update his Apache Licensed > artifacts >- Based on the type of contribution, evaluate the contributor and > possible make him a committer, then problem solved... > > For non Apache Licensed artifacts, you might consider Apache Extras, > but you probably wil only have a link saying something like "For other > non Apache Licensed artifacts, see... " and point to apache extras. > > > -- > Luciano Resende > http://people.apache.org/~lresende > http://twitter.com/lresende1975 > http://lresende.blogspot.com/ > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
[RESULT][VOTE] Graduate Apache Bloodhound from Incubator
We appear to be beyond the 72 hours now and the following votes have been cast: +1 Branko Čibej (binding) +1 Chris Mattmann (binding) +1 Greg Stein (binding) +1 Joachim Dreimann +1 Ryan Ollos +1 Jure Zitnik +1 Matevž Bradač +1 Gavin McDonald (binding) With 8 +1s, four of which are binding, and no other votes cast, the vote has passed. I will shortly email the proposed resolution to the board asking for inclusion at the next board meeting. Many thanks, Gary On 10/03/13 00:31, Gary Martin wrote: Hi, Following the community graduation vote result announcement on the bloodhound-dev@i.a.o mailing list [1] and the conclusion of the podling name search [2], I would like to invite Apache Incubator to vote on recommending Apache Bloodhound for graduation. Please vote: [ ] +1 Graduate Apache Bloodhound podling from Apache Incubator [ ] +0 Indifferent to the graduation status of Apache Bloodhound podling [ ] -1 Reject graduation of Apache Bloodhound podling from Apache Incubator because ... The vote will run for at least 72 hours. The proposed graduation resolution is below. Cheers, Gary [1] http://markmail.org/message/k6q7l4gvdtuhu6z2 [2] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-22 --- X. Establish the Apache Bloodhound Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software, for distribution at no charge to the public, related to a software development collaboration tool, including issue tracking, wiki and repository browsing. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache Bloodhound Project", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Bloodhound Project be and hereby is responsible for the creation and maintenance of software related to a software development collaboration tool, including issue tracking, wiki and repository browsing; and be it further RESOLVED, that the office of "Vice President, Apache Bloodhound" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Bloodhound Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Bloodhound Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Bloodhound Project: * Mat Booth * Matevž Bradač * John Chambers * Branko Čibej * Joachim Dreimann * Andrej Golcov * Peter Koželj * Gary Martin * Gavin McDonald * Ryan Ollos * Mark Poole * Greg Stein * Hyrum K. Wright * Jure Žitnik NOW, THEREFORE, BE IT FURTHER RESOLVED, that Gary Martin be appointed to the office of Vice President, Apache Bloodhound, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Bloodhound PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Bloodhound Project; and be it further RESOLVED, that the Apache Bloodhound Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Bloodhound podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Bloodhound podling encumbered upon the Apache Incubator Project are hereafter discharged. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Resolved] (PODLINGNAMESEARCH-26) Establish whether "Apache Open Climate Workbench" is a suitable name
[ https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris A. Mattmann resolved PODLINGNAMESEARCH-26. Resolution: Fixed - resolved name is suitable. > Establish whether "Apache Open Climate Workbench" is a suitable name > > > Key: PODLINGNAMESEARCH-26 > URL: > https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-26 > Project: Podling Suitable Names Search > Issue Type: Suitable Name Search >Reporter: Chris A. Mattmann > > A suitable name search is required in order for Open Climate Workbench to > graduate from the incubation. > Apache Open Climate Workbench is a system that allows for easy comparison of > climate model outputs (regional, and global, but focused on reigional) and > remote sensing/satellite observations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT][VOTE] Accept Tez into Incubator
On 25.02.2013 05:44, Arun C Murthy wrote: > Thanks to all who voted. Obviously, I'm +1 (binding) on the proposal. > > With 14 +1s (10 binding) the vote passes. > > I'll start the work to get the podling started. > > thanks, > Arun > > On Feb 19, 2013, at 8:26 PM, Arun C Murthy wrote: > >> Hi Folks, >> >> Thanks for participating in the discussion. I'd like to call a VOTE for >> acceptance of Apache Tez into the Incubator. I'll let the vote run till into >> this weekend (Sun 2/24 6pm PST). >> >> [ ] +1 Accept Apache Tez into the Incubator >> [ ] +0 Don't care. >> [ ] -1 Don't accept Apache Tez into the Incubator because... >> >> Full proposal is pasted at the bottom of this email, and the corresponding >> wiki is http://wiki.apache.org/incubator/TezProposal. >> >> Only VOTEs from Incubator PMC members are binding, but all are welcome to >> express their thoughts. >> >> Here's my +1 (binding). >> >> thanks, >> Arun >> >> PS: From the initial discussion, the only changes are that I've added one >> new mentor and 2 new committers. All the new additions come from the >> non-major employer while we continue to strive to further diversify during >> the incubation. Thanks. >> >> >> >> = Tez = >> >> == Abstract == >> Tez is an effort to develop a generic application framework which can be used >> to process arbitrarily complex data-processing tasks and also a re-usable set >> of data-processing primitives which can be used by other projects. >> >> == Proposal == >> Tez is a proposal to develop a generic application which can be used to >> process complex data-processing task DAGs and runs natively on Apache Hadoop >> YARN. YARN is a generic resource-management system on which currently >> applications like MapReduce already exist. MapReduce is a specific, and >> constrained, DAG - which is not optimal for several frameworks like Apache >> Hive >> and Apache Pig. Furthermore, we propose to develop a re-usable set of >> libraries of data-processing primitives such as sorting, merging, >> data-shuffling, intermediate data management etc. which are necessary for >> Tez >> which we envision can be used directly by other projects. >> >> == Background == >> Apache Hadoop MapReduce has emerged as the assembly-language on which other >> frameworks like Apache Pig and Apache Hive have been built. However, it has >> been well accepted that MapReduce produces very constrained task DAGs for >> each >> job which results in Apache Pig and Apache Hive requiring multiple MapReduce >> jobs for several queries. By providing a more expressive DAG of tasks for a >> job, Tez attempts to provide significantly enhanced data-processing >> capabilities for projects like Apache Pig, Apache Hive, Cascading etc. >> >> == Rationale == >> There is an important gap that Tez fulfills in the Apache Hadoop ecosystem of >> allowing for more expressive task DAGs for data-processing applications such >> as Apache Pig, Apache Hive, Cascading etc. >> >> With emergence of Apache Hadoop YARN, there is a strong need for a >> common DAG application which can then be shared by Apache Pig, Apache Hive, >> Cascading etc. >> >> == Initial Goals == >> The initial goals for this project are to specify the detailed requirements >> and architecture, and then develop the initial implementation including the >> DAG ApplicationMaster to run natively inside Apache Hadoop YARN. >> >> == Current Status == >> Significant work has been completed to identify the initial requirements and >> define the overall system architecture. There is a patch available in the >> internal Hortonworks git repository which can act as the initial seed. >> >> === Meritocracy === >> We plan to invest in supporting a meritocracy. We will discuss the >> requirements >> in an open forum. Several companies have already expressed interest in this >> project, and we intend to invite additional developers to participate. >> We will encourage and monitor community participation so that privileges can >> be >> extended to those that contribute. >> >> === Community === >> The need for a generic DAG application for data processing in the open >> source is >> tremendous, so there is a potential for a very large community. We believe >> that Tez's extensible architecture will further encourage community >> participation. >> Also, related Apache projects (eg, Pig, Hive) have very large and active >> communities, and we expect that over time Tez will also attract a large >> community. >> >> === Core Developers === >> The developers on the initial committers list include people very experienced >> in the Apache Hadoop ecosystem: >> >> * Alan Gates >> * Arun C Murthy >> * Ashutosh Chauhan >> * Bikas Saha >> * Chris Douglas >> * Daryn Sharp >> * Devaraj Das >> * Gopal Vijayaraghavan >> * Gunther Hagleitner >> * Hitesh Shah >> * Jason Lowe >> * Jean Xu >> * Jitendra Pandey >> * Julien Le Dem >> * Kevin Wilfong >> * Mike Liddell >> * Namit Jain
[RESULT][VOTE] Accept Provisionr into the Apache Incubator
On 07.03.2013 08:54, Andrei Savu wrote: > Thanks to all who voted! With 18 +1s (10 binding) the vote passes. > > I'll start the work to get the podling started. > > Thanks, > Andrei > > On Mon, Mar 4, 2013 at 9:31 PM, Henry Saputra wrote: > >> +1 non-binding >> >> Good luck >> >> >> On Sat, Mar 2, 2013 at 3:35 PM, Andrei Savu wrote: >> >>> Hi Guys, >>> >>> I'd like to call a VOTE for acceptance of Provisionr into the Apache >>> Incubator. >>> >>> The vote will close on March 8. >>> >>> [] +1 Accept Provisionr into the Apache incubator >>> [] +0 Don't care. >>> [] -1 Don't accept Provisionr into the incubator because... >>> >>> Full proposal is pasted at the bottom on this email, and the >> corresponding >>> wiki is http://wiki.apache.org/incubator/ProvisionrProposal >>> >>> Only VOTEs from Incubator PMC members are binding, but all are welcome to >>> express their thoughts. >>> >>> Thanks, >>> Andrei Savu >>> >>> -- >>> Provisionr Proposal >>> >>> == Abstract == >>> >>> Provisionr is an effort to develop a service that can be used to create >> and >>> manage pools of virtual machines on multiple clouds. Our focus is on >>> semi-automated workflows and cloud portability. >>> >>> == Proposal == >>> >>> Provisionr solves the problem of cloud portability by hiding completely >> the >>> APIs and only focusing on building a cluster that matches the same set of >>> assumptions on all clouds, assumptions like: running a specific operating >>> system (e.g. Ubuntu 12.04 LTS), having the same set of pre-installed >>> packages and binaries, sane dns settings (forward & reverse ip >> resolution - >>> as needed for Hadoop), ntp settings, networking settings, firewall, ssh >>> admin access, vpn access etc. >>> >>> As a secondary goal Provisionr should also provide primitives for >> building >>> automatic or semi-automatic workflows for configuring services, workflows >>> that assume that all the machines share a common set of characteristics >> as >>> described above. >>> >>> == Background == >>> >>> Creating clusters on cloud infrastructure is non-trivial because careful >>> orchestration is required. To make it easy to deploy services we need to >>> start from a foundation that matches a common set of assumptions on >>> multiple providers. >>> >>> == Rationale == >>> >>> This project started as a re-write of the core of Apache Whirr but has a >>> different target being more focused on semi-automated workflows and cloud >>> portability. >>> >>> == Initial Goals == >>> >>> * Build a community >>> * Provide an excellent user experience for semi-automatic workflows >> (e.g. >>> using Rundeck) >>> * Implement a REST service and a Web Console >>> * Add support for more providers >>> >>> == Current Status == >>> >>> Provisionr had four releases on [[ >>> https://github.com/axemblr/axemblr-provisionr/wiki|GitHub]] and it's >> used >>> to deploy Hadoop clusters on-demand at Axemblr and infrastructure for >>> testing / QA. >>> >>> === Meritocracy === >>> >>> We plan to invest in supporting a meritocracy. We will discuss the >>> requirements in an open forum. Several companies have already expressed >>> interest in this project, and we intend to invite additional developers >> to >>> participate. We will encourage and monitor community participation so >> that >>> privileges can be extended to those that contribute. >>> >>> === Community === >>> >>> The community interested in cloud service infrastructure is currently >>> spread across many smaller projects, and one of the main goals of this >>> project is to build a vibrant community to share best practices and build >>> common infrastructure. >>> >>> === Core developers === >>> >>> Core developers are very experienced in the Apache ecosystem. To achieve >>> more diversity of developers, we will be eager to recruit developers from >>> diverse companies. >>> >>> * Andrei Savu - asavu at apache dot org (Apache Whirr PMC) >>> * Ioan Eugen Stan - ieugen at apache dot org (Apache James PMC) >>> * Alex Ciminian - alex.ciminian at gmail dot org >>> >>> === Alignment === >>> >>> Provisionr complements Apache Whirr and later on it should provide a >> robust >>> foundation for more advanced functionalities. >>> >>> == Known Risks == >>> >>> === Orphaned products === >>> >>> The contributors have significant open source experience and the project >> is >>> being used as part of a commercial product, so the risk of being orphaned >>> is relatively low. We plan to mitigate this risk by recruiting additional >>> committers. >>> >>> === Inexperience with Open Source === >>> >>> Most of the initial committers have experience working on open source >>> projects. Andrei Savu and Ioan Eugen Stan have experience as committers >> and >>> PMC members on other Apache projects. >>> >>> === Homogenous Developers === >>> >>> We are committed to recruiting additional committers from other companies >>> based on their contributions to the project. >>> >>> === Reliance on Salaried Develope
[RESULT][VOTE] Accept Tajo into the Apache Incubator
Hi folks, This VOTE has PASSED with 11 binding +1's and 5 non-binding +1's. (binding) +1 Jakob Homan +1 Chris Douglas +1 Jean-Baptiste Onofré +1 Ted Dunning +1 Alan Cabrera +1 Suresh Marru +1 Owen O'Malley +1 Steve Loughran +1 Roman Shaposhnik +1 Alex Karasulu +1 Mattmann, Chris A (non-binding.) +1 Matthias Friedrich +1 Henry Saputra +1 Sharad Agarwal +1 Andrew Purtell +1 Hyunsik Choi Thanks, all
Re: [VOTE] Graduation of EasyAnt into Ant
On 2013-03-12, Nicolas Lalevée wrote: > Please cast your votes over the graduation of Easyant as a subproject of Ant. +1 Stefan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Please publish the incubator website, when did changes
Hi folks, from time to time I publish the website. Usually I check the diff first, and it happens that I see changes which I didn't include. I am then required to make a quick cross check and see if they are ok. It would be better if the person who pushed a change (most often the status page) would also publish the website right after. Otherwise the next publisher will never knew if publication is desired or not. Cheers Christian -- 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: Please publish the incubator website, when did changes
> status page) would also publish the website right after. Otherwise the Thanks I see. To publish the website, do I only need to commit to production like below? Log: mrql added, changes to ripple. Added: websites/production/incubator/content/ - copied from r854238, websites/staging/incubator/trunk/content/ On Wed, Mar 13, 2013 at 3:41 PM, Christian Grobmeier wrote: > Hi folks, > > from time to time I publish the website. Usually I check the diff > first, and it happens that I see changes which I didn't include. I am > then required to make a quick cross check and see if they are ok. > > It would be better if the person who pushed a change (most often the > status page) would also publish the website right after. Otherwise the > next publisher will never knew if publication is desired or not. > > Cheers > Christian > > -- > 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 > -- Best Regards, Edward J. Yoon @eddieyoon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
