Re: [DISCUSS] BOM and supported platforms for Bigtop 0.4.0
Hi,
On Fri, May 4, 2012 at 11:00 PM, Roman Shaposhnik r...@apache.org wrote:
Perhaps this preso can help a bit:
http://people.apache.org/~rvs/apache-bigtop2.pdf
Perfect, thanks!
* If the former, then each subdirectory of [1] falls fairly
conveniently into the traditional concept of convenience binaries
built from the source release. The only extra thing you'd need is a
proper set of license metadata and signatures for the binaries.
This is, in fact, the process we've been following with our convenience
artifacts for as long as we've had releases. We're signing every single
binary and are pretty pedantic about providing LICENSE and NOTICE files.
Sounds good.
I'm just wondering about where do I find for example the licensing
metadata for example for the files in
http://www.apache.org/dist/incubator/bigtop/bigtop-0.3.0-incubating/repos/fedora16/hive/
Or am I just missing something obvious? Like that you're using RPM
conventions for those bits, similar to how binary jars typically have
their licensing metadata in META-INF/{LICENSE,NOTICE}.
BR,
Jukka Zitting
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] retire zeta components from incubation
Here my vote : +1 (binding) On Thu, May 3, 2012 at 2:36 PM, Ralph Goers ralph.go...@dslextreme.com wrote: +1 (binding) Ralph On May 3, 2012, at 1:12 AM, Julien Vermillard wrote: Hi, As discussed earlier the Zeta components community has voted to retire the project. Following the retirement guide [1], I now call the Incubator PMC to vote on confirming this decision. This vote is open for the next 72 hours. [ ] +1 Retire the Zeta components project [ ] -1 Do not retire the project, because ... [1] http://incubator.apache.org/guides/retirement.html Cheers, Julien -- Forwarded message -- From: Julien Vermillard jvermill...@gmail.com Date: Fri, Apr 20, 2012 at 3:05 PM Subject: [RESULT] Re: [VOTE] retire zeta components from incubation To: zeta-...@incubator.apache.org Cc: general@incubator.apache.org So let's close the vote : +1 binding : grobmeier, beberlei, derick, jpic, oms, rolandb, +0 binding : kore, toby -1 none So let's close this podling. Julien - 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] BOM and supported platforms for Bigtop 0.4.0
Hi, On Sat, May 5, 2012 at 1:34 AM, Alan Gates ga...@hortonworks.com wrote: My question here was whether this concept of convenience binaries should extend beyond ASF owned packages. I realize that many existing convenience binaries contain non-ASF jars, etc. But taking the next step of explicitly distributing non-ASF binaries on their own concerns me. The normal guidelines of what kind of third-party bits can be redistributed by Apache projects are in http://www.apache.org/legal/resolved.html. As long as all the components included in a BigTop x.y installation meet those guidelines or are system dependencies like Fedora 16 that don't come form the ASF, then the ASF policy side of things should be fine. A somewhat similar example from another domain is Apache Tika, which binds together a lot of upstream libraries from both within and outside the ASF and makes them available as a single integrated and tested package. AFAIUI the main difference here is that unlike in Tika, BigTop doesn't have a programming API for accessing the included components. Instead, IIUC, the BigTop API is a deployment/testing one with stuff like yum install, etc. Now (again IIUC) the interesting bit is whether it's better for BigTop to be repackaging and -distributing upstream components by itself, or if it would in fact be better for BigTop to simply provide something like bigtop-x.y.rpm and bigtop-x.y.deb packages that just declare dependencies to specific, integration-tested versions of upstream packages. To do this, BigTop would need to work with the upstream projects to help them produce the appropriate deployment packages as a part of their normal release processes. And BigTop could also team up with Infrastructure to maintain the kind of repository structure and download service expected by deployment tools like yum and apt, a bit like what Maven projects have in https://repository.apache.org/. This is in fact a bit like what Tika has recently been considering (see http://markmail.org/message/wj4xkoax2ojnqlht) with it's upstream components. Instead of repackaging and -distributing them directly as a part of a Tika release, we're looking at ways to add the required extra bits to the upstream releases so that Tika could just consume them as normal dependencies. * In that case there might still be a role for BigTop to provide a central repository for such easily consumable upstream releases. This would be somewhat similar to the discussions that took place a few years ago about whether and how the ASF could host something like the central Maven repository. Do you know what list that discussion took place on and a general time frame? Reading through that would be very helpful for my thinking on this topic. See January 2007 on board@ and infrastructure@. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] BOM and supported platforms for Bigtop 0.4.0
spreading the world since years, and it's always funny what new combinations come up: https://twitter.com/#!/struberg/status/197003905027149824 :) LieGrue, strub From: Greg Stein gst...@gmail.com To: general@incubator.apache.org Cc: bigtop-...@incubator.apache.org Sent: Friday, May 4, 2012 8:54 PM Subject: Re: [DISCUSS] BOM and supported platforms for Bigtop 0.4.0 On May 4, 2012 2:03 PM, Patrick Hunt ph...@apache.org wrote: ... EOD existing Apache rules/license make no such distinction. Works under the following licenses may be included within Apache products (includes ASL). Can people please stop using ASL or APL? No such thing. It is the Apache License. AL for short, or even ALv2. Thanks, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[ANNOUNCE] Apache Airavata 0.2-INCUBATING Release
The Apache Airavata (Incubating) team is pleased to announce the immediate availability of the Airavata 0.2-INCUBATING release. The release can be obtained from the Apache Airavata download page - http://incubator.apache.org/airavata/about/downloads.html Release notes are available at - https://svn.apache.org/repos/asf/incubator/airavata/tags/airavata-0.2-incubating/RELEASE_NOTES Apache Airavata is a software toolkit currently used to build science gateways but that has a much wider potential use. It provides features to compose, manage, execute, and monitor small to large scale applications and workflows on computational resources ranging from local clusters to national grids and computing clouds. Gadgets interfaces to Airavata back end services can be deployed in open social containers such as Apache Rave and modify them to suit their needs. Airavata builds on general concepts of service oriented computing, distributed messaging, and workflow composition and orchestration. For general information on Apache Airavata, please visit the project website: http://incubator.apache.org/airavata/ Disclaimer: Apache Airavata is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the Apache Incubator. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
Re: [VOTE] retire zeta components from incubation
+1 binding Regards, Alan On May 3, 2012, at 1:12 AM, Julien Vermillard wrote: Hi, As discussed earlier the Zeta components community has voted to retire the project. Following the retirement guide [1], I now call the Incubator PMC to vote on confirming this decision. This vote is open for the next 72 hours. [ ] +1 Retire the Zeta components project [ ] -1 Do not retire the project, because ... [1] http://incubator.apache.org/guides/retirement.html Cheers, Julien -- Forwarded message -- From: Julien Vermillard jvermill...@gmail.com Date: Fri, Apr 20, 2012 at 3:05 PM Subject: [RESULT] Re: [VOTE] retire zeta components from incubation To: zeta-...@incubator.apache.org Cc: general@incubator.apache.org So let's close the vote : +1 binding : grobmeier, beberlei, derick, jpic, oms, rolandb, +0 binding : kore, toby -1 none So let's close this podling. Julien - 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: Shepherds for podling reports
On May 2, 2012, at 1:53 AM, Jukka Zitting wrote: Hi, In order to better share the effort of reviewing podling reports and giving constructive feedback where needed, I'd like to propose something like the shepherd model the ASF board is using for project reports. For each report a single shepherd [*] is assigned responsibility for a deeper review of the report and any followups that may be needed. Of course anyone within the IPMC is still welcome to help in the review, and in any case the mentors of a podling should review and sign off on the reports of their podlings. Any volunteer shepherds? Please sign up by adding your name to [1]. [1] http://wiki.apache.org/incubator/IncubatorShepherds [*] A shepherd watching over a podling... Perhaps someone has a better agricultural term in mind? :-) I feel that I should state my opinion, and this is just my humble opinion, that the solution to a problem is not to add more process, bureaucracy, and roles. It's my opinion that this task should be done by the mentors, period. If people have spare bandwidth they then should sign up to be a mentor. Just my 2 cents. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Shepherds for podling reports
On Sat, May 5, 2012 at 6:27 PM, Alan D. Cabrera l...@toolazydogs.com wrote: On May 2, 2012, at 1:53 AM, Jukka Zitting wrote: Hi, In order to better share the effort of reviewing podling reports and giving constructive feedback where needed, I'd like to propose something like the shepherd model the ASF board is using for project reports. For each report a single shepherd [*] is assigned responsibility for a deeper review of the report and any followups that may be needed. Of course anyone within the IPMC is still welcome to help in the review, and in any case the mentors of a podling should review and sign off on the reports of their podlings. Any volunteer shepherds? Please sign up by adding your name to [1]. [1] http://wiki.apache.org/incubator/IncubatorShepherds [*] A shepherd watching over a podling... Perhaps someone has a better agricultural term in mind? :-) I feel that I should state my opinion, and this is just my humble opinion, that the solution to a problem is not to add more process, bureaucracy, and roles. It's my opinion that this task should be done by the mentors, period. If people have spare bandwidth they then should sign up to be a mentor. Just my 2 cents. Thanks Alan, I always appreciate your input. However I think Jukka is simply asking for more fresh eye balls to help in the review before submission of the composite report. The shear time, and volume of work required to properly review all those Incubator Podling reports can be overwhelming for a single person: delegation is very sensible. I don't think there's more process or more bureaucracy. IMHO it's a good, non-bureaucratic evolutionary step towards better management. Honestly when I try to put myself into the IPMC Chair's perspective to understand the amount of work and responsibility he has, I get overwhelmed. -- Best Regards, -- Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Shepherds for podling reports
On May 5, 2012, at 9:04 AM, Alex Karasulu wrote: On Sat, May 5, 2012 at 6:27 PM, Alan D. Cabrera l...@toolazydogs.com wrote: On May 2, 2012, at 1:53 AM, Jukka Zitting wrote: Hi, In order to better share the effort of reviewing podling reports and giving constructive feedback where needed, I'd like to propose something like the shepherd model the ASF board is using for project reports. For each report a single shepherd [*] is assigned responsibility for a deeper review of the report and any followups that may be needed. Of course anyone within the IPMC is still welcome to help in the review, and in any case the mentors of a podling should review and sign off on the reports of their podlings. Any volunteer shepherds? Please sign up by adding your name to [1]. [1] http://wiki.apache.org/incubator/IncubatorShepherds [*] A shepherd watching over a podling... Perhaps someone has a better agricultural term in mind? :-) I feel that I should state my opinion, and this is just my humble opinion, that the solution to a problem is not to add more process, bureaucracy, and roles. It's my opinion that this task should be done by the mentors, period. If people have spare bandwidth they then should sign up to be a mentor. Just my 2 cents. Thanks Alan, I always appreciate your input. However I think Jukka is simply asking for more fresh eye balls to help in the review before submission of the composite report. The shear time, and volume of work required to properly review all those Incubator Podling reports can be overwhelming for a single person: delegation is very sensible. I don't think there's more process or more bureaucracy. IMHO it's a good, non-bureaucratic evolutionary step towards better management. Honestly when I try to put myself into the IPMC Chair's perspective to understand the amount of work and responsibility he has, I get overwhelmed. I understand and sympathize that it's a lot of work for the IPMC chair but frankly, I had always thought that this bit of responsibility was delegated to the mentors which is why mentors usually needed to be IPMC members. It is more process, reports are now to be checked by a new role in addition to being checked by the mentors, and bureaucracy, there are signup sheets, and now there are new roles, shepherds. Now the shepherds need to be tracked to see if there is sufficient coverage for report checking. IMNSHO, the elephant in the room is MIA mentors. Regards, Alan
Re: Shepherds for podling reports
If you don't want to be a Shepherd, don't sign up. The board asked us to do a better job of reviewing reports and detecting mentor deficiencies. This is a plan to accomplish that. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT][VOTE] Graduate Apache MRUnit from Incubator
The vote has been open since Tue, 24 Apr 2012 03:56:24 GMT. The vote to graduate MRUnit passes: I guess you can add to this to board agena now, Chris. 9 +1's 0 0's 0 -1's IPMC +1 Patrick Hunt Chris Mattmann Jukka Zitting Tom White PPMC +1 Brock Noland Dave Beech Jim Donofrio Jarek Jarcec Cecho Others +1 Joey Echeverria On 05/04/2012 12:21 PM, Tom White wrote: +1 to graduate MRUnit. Cheers, Tom On Thu, May 3, 2012 at 7:31 PM, Jim Donofriodonofrio...@gmail.com wrote: We havent heard anything +1 or -1 from any IPMC members besides our mentors. Any thoughts on this vote? We released 0.9.0-incubating on Tuesday so we have completed 4 releases and added 4 new commiters since the beginning of incubation To resummarize the current vote is below: 7 +1's 0 0's 0 -1's IPMC +1 Patrick Hunt Chris Mattmann PPMC +1 Brock Noland Dave Beech Jim Donofrio Jarek Jarcec Cecho Others +1 Joey Echeverria On 04/28/2012 12:11 PM, Mattmann, Chris A (388J) wrote: Hi Jim, Yep, we need more VOTEs than 2 (3 I believe, but it would be nice to have a bit more -- though not required). There's been a lot of traffic on general@incbuator lately so folks are probably just busy. I would wait until tonight or tomorrow and poll for some more VOTEs on the VOTE thread. Once we get the required VOTEs, you can close the VOTE, and I can add the resolution to the board agenda. Cheers, Chris On Apr 28, 2012, at 6:35 AM, Jim Donofrio wrote: How many IPMC votes are required for graduation? We got 2 IPMC votes so far from mentors but havent gotten any on the general@ list. Since the vote has been open for more than 72 hours, does this mean we cant graduate yet? On 04/23/2012 11:56 PM, Jim Donofrio wrote: We havent heard anything on the DISCUSS thread since posting it over 72 hours ago so I am starting a VOTE thread following Chris Mattmann's recommendation. I will leave the vote open for 72 hours. The current vote is below copying from the community vote [2] that passed: 7 +1's 0 0's 0 -1's IPMC +1 Patrick Hunt Chris Mattmann PPMC +1 Brock Noland Dave Beech Jim Donofrio Jarek Jarcec Cecho Others +1 Joey Echeverria In the last MRUnit incubator report [1] the 3 blockers were: * Grow the community size and diversity * Make another incubating release * Construct an MRUnit website to replace the existing stub We have since: * Added 2 new committers/PPMC members * 0.9.0-incubating will get released soon, pending one more IPMC +1 * We have a new website From the beginning of incubation we have: * Added 4 new committers/PPMC members * Done 4 releases once 0.9.0-incubating is released soon, pending one more IPMC +1 * Created a real website [1]: http://incubator.apache.org/mrunit/ppmc/incubator_reports.html#march-2012 [2]: http://mail-archives.apache.org/mod_mbox/incubator-mrunit-dev/201204.mbox/%3C4F91FED1.2010609%40gmail.com%3E X. Establish the Apache MRUnit 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 related to unit testing Apache Hadoop map reduce jobs for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache MRUnit Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache MRUnit Project be and hereby is responsible for the creation and maintenance of software related to unit testing Apache Hadoop map reduce jobs; and be it further RESOLVED, that the office of Vice President, Apache MRUnit 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 MRUnit Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache MRUnit 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 MRUnit Project: * Brock Noland br...@apache.org * Patrick Hunt ph...@apache.org * Nigel Daley ni...@apache.org * Eric Sammer esam...@apache.org * Aaron Kimball kimba...@apache.org * Konstantin Boudnik c...@apache.org * Garrett Wu g...@apache.org * Jim Donofrio jdonof...@apache.org * Jarek Jarcec Cecho jar...@apache.org * Dave Beech dbe...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Brock Noland be appointed to the office of Vice President, Apache MRUnit, 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 MRUnit PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and
Re: Shepherds for podling reports
On May 5, 2012, at 11:07 AM, Benson Margulies wrote: If you don't want to be a Shepherd, don't sign up. Yeah, I get that part. The board asked us to do a better job of reviewing reports and detecting mentor deficiencies. I get that too. This is a plan to accomplish that. My opinion about the plan stands. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT][VOTE] Graduate Apache MRUnit from Incubator
Hi Jim, Thanks, will do. I will add it to the board agenda shortly. Thanks to all for VOTE'ing! Cheers, Chris On May 5, 2012, at 11:31 AM, Jim Donofrio wrote: The vote has been open since Tue, 24 Apr 2012 03:56:24 GMT. The vote to graduate MRUnit passes: I guess you can add to this to board agena now, Chris. 9 +1's 0 0's 0 -1's IPMC +1 Patrick Hunt Chris Mattmann Jukka Zitting Tom White PPMC +1 Brock Noland Dave Beech Jim Donofrio Jarek Jarcec Cecho Others +1 Joey Echeverria On 05/04/2012 12:21 PM, Tom White wrote: +1 to graduate MRUnit. Cheers, Tom On Thu, May 3, 2012 at 7:31 PM, Jim Donofriodonofrio...@gmail.com wrote: We havent heard anything +1 or -1 from any IPMC members besides our mentors. Any thoughts on this vote? We released 0.9.0-incubating on Tuesday so we have completed 4 releases and added 4 new commiters since the beginning of incubation To resummarize the current vote is below: 7 +1's 0 0's 0 -1's IPMC +1 Patrick Hunt Chris Mattmann PPMC +1 Brock Noland Dave Beech Jim Donofrio Jarek Jarcec Cecho Others +1 Joey Echeverria On 04/28/2012 12:11 PM, Mattmann, Chris A (388J) wrote: Hi Jim, Yep, we need more VOTEs than 2 (3 I believe, but it would be nice to have a bit more -- though not required). There's been a lot of traffic on general@incbuator lately so folks are probably just busy. I would wait until tonight or tomorrow and poll for some more VOTEs on the VOTE thread. Once we get the required VOTEs, you can close the VOTE, and I can add the resolution to the board agenda. Cheers, Chris On Apr 28, 2012, at 6:35 AM, Jim Donofrio wrote: How many IPMC votes are required for graduation? We got 2 IPMC votes so far from mentors but havent gotten any on the general@ list. Since the vote has been open for more than 72 hours, does this mean we cant graduate yet? On 04/23/2012 11:56 PM, Jim Donofrio wrote: We havent heard anything on the DISCUSS thread since posting it over 72 hours ago so I am starting a VOTE thread following Chris Mattmann's recommendation. I will leave the vote open for 72 hours. The current vote is below copying from the community vote [2] that passed: 7 +1's 0 0's 0 -1's IPMC +1 Patrick Hunt Chris Mattmann PPMC +1 Brock Noland Dave Beech Jim Donofrio Jarek Jarcec Cecho Others +1 Joey Echeverria In the last MRUnit incubator report [1] the 3 blockers were: * Grow the community size and diversity * Make another incubating release * Construct an MRUnit website to replace the existing stub We have since: * Added 2 new committers/PPMC members * 0.9.0-incubating will get released soon, pending one more IPMC +1 * We have a new website From the beginning of incubation we have: * Added 4 new committers/PPMC members * Done 4 releases once 0.9.0-incubating is released soon, pending one more IPMC +1 * Created a real website [1]: http://incubator.apache.org/mrunit/ppmc/incubator_reports.html#march-2012 [2]: http://mail-archives.apache.org/mod_mbox/incubator-mrunit-dev/201204.mbox/%3C4F91FED1.2010609%40gmail.com%3E X. Establish the Apache MRUnit 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 related to unit testing Apache Hadoop map reduce jobs for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache MRUnit Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache MRUnit Project be and hereby is responsible for the creation and maintenance of software related to unit testing Apache Hadoop map reduce jobs; and be it further RESOLVED, that the office of Vice President, Apache MRUnit 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 MRUnit Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache MRUnit 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 MRUnit Project: * Brock Noland br...@apache.org * Patrick Hunt ph...@apache.org * Nigel Daley ni...@apache.org * Eric Sammer esam...@apache.org * Aaron Kimball kimba...@apache.org * Konstantin Boudnik c...@apache.org * Garrett Wu g...@apache.org * Jim Donofrio jdonof...@apache.org * Jarek Jarcec Cecho jar...@apache.org * Dave Beech dbe...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Brock Noland be appointed to the office of Vice President, Apache MRUnit, to serve in accordance with and subject to the direction
Re: [DISCUSS] BOM and supported platforms for Bigtop 0.4.0
On Fri, May 04, 2012 at 11:02AM, Patrick Hunt wrote: On Fri, May 4, 2012 at 9:47 AM, Owen O'Malley omal...@apache.org wrote: On Fri, May 4, 2012 at 8:58 AM, Patrick Hunt ph...@apache.org wrote: It's not the job of the incubator to create new rules, but rather to help podlings to graduation while following existing Apache guidelines. We aren't making new rules. We are trying to help the Bigtop project understand the rules about not releasing non-Apache software. There is a huge difference between depending on an artifact from another project and building and distributing non-Apache rpms in the project's /dist directory. They are not releasing non-Apache software. They are not forking an existing project. Bigtop's release artifact will contain packaging code which allows users to compile packages (deb, rpm, etc...) for this ASL licensed component, not the source/binaries of the component itself. Thank you Patrick to bringing this back again! It seems that this point keeps dropping on the floor all the time. BigTop releases are merely a source code for tools to produce and validate the integrity of software stacks. Let's keep in mind at the next round of deliberations. Packages are secondary and can be stored someplace else, because really anyone can produce them with ease using BigTop. If someone dislike component-A for one reason or another - it is easy to remote it from a particular release's BOM file. Cos It's very clear from http://www.apache.org/legal/resolved.html that what has been proposed is acceptable under existing Apache rules. Can you find a single instance other than the disagreement between Apache Lucene and Apache Commons where one project is distributing another project's rpms? Are there any other non-Apache rpms in /dist? Clearly the answer is a resounding NO. It would be a huge violation of the trust the incubator is putting in me as a mentor if I didn't block Bigtop's plan to do so. If the component made an objection to being included in Bigtop then I could see an argument to be made, that's not the case here. The opposite is true from what I've seen -- people want their software to be included so that users can more easily consume it. That's why they released their software under a less restrictive license in the first place. EOD existing Apache rules/license make no such distinction. Works under the following licenses may be included within Apache products (includes ASL). Patrick signature.asc Description: Digital signature
Re: Shepherds for podling reports
Hi Alan For sure your point may be valid, but the whole point, if you read the whole thread from the beginning, which I am sure you did, you will notice that Jukka mentioned that this is a start and will assess the effort and the whole plan after giving it sometime. And actually having other people looking into reports, from one side that will help mentors and from the other side it is as mentioned by Alex a fresh eye, who can poke around and ask questions or even provide more help. On Sat, May 5, 2012 at 8:50 PM, Alan D. Cabrera l...@toolazydogs.comwrote: On May 5, 2012, at 11:07 AM, Benson Margulies wrote: If you don't want to be a Shepherd, don't sign up. Yeah, I get that part. The board asked us to do a better job of reviewing reports and detecting mentor deficiencies. I get that too. This is a plan to accomplish that. My opinion about the plan stands. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
Fwd: Graduate Apache MRUnit from the Incubator
FYI Begin forwarded message: From: Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov Date: May 5, 2012 1:30:16 PM PDT To: bo...@apache.org bo...@apache.org Subject: Graduate Apache MRUnit from the Incubator Reply-To: bo...@apache.org Hi Board@, The Incubator PMC and MRUnit community have VOTEd to graduate Apache MRunit from the Incubator. The resolution is pasted below. Thanks! Cheers, Chris P.S. When the agenda is created, if no one has added it yet by then I'll do so. X. Establish the Apache MRUnit 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 related to unit testing Apache Hadoop map reduce jobs for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache MRUnit Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache MRUnit Project be and hereby is responsible for the creation and maintenance of software related to unit testing Apache Hadoop map reduce jobs; and be it further RESOLVED, that the office of Vice President, Apache MRUnit 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 MRUnit Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache MRUnit 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 MRUnit Project: * Brock Noland br...@apache.org * Patrick Hunt ph...@apache.org * Nigel Daley ni...@apache.org * Eric Sammer esam...@apache.org * Aaron Kimballkimba...@apache.org * Konstantin Boudnik c...@apache.org * Garrett Wu g...@apache.org * Jim Donofrio jdonof...@apache.org * Jarek Jarcec Cecho jar...@apache.org * Dave Beech dbe...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Brock Noland be appointed to the office of Vice President, Apache MRUnit, 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 MRUnit 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 MRUnit Project; and be it further RESOLVED, that the Apache MRUnit Project be and hereby is tasked with the migration and rationalization of the Apache Incubator MRUnit podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator MRUnit podling encumbered upon the Apache Incubator Project are hereafter discharged. ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Shepherds for podling reports
Thanks for replying with a thoughtful response. Jukka put forth the idea of shepherds as a proposal. I was merely replying to that proposal with my own considered ideas. I am encouraged about the enthusiasm but I feel that it blurs the responsibility of the mentor. Shepherding the shepherds of a podling, i.e. mentors, seems to me like the wrong way to go. It does add process. If one carefully re-reads posts to this thread there's all sorts of extra complexity being considered such as groupings of podlings and clearly defining the rules for cross-cutting projects, etc. Not that this is what's going to finally be adopted. Incubation is confusing enough as it is. Sprinkling more process, roles, and bureaucracy is not the solution to, my mind, mentors who need to be politely pinged. This is just my humble opinion. With that said, the shepherds have my sincere best wishes and I am happy to cooperate for those podlings where I am mentor. Thanks again for your kind reply. Regards, Alan On May 5, 2012, at 1:04 PM, Mohammad Nour El-Din wrote: Hi Alan For sure your point may be valid, but the whole point, if you read the whole thread from the beginning, which I am sure you did, you will notice that Jukka mentioned that this is a start and will assess the effort and the whole plan after giving it sometime. And actually having other people looking into reports, from one side that will help mentors and from the other side it is as mentioned by Alex a fresh eye, who can poke around and ask questions or even provide more help. On Sat, May 5, 2012 at 8:50 PM, Alan D. Cabrera l...@toolazydogs.comwrote: On May 5, 2012, at 11:07 AM, Benson Margulies wrote: If you don't want to be a Shepherd, don't sign up. Yeah, I get that part. The board asked us to do a better job of reviewing reports and detecting mentor deficiencies. I get that too. This is a plan to accomplish that. My opinion about the plan stands. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
Re: [DISCUSS] BOM and supported platforms for Bigtop 0.4.0
On Sat, May 5, 2012 at 1:32 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: On Fri, May 4, 2012 at 11:00 PM, Roman Shaposhnik r...@apache.org wrote: Perhaps this preso can help a bit: http://people.apache.org/~rvs/apache-bigtop2.pdf Perfect, thanks! Roman could you post this on the wiki? (looked but didn't notice it there) Patrick - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Shepherds for podling reports
Hi Alan... On Sun, May 6, 2012 at 12:05 AM, Alan D. Cabrera l...@toolazydogs.comwrote: Thanks for replying with a thoughtful response. Jukka put forth the idea of shepherds as a proposal. I was merely replying to that proposal with my own considered ideas. I am encouraged about the enthusiasm but I feel that it blurs the responsibility of the mentor. Shepherding the shepherds of a podling, i.e. mentors, seems to me like the wrong way to go. It does add process. If one carefully re-reads posts to this thread there's all sorts of extra complexity being considered such as groupings of podlings and clearly defining the rules for cross-cutting projects, etc. Not that this is what's going to finally be adopted. Incubation is confusing enough as it is. Sprinkling more process, roles, and bureaucracy is not the solution to, my mind, mentors who need to be politely pinged. This is just my humble opinion. With that said, the shepherds have my sincere best wishes and I am happy to cooperate for those podlings where I am mentor. Thanks again for your kind reply. You still have a point, but lets give it a try and adjust the idea along the way :), maybe come up with another idea if this didn't work out Regards, Alan On May 5, 2012, at 1:04 PM, Mohammad Nour El-Din wrote: Hi Alan For sure your point may be valid, but the whole point, if you read the whole thread from the beginning, which I am sure you did, you will notice that Jukka mentioned that this is a start and will assess the effort and the whole plan after giving it sometime. And actually having other people looking into reports, from one side that will help mentors and from the other side it is as mentioned by Alex a fresh eye, who can poke around and ask questions or even provide more help. On Sat, May 5, 2012 at 8:50 PM, Alan D. Cabrera l...@toolazydogs.com wrote: On May 5, 2012, at 11:07 AM, Benson Margulies wrote: If you don't want to be a Shepherd, don't sign up. Yeah, I get that part. The board asked us to do a better job of reviewing reports and detecting mentor deficiencies. I get that too. This is a plan to accomplish that. My opinion about the plan stands. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
