[VOTE] Graduate ManifoldCF as TLP
A vote was just completed in the ManifoldCF community on the following resolution: == 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 transferring content between repositories or search indexes, 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 ManifoldCF Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache ManifoldCF Project be and hereby is responsible for the creation and maintenance of open-source software for transferring content between repositories or search indexes, for distribution at no charge to the public. RESOLVED, that the office of Vice President, ManifoldCF 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 ManifoldCF Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache ManifoldCF 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 ManifoldCF Project: * Shinichiro Abe (shinich...@apache.org) * Erlend Garåsen(rid...@apache.org) * Piergiorgio Lucidi (piergior...@apache.org) * Hitoshi Ozawa (hoz...@apache.org) * Tommaso Teofili (tomm...@apache.org) * Simon Willnauer(sim...@apache.org) * Karl Wright (kwri...@apache.org) * Jukka Zitting (ju...@apache.org) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Karl Wright be appointed to the office of Vice President, ManifoldCF, 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 ManifoldCF Project be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the ManifoldCF Project; and be it further RESOLVED, that the initial Apache ManifoldCF Project be and hereby is tasked with the migration and rationalization of the Apache Incubator ManifoldCF podling; and be it further RESOLVED, that all responsibility pertaining to the Apache Incubator ManifoldCF podling encumbered upon the Apache Incubator PMC are hereafter discharged. == The vote passed with three IPMC members (Jukka Zitting, Tommaso Teofili, and Karl Wright). The thread ID for the vote was: be9e17b9-4b38-4611-8047-4bf9caea8...@gmail.com Please vote in favor (+1) or against (-1) this resolution. Thanks, Karl - 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, On Thu, May 3, 2012 at 11:14 PM, Dave Fisher dave2w...@comcast.net wrote: This looks like a mind expanding activity. I added my name for a maximum of 2 per month. Great, thanks! Would you mind taking a look at for example Nuvem and Wink this month? Or pick some other yet unclaimed reports. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Apache MRUnit from Incubator
Hi, On Fri, May 4, 2012 at 4:31 AM, Jim Donofrio donofrio...@gmail.com wrote: We havent heard anything +1 or -1 from any IPMC members besides our mentors. Any thoughts on this vote? +1 to graduate Note that when you reply to a message and only change the [...] prefix, at least GMail thinks it's just a continuation of the same discussion and not a separate new thread. Thus the user interface still shows the message under the original [DISCUSS] subject, which together with the your wording of I am starting a VOTE thread (instead of something like this is the VOTE) left at least me waiting for a separate thread. The mistake obviously is mine and of anyone else using GMail or a similar client that makes it hard to spot such subject changes, but probably explains why you got so little IPMC feedback. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT][VOTE] Release Apache Airavata 0.2-incubating
The 72 hour voting period is passed and the vote is now closed. Thanks to everyone who took time to review the release. With the three IPMC member votes (2 of them mentors) and 5 PPMC votes the vote succeeds. IPMC member voting record: * Ate Douma: +1 * Chris Mattmann : +1 Srinath Perera : +1 *Denotes an IPMC member vote cast on the airavata-dev list Thanks, Suresh On May 1, 2012, at 9:54 AM, Suresh Marru wrote: This is the first incubator release for Apache Airavata, with the artifacts being versioned as 0.2-incubating. We are requesting at least one additional IPMC member vote, as we have received 2 binding Mentors/IPMC +1 votes during the release voting on airavata-dev: Community VOTE RESULT Thread : http://markmail.org/thread/5vcfvyezsfzzgfd2 Mentors/IPMC member votes from the Airavata-Dev list: Ate Douma: +1 Chris Mattmann: +1 Detailed change log/release notes: https://svn.apache.org/repos/asf/incubator/airavata/tags/airavata-0.2-incubating/RELEASE_NOTES All Release Artifacts: http://people.apache.org/builds/incubator/airavata/0.2-incubating/RC6/ PGP release keys (signed using 617DDBAD): https://svn.apache.org/repos/asf/incubator/airavata/KEYS Specific URL's: SVN source tag (1330645): https://svn.apache.org/repos/asf/incubator/airavata/tags/airavata-0.2-incubating/ Source release: http://people.apache.org/builds/incubator/airavata/0.2-incubating/RC6/airavata-0.2-incubating-source-release.zip Binary Artifacts: http://people.apache.org/builds/incubator/airavata/0.2-incubating/RC6/apache-airavata-0.2-incubating-bin.tar.gz http://people.apache.org/builds/incubator/airavata/0.2-incubating/RC6/apache-airavata-0.2-incubating-bin.zip Maven staging repo: https://repository.apache.org/content/repositories/orgapacheairavata-108/ Please verify the artifacts and vote. The vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why)
Re: [DISCUSS] BOM and supported platforms for Bigtop 0.4.0
It's not the job of the incubator to create new rules, but rather to help podlings to graduation while following existing Apache guidelines. It's very clear from http://www.apache.org/legal/resolved.html that what has been proposed is acceptable under existing Apache rules. Bigtop is building on/around ASL licensed software (packaging, iteroperability tests, utilities, etc...), much like many other Apache projects, much like other distributions do with Apache's own projects/software. I don't see any reason to create new rules which limit the podling's ability to include compatibly licensed software in their releases. (as long as they follow the licenses of said software) Patrick On Thu, May 3, 2012 at 4:30 PM, Bruno Mahé br...@cloudera.com wrote: Hi, Please see my reply inline. On 05/03/2012 04:00 PM, Owen O'Malley wrote: On Thu, May 3, 2012 at 12:01 PM, Bruno Mahé bm...@apache.org wrote: As a mentor of the Bigtop project, I don't see it as acceptable for an Apache project to distribute binaries of non-Apache software. If the owners of the Hue project decide to donate it to Apache and it had been released by Apache, then it would be acceptable. I'm strictly -1 on releasing any version of Bigtop with Hue or any other non-Apache software as part of the release. -- Owen As part of mentoring Apache Bigtop (incubating) project, it would also be greatly appreciated if you would explain why this -1. Apache Bigtop (incubating) does not and will not include anything that does not belong to the Apache Foundation. So I am really confused as to why this strong reaction. The strong reaction is because Roman was proposing a Bigtop release with rpms and debs for non-Apache projects. That is a non-starter. Apache will not distribute non-Apache projects. Saying that Bigtop does not release the projects that it incorporates is not justified given the fact that Bigtop is putting rpms of each of the incorporated projects into /dist/incubator/bigtop. The 2.9GB size of the latest Bigtop release has already caused infrastructure significant headaches. Seems like you are still (this is not the first time this is explained to you) conflating Apache releases on which members vote on, with convenience artefacts. Apache Bigtop (incubating) releases are not the packages. Apache Bigtop (incubating) releases are Apache Bigtop (incubating) source code. RPMs and DEBs are convenience artefact. If they are not that convenient to the Apache Foundation, I don't see the issue with not distributing the ones that are not convenient. As far as I know, Apache Infra was only asking for heads up. Which we will provide and we will pay attention to work more closely with them. I also fail to see the relationship between the size of the convenience artefacts and the bill of materials for the coming release of Apache Bigtop (incubating), which I repeat only contains Apache Bigtop (incubating) source code. So now we have establish that you issue is about the convenience artefacts, I don't see any remaining issue with Apache Bigtop (incubating) releases. The convenience artefact may pull Hue in, but this is in no way different from Apache Hadoop pulling in Google protocol buffer or Google guava. So again, how is this different? Is Apache Hadoop going to avandon Google Protocolbuffer? There is a big difference between referencing external projects that are required for your project's functionality and incorporating non-Apache projects into your project and publishing releases of them using independent artifacts. When the user installs a Hadoop rpm, the protobuf.jar is there under the hood, but is considered an implementation detail that is required for Hadoop to run. I'd complain similarly if Hadoop was downloading protobuf tarballs, making changes to protobuf, making protobuf rpms with those changes, and publishing those rpms on Apache's servers. In any case, there is still distribution of a non-Apache project's artefacts by both projects. You either distribute artefacts of it, or you don't. Here the end goal is not to provide packages, but a deployable big data stack. Packages are just a mean to an end. We don't distribute upstream projects, they are dependencies. However, it goes deeper than than that. If the user installs Bigtop's rpms and hits a bug do they contact Hue or Bigtop? Furthermore, I'm sure the links that are displayed when you run Bigtop's Hue point off to Cloudera's bug and support system. That kind of branding is not ok for an Apache project. Hue is not even integrated into Apache Bigtop (incubating). So let's cross that bridge when we get there. And in any case, this is an issue that can be fixed trivially, so I wouldn't make it a blocker. But beyond that, we don't patch anything. So any product issue would come from the product. Any integration issue would be an Apache Bigtop (incubating) issue. The same way with Apache Hadoop. No matter
Re: [VOTE] Graduate Apache MRUnit from Incubator
+1 to graduate MRUnit. Cheers, Tom On Thu, May 3, 2012 at 7:31 PM, Jim Donofrio donofrio...@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 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
Re: Shepherds for podling reports
Hi Jukka... I also added myself, but as being a Mentor of CloudStack I would rather take (shepherdZ: DeltaSpike, Nuvem, Wink) while Dave Fisher takes (shepherdY: CloudStack, NPanday, VCL) Dave would you please ACK that ? On Fri, May 4, 2012 at 2:54 PM, Jukka Zitting jukka.zitt...@gmail.comwrote: Hi, On Thu, May 3, 2012 at 11:14 PM, Dave Fisher dave2w...@comcast.net wrote: This looks like a mind expanding activity. I added my name for a maximum of 2 per month. Great, thanks! Would you mind taking a look at for example Nuvem and Wink this month? Or pick some other yet unclaimed reports. BR, Jukka Zitting - 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 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. 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. -- Owen - 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
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. 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Shepherds for podling reports
In the Board agenda, we have a line where each Director can state they have reviewed the report (before the meeting). They can also append queries and comments. Little mini-discussions kinda happen in those comments. Point here is: provide a similar location for IPMC members (including shepherds) to list their review/approval. There is no strict need to divvy the reviews. Jukka is doing that as a transitionary measure until people get into it. IOW, there is no big deal if both Mohammad and Dave review Nuvem and Wink. The real goal is at least one or more IPMC names associated with each podling report. (beyond mentor signoffs?) Another way to say it: Mohammad: go ahead and review all six. No big deal if there is overlap. (and if you believe six is a problem, then avoid becoming a Director; we review something like 40 to 50... month after month... :-P) It is this early review and signoff that is behind the need for receiving reports in advance of the meeting. The hope is that all reports have been reviewed by (all) the Directors beforehand, so we don't have to discuss them in detail during the meeting. We stop and discuss when a Director leaves a flag/query/concern in the report comments. Cheers, -g On May 4, 2012 12:35 PM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: Hi Jukka... I also added myself, but as being a Mentor of CloudStack I would rather take (shepherdZ: DeltaSpike, Nuvem, Wink) while Dave Fisher takes (shepherdY: CloudStack, NPanday, VCL) Dave would you please ACK that ? On Fri, May 4, 2012 at 2:54 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Thu, May 3, 2012 at 11:14 PM, Dave Fisher dave2w...@comcast.net wrote: This looks like a mind expanding activity. I added my name for a maximum of 2 per month. Great, thanks! Would you mind taking a look at for example Nuvem and Wink this month? Or pick some other yet unclaimed reports. BR, Jukka Zitting - 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: Shepherds for podling reports
On May 3, 2012, at 6:18 AM, Jukka Zitting wrote: Hi, OK, so let's see how this works out in practice. We have 19 podling reports to review by next Wednesday (Ambari is still empty). To keep the required effort down to a reasonable level, I divided these to six slots of three reports each and divided them among me, Ross and Matt and three other potential volunteers. I'll take care of the outlying mini-report of the retiring Zeta Components. Since Ross is a mentor of four of the podlings that reported this month (nice!), I ideally would have excused him from all extra review duty this month. But since we're a bit low on volunteers (and Ross seemed eager enough :-), I decided to assign two reports to him and take the extra one myself. I also took Ross' stated interest into mobile stuff into account by assigning PhotArk (that's nowadays trying to become a HTML5/Cordova mobile app) to him before dividing the remaining reports in sequence. The resulting TODOs are (see also the May2012 wiki page): - jukka: Airavata, Droids, SIS, Wookie, Zeta Components - rgardler: Amber, PhotArk - mfranklin: Ambari, Flex, Stanbol - shepherdX: Clerezza, Lucene.NET, Syncope - shepherdY: CloudStack, NPanday, VCL - shepherdZ: DeltaSpike, Nuvem, Wink Even though I'm the mentor for VCL I now have to sign up to be a shepherd too? Regards, Alan - 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
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
Re: Shepherds for podling reports
On Fri, May 4, 2012 at 2:49 PM, Alan D. Cabrera l...@toolazydogs.com wrote: On May 3, 2012, at 6:18 AM, Jukka Zitting wrote: ... The resulting TODOs are (see also the May2012 wiki page): - jukka: Airavata, Droids, SIS, Wookie, Zeta Components - rgardler: Amber, PhotArk - mfranklin: Ambari, Flex, Stanbol - shepherdX: Clerezza, Lucene.NET, Syncope - shepherdY: CloudStack, NPanday, VCL - shepherdZ: DeltaSpike, Nuvem, Wink Even though I'm the mentor for VCL I now have to sign up to be a shepherd too? Nope. Jukka is looking for *additional* people to review the reports at the IPMC-level. You can continue to help VCL with their community and their podling report. Some additional people will review and look for concerns and action items for the IPMC to work on (feedback/actions for podlings, or meta-level IPMC issues, etc). Then Jukka bundles all that up and pops it up to the Board. Cheers, -g - 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 4, 2012, at 9:35 AM, Mohammad Nour El-Din wrote: Hi Jukka... I also added myself, but as being a Mentor of CloudStack I would rather take (shepherdZ: DeltaSpike, Nuvem, Wink) while Dave Fisher takes (shepherdY: CloudStack, NPanday, VCL) Dave would you please ACK that ? Sorry Mohammad, I had already reviewed Wink and Nuvem. I only have time for two. Wink: From activity it looks like this project should have graduated into a TLP a year ago. It looks like a mature and well developed project. I don't understand why they think that they should become a subproject of Geronimo or Tuscany. They are a mature and useful tool. It's time for this bird to fly on its own wings. They are an example of a small, viable community that contributes to more than one other community. Podling Namesearch and graduation should be next. For my $job, I'll likely ask my developers to take a look to see if this is a useful tool for some us. Nuvem: It is really hard to know what this project is trying to do other than be a common API for Cloud Apps. Very low activity. Apparently no users. A little pick up in dev activity recently. More information on the podling site might attract a few more developers. No release. This thread shows that the developers are aware: http://mail-archives.apache.org/mod_mbox/incubator-nuvem-dev/201201.mbox/%3CCANzUfzemiQBzxt%3DgFFM7tMBdyMv-q7H%2BvBB2xR0GxECs5y17KQ%40mail.gmail.com%3E I suggest the Nuvem PPMC focus on explaining precisely what they are trying to build. Regards, Dave On Fri, May 4, 2012 at 2:54 PM, Jukka Zitting jukka.zitt...@gmail.comwrote: Hi, On Thu, May 3, 2012 at 11:14 PM, Dave Fisher dave2w...@comcast.net wrote: This looks like a mind expanding activity. I added my name for a maximum of 2 per month. Great, thanks! Would you mind taking a look at for example Nuvem and Wink this month? Or pick some other yet unclaimed reports. BR, Jukka Zitting - 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 - 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, I don't understand the BigTop use cases and release model in too much detail to have very specific or hard opinions on this, but here's a few high-level observations that hopefully are useful for this discussion: * AFAICT there's no immediate release that's being blocked by this discussion, so everyone can calm down. An issue was brought up, it's being discussed and I'm sure we'll soon enough have a solution that everyone is happy about. * It sounds like BigTop is doing something that few Apache projects have done before. Thus it's fine to question whether and to what extent existing rules apply. However, at the same time it's good to acknowledge that new rules and consensus on a new interpretation of existing rules may be needed for something like this. It's natural for this process to take some time and involve some misunderstandings along the way. * The convenience binaries many projects are providing are normally the result of building the respective source release (together with any required third party dependencies). As a general rule it should be possible for anyone to reproduce equivalent binaries by following the build instructions included in the source release. * As a recent addition, some projects have started providing also convenience packages containing such dependencies required by the source build as described above. In both cases the contents of all such binary packages should be properly signed and contain appropriate LICENSE and NOTICE files. * As far as I can tell from the discussion, the BigTop repos directory [1] doesn't neatly fit into either of the above categories. I guess the key question here is whether the purpose of BigTop is to be a particular, tested combination of upstream projects or rather a tool for testing and building such combinations. (Or perhaps something else entirely?) * 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. * If the latter, it seems to me that it isn't BigTop that should be distributing the packages in [1]. Instead each upstream project should using BigTop as a tool to produce such packages as a part of their own release processes. * 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. [1] http://www.apache.org/dist/incubator/bigtop/bigtop-0.3.0-incubating/repos/ BR, Jukka Zitting - 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 Fri, May 4, 2012 at 8:27 PM, Greg Stein gst...@gmail.com wrote: In the Board agenda, we have a line where each Director can state they have reviewed the report (before the meeting). They can also append queries and comments. Little mini-discussions kinda happen in those comments. Point here is: provide a similar location for IPMC members (including shepherds) to list their review/approval. There is no strict need to divvy the reviews. Jukka is doing that as a transitionary measure until people get into it. IOW, there is no big deal if both Mohammad and Dave review Nuvem and Wink. The real goal is at least one or more IPMC names associated with each podling report. (beyond mentor signoffs?) Another way to say it: Mohammad: go ahead and review all six. No big deal if there is overlap. (and if you believe six is a problem, then avoid becoming a Director; we review something like 40 to 50... month after month... :-P) Well, I can start rehearsing with 6 reports preparing for the 40-50 ones :P It is this early review and signoff that is behind the need for receiving reports in advance of the meeting. The hope is that all reports have been reviewed by (all) the Directors beforehand, so we don't have to discuss them in detail during the meeting. We stop and discuss when a Director leaves a flag/query/concern in the report comments. Cheers, -g On May 4, 2012 12:35 PM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: Hi Jukka... I also added myself, but as being a Mentor of CloudStack I would rather take (shepherdZ: DeltaSpike, Nuvem, Wink) while Dave Fisher takes (shepherdY: CloudStack, NPanday, VCL) Dave would you please ACK that ? On Fri, May 4, 2012 at 2:54 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Thu, May 3, 2012 at 11:14 PM, Dave Fisher dave2w...@comcast.net wrote: This looks like a mind expanding activity. I added my name for a maximum of 2 per month. Great, thanks! Would you mind taking a look at for example Nuvem and Wink this month? Or pick some other yet unclaimed reports. BR, Jukka Zitting - 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
Re: [DISCUSS] BOM and supported platforms for Bigtop 0.4.0
On Fri, May 4, 2012 at 11:54 AM, Greg Stein gst...@gmail.com wrote: 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. Sorry for the incorrect tla usage. Will do. Patrick - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Mesos 0.9.0-incubating (RC5)
Hi, On Fri, Apr 27, 2012 at 8:47 PM, Benjamin Hindman benjamin.hind...@gmail.com wrote: Can you elaborate on this? Do you mean recruit active participants from the Mesos community into the IPMC? Or do you mean recruit people from the IPMC to be more active in Mesos? Ideally each podling should have at least three active mentors who can make sure that the required threshold of at least three PMC votes for a release is reached. If that's not the case (as it sounds like), there are a few options: * Ask help from other IPMC members to review the particular release candidate. If you're otherwise doing fine, this should be an OK workaround until you graduate. * Find one or more new mentors to replace inactive ones. Based on past experience this can be a bit difficult, but definitely worth a try. * If the above solutions fail, i.e. the Incubator PMC is unable to provide the help and oversight you deserve, we can also promote deserving PPMC members to the IPMC so that they have binding vote on things like releases. This works, but since that's more or less equivalent to saying that at least a part of the PPMC is already able to oversee itself, so one could well argue that a better solution would be to simply let the podling graduate. None of these solutions are really ideal, which is why I'm really hoping to find better ways for us to proactively identify and find solutions to cases where a podling no longer has enough active mentors. Unfortunately that won't help with the pressing matter of your release vote. Any IPMC members around who'd be willing to lend Mesos a hand and review this release candidate? Unless anyone beats me to it (please do! :-), I'll take care of it later in the weekend. 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
Hi Jukka! Thanks a million for chiming in. On Fri, May 4, 2012 at 12:52 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, I don't understand the BigTop use cases Perhaps this preso can help a bit: http://people.apache.org/~rvs/apache-bigtop2.pdf * 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. All of the distributed convenience artifacts have Apache License and this policy will remain. Staring from Bigtop 0.4.0 release we are going to also take great care in coordinating release of our convenience artifacts with Apache Software Foundation's Infrastructure team in order to avoid surprises and reduce strain on the mirroring infrastructure. Please let me know if, from your point of view, the above alleviates the concerns that have been expressed on this list. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Giraph to a TLP
Hi, On Fri, May 4, 2012 at 11:11 PM, Owen O'Malley omal...@apache.org wrote: Giraph has been been in incubator for the last year and I think it is ready to graduate. That's my understanding as well: http://markmail.org/message/rxroucqrf4wowox7 Is Giraph ready to graduate? +1, yes 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
Jukka, Thanks for your response, this is very helpful. I have a couple of questions/clarifications inlined. On May 4, 2012, at 12:52 PM, Jukka Zitting wrote: * As far as I can tell from the discussion, the BigTop repos directory [1] doesn't neatly fit into either of the above categories. I guess the key question here is whether the purpose of BigTop is to be a particular, tested combination of upstream projects or rather a tool for testing and building such combinations. (Or perhaps something else entirely?) * 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. 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. * If the latter, it seems to me that it isn't BigTop that should be distributing the packages in [1]. Instead each upstream project should using BigTop as a tool to produce such packages as a part of their own release processes. * 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. Alan. [1] http://www.apache.org/dist/incubator/bigtop/bigtop-0.3.0-incubating/repos/ BR, Jukka Zitting - 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
