Re: [DISCUSS] BOM and supported platforms for Bigtop 0.4.0
On Mon, May 7, 2012 at 9:48 PM, Bruno Mahé bm...@apache.org wrote: ... It seems that we're talking about this location: http://www.apache.org/dist/incubator/bigtop/bigtop-0.3.0-incubating/ Again, we don't distribute non-Apache software, I didn't find any non-Apache software in the location noted above. as well as we don't distribute other Apache software either. I found a bunch of Apache software in there. So I'd say you're distributing it. (not that I believe that is a problem, but let's try and get things straight here) Since you keep on doing this mistake, there is surely a misunderstanding. So it would probably be easier if you could point us to other Apache (or non-Apache) software being distributed as part as any Apache Bigtop (incubating) releases on which members have voted on? I can see anybody looking at that URL location believing that you're distributing both Bigtop *AND* other Apache software. If you're using a different definition of distributing, then we need to resolve that situation. I see lots of ASF software being distributed via that URL. And again, Apache releases are what people vote on. not the convenience artefacts which are there for convenience and are not voted on. So I still don't see any reason to not withdraw your -1 since your only issue seems to be related to the dependencies in the convenience artefacts (which is standard practice, even within Apache Hadoop) It is true that votes only apply to Bigtop releases and not those artifacts under bigtop-0.3.0-incubating/repos/. It is also true that (in normal PMC operation) it is not possible to veto a release. I have no strong opinion, but would believe the that a podling can also make a release with three IPMC +1 votes (and, again, vetoes do not apply). Note: IPMC votes, not PPMC votes. If somebody raises a -1, then I suspect getting those IPMC votes might be difficult until the concern is discussed. Regarding the release artifacts: I don't have any strong opinions right now. I can see the confusion with them all in the same location. I can also see that Infra should probably get involved in some way to deal with mirroring issues and to somehow distinguish, verify, and validate these binary artifacts. ... Cheers, -g - 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 Mon, May 7, 2012 at 11:08 PM, Greg Stein gst...@gmail.com wrote: On Mon, May 7, 2012 at 9:48 PM, Bruno Mahé bm...@apache.org wrote: ... It seems that we're talking about this location: http://www.apache.org/dist/incubator/bigtop/bigtop-0.3.0-incubating/ Again, we don't distribute non-Apache software, I didn't find any non-Apache software in the location noted above. They are proposing adding Hue, which is a Apache licensed project on Github. I raised the concern when they stated the plan, not after the release. -- 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
First, thank you very much for taking the time to write a thoughtful reply. On 05/08/2012 02:08 PM, Greg Stein wrote: On Mon, May 7, 2012 at 9:48 PM, Bruno Mahé bm...@apache.org wrote: ... It seems that we're talking about this location: http://www.apache.org/dist/incubator/bigtop/bigtop-0.3.0-incubating/ Again, we don't distribute non-Apache software, I didn't find any non-Apache software in the location noted above. as well as we don't distribute other Apache software either. I found a bunch of Apache software in there. So I'd say you're distributing it. (not that I believe that is a problem, but let's try and get things straight here) But all these files are convenience artefacts. They are not part of a release. I don't see any difference from the Google protocolbuffer binary artefacts found in Apache Hadoop convenience artefacts. Except that instead of all of them being hidden into a giant tarball, they are organized openly inside a repository. Since you keep on doing this mistake, there is surely a misunderstanding. So it would probably be easier if you could point us to other Apache (or non-Apache) software being distributed as part as any Apache Bigtop (incubating) releases on which members have voted on? I can see anybody looking at that URL location believing that you're distributing both Bigtop *AND* other Apache software. If you're using a different definition of distributing, then we need to resolve that situation. I see lots of ASF software being distributed via that URL. I don't think I am using a different definition of distributing. But I would like to stress out that I make a clear distinction between what is distributed as part of an Apache release and what is distributed as part of a convenience artefact. Here is a quote from Owen: I'm strictly -1 on releasing any version of Bigtop with Hue or any other non-Apache software as part of the release. And we truly do not include anything else then Apache Bigtop (incubating) in Apache Bigtop (incubating) releases. And as far as I can tell, the issue Owen is having is related to convenience artefacts, not releases. We use these upstream projects as dependencies. We don't distribute directly other software in the convenience artefacts of Apache Bigtop (incubating). The output of Apache Bigtop (incubating) can be quite unusual since it is a deployable production quality big data stack. So we need to consider the project as a whole, not just one single part. The release provides the recipes to enable you to build and/or customize such a stack. These recipes include the recipes to build packages, virtual machines, integration, performance and validation tests as well as recipes (puppet recipes) to deploy such stack. But we also provide a validated stack as convenience artefacts. And again, Apache releases are what people vote on. not the convenience artefacts which are there for convenience and are not voted on. So I still don't see any reason to not withdraw your -1 since your only issue seems to be related to the dependencies in the convenience artefacts (which is standard practice, even within Apache Hadoop) It is true that votes only apply to Bigtop releases and not those artifacts under bigtop-0.3.0-incubating/repos/. It is also true that (in normal PMC operation) it is not possible to veto a release. I have no strong opinion, but would believe the that a podling can also make a release with three IPMC +1 votes (and, again, vetoes do not apply). Note: IPMC votes, not PPMC votes. If somebody raises a -1, then I suspect getting those IPMC votes might be difficult until the concern is discussed. Regarding the release artifacts: I don't have any strong opinions right now. I can see the confusion with them all in the same location. I can also see that Infra should probably get involved in some way to deal with mirroring issues and to somehow distinguish, verify, and validate these binary artifacts. ... What confuses me the most, is that Owen's issue is with the convenience artefacts, not with the release itself. So there is no real reason to -1 releases if they are not the issue. And if I understand correctly from what you are saying, there is really nothing preventing us from continuing, providing the Apache Bigtop (incubating) community is in agreement (ie. enough +1 on tickets and enough +1 from IPMC members for releases). Although I would rather end up with everyone agreeing. But in the worst case scenario, we can always stop publishing convenience artefacts as part of Apache releases, and host these convenience artefacts outside of the Apache Infrastructure as contributors and bypass all these concerns. Note also that Infra has already been involved. Thanks, Bruno - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail:
Re: [DISCUSS] BOM and supported platforms for Bigtop 0.4.0
Hi, On Tue, May 8, 2012 at 8:38 AM, Owen O'Malley omal...@apache.org wrote: They are proposing adding Hue, which is a Apache licensed project on Github. Does Hue match the guidelines in http://www.apache.org/legal/resolved.html? If yes, then it's fine by ASF policy for an Apache project to include it. Is there some other reason why BigTop shouldn't be adding Hue? 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
On Tue, May 8, 2012 at 3:03 AM, Bruno Mahé bm...@apache.org wrote: First, thank you very much for taking the time to write a thoughtful reply. On 05/08/2012 02:08 PM, Greg Stein wrote: ... as well as we don't distribute other Apache software either. I found a bunch of Apache software in there. So I'd say you're distributing it. (not that I believe that is a problem, but let's try and get things straight here) But all these files are convenience artefacts. They are not part of a release. Sure. I don't see any difference from the Google protocolbuffer binary artefacts found in Apache Hadoop convenience artefacts. Except that instead of all of them being hidden into a giant tarball, they are organized openly inside a repository. I don't care what other projects do. We're talking about Bigtop right now. (I can comment on Hadoop/protobuf, but will not do so in this thread) Since you keep on doing this mistake, there is surely a misunderstanding. So it would probably be easier if you could point us to other Apache (or non-Apache) software being distributed as part as any Apache Bigtop (incubating) releases on which members have voted on? I can see anybody looking at that URL location believing that you're distributing both Bigtop *AND* other Apache software. If you're using a different definition of distributing, then we need to resolve that situation. I see lots of ASF software being distributed via that URL. I don't think I am using a different definition of distributing. But I would like to stress out that I make a clear distinction between what is distributed as part of an Apache release and what is distributed as part of a convenience artefact. Agreed. There *is* a distinction. My point was that placing them both in the same directory (URL; whatever) makes it *appear* they are combined. And based on that appearance, people are (empirically demonstrated) getting confused. But stepping back a little bit. You are distributing two things: 1) Apache Bigtop (incubating) 2) Convenience artifacts Do you agree with that? Here is a quote from Owen: I'm strictly -1 on releasing any version of Bigtop with Hue or any other non-Apache software as part of the release. And we truly do not include anything else then Apache Bigtop (incubating) in Apache Bigtop (incubating) releases. And as far as I can tell, the issue Owen is having is related to convenience artefacts, not releases. Fine. Relax. So he misspoke in one single sentence. It happens. Move on, already. I will offer a piece of advice here: if you ever write an email with somebody's name in it, then please step back and reconsider. A technical/procedural/whatever discussion *does not* require people's names to be productive. Speak to the issue at hand, the problem being raised, the disconnect that has occurred. Continuing to bring Owen's name into this discussion is a complete distraction. In short: omit names. It really helps. We use these upstream projects as dependencies. We don't distribute directly other software in the convenience artefacts of Apache Bigtop (incubating). You distribute *some* software. I don't know that it matters what that software is, but simply the fact that you're distributing two things: Bigtop, and other stuff. If you agree with that, then let's talk about people's concerns with the other stuff part. (I don't think anybody has raised any issue with the Apache Bigtop (incubating) part of the release, so assuming that's true, let's just please drop that part, stop harping on it, and move on to the relevant part of the discussion) ... It is true that votes only apply to Bigtop releases and not those artifacts under bigtop-0.3.0-incubating/repos/. It is also true that (in normal PMC operation) it is not possible to veto a release. I have no strong opinion, but would believe the that a podling can also make a release with three IPMC +1 votes (and, again, vetoes do not apply). Note: IPMC votes, not PPMC votes. If somebody raises a -1, then I suspect getting those IPMC votes might be difficult until the concern is discussed. Regarding the release artifacts: I don't have any strong opinions right now. I can see the confusion with them all in the same location. I can also see that Infra should probably get involved in some way to deal with mirroring issues and to somehow distinguish, verify, and validate these binary artifacts. What confuses me the most, is that Owen's issue is with the convenience artefacts, not with the release itself. So there is no real reason to -1 releases if they are not the issue. Whatever. Let's assume he misspoke and restart the conversation instead of rehashing this over and over. Let's not try and state what he should or should not do, and whether he has any real reason to do so. And if I understand correctly from what you are saying, there is really nothing preventing us from continuing, providing the Apache Bigtop (incubating)
Re: [DISCUSS] BOM and supported platforms for Bigtop 0.4.0
Greg Stein wrote on Tue, May 08, 2012 at 03:32:32 -0400: On Tue, May 8, 2012 at 3:03 AM, Bruno Mahé bm...@apache.org wrote: Note also that Infra has already been involved. Yup. Saw. What's the infra issue here? I see no new mentions of bigtop on infra list in the last day - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating
Hi Sebb, you can find my replies embedded below. I am going to send a [CANCEL] reply to this thread, remove Nexus staging repo and SVN tag, fix everything and start again the release process for 1.0.0-RC1-incubating from scratch. Regards. On 07/05/2012 14:47, sebb wrote: On 7 May 2012 10:38, Francesco Chicchiriccòilgro...@apache.org wrote: I've created a 1.0.0-RC1-incubating release, with the following artifacts up for a vote: SVN source tag (r1333797): https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/ There must be an Incubator DISCLAIMER. This is required in all distributions (and on the web-site, which has been done). Please add the DISCLAIMER file to SVN and make sure it gets added to all archives. Understood. The NOTICE file is very long; I suspect that not all of the entries are *required*. The LICENSE and NOTICE files were written against the parent POM: all the dependencies with scope != test were considered, then. For example, cglib is available under AL 2.0, so I don't think it needs to be mentioned in the NOTICE file. All the AL 2.0 dependencies not from ASF were added anyway to the LICENSE and NOTICE files; we preferred to have these two files with the same entries, even though for different purposes. The LICENSE file should mention all software included in the release. In both cases, the NL files should only mention software that is actually included in the release. The LICENSE file misspells Javassist. Already fixed in trunk: thanks for reporting! Maven staging repo: https://repository.apache.org/content/repositories/orgapachesyncope-034/ The syncope-root POM does not use the Apache POM as parent. ASF product Poms should normally chain back to a version of the Apache pom to ensure that the correct settings are established. [the other poms do chain back to the Apache pom] If there is a good reason for not doing so, it should be documented in the pom, and care must be taken to ensure that the required elements are copied from the Apache pom. As you might have noticed, the root POM is not the parent POM, and parent POM does extend Apache POM 10. The root POM is only functional to perform some actions: anyway we'll try to make it extend Apache POM as well. FYI, we have already planned to normalize POM structure in next major release (see SYNCOPE-79 on JIRA) Source release (checksums and signatures are available at the same location): https://repository.apache.org/content/repositories/orgapachesyncope-034/org/apache/syncope/syncope-root/1.0.0-RC1-incubating/syncope-root-1.0.0-RC1-incubating-source.tar.gz https://repository.apache.org/content/repositories/orgapachesyncope-034/org/apache/syncope/syncope-root/1.0.0-RC1-incubating/syncope-root-1.0.0-RC1-incubating-source.zip PGP release keys (signed using 273DF287): http://www.apache.org/dist/incubator/syncope/KEYS This has been voted through on the syncope-...@incubator.apache.org mailing list [1], and now requires a vote on general@incubator.apache.org Votes already cast (on syncope-dev): +1 (binding) * Francesco Chicchiriccò * Fabio Martelli * Marco Di Sabatino Di Diodoro * Massimiliano Perrone * Colm O hEigeartaigh (IPMC member) * Emmanuel Lécharny (IPMC member) * Simone Tripodi +1 (non binding) * Denis SIgnoretto * Riccardo Costa Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Best regards. [1] http://syncope-dev.1063484.n5.nabble.com/RESULT-VOTE-Apache-Syncope-1-0-0-RC1-incubating-4th-attempt-tt5690572.html -- Francesco Chicchiriccò Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/ - 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 Tue, May 8, 2012 at 12:30 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Tue, May 8, 2012 at 8:38 AM, Owen O'Malley omal...@apache.org wrote: They are proposing adding Hue, which is a Apache licensed project on Github. Does Hue match the guidelines in http://www.apache.org/legal/resolved.html? If yes, then it's fine by ASF policy for an Apache project to include it. Is there some other reason why BigTop shouldn't be adding Hue? Hue is Apache licensed, so that isn't an issue. The issue is that Bigtop is planning on distributing non-Apache software for the primary purpose of providing it to their users. It seems to me pretty fundamental that Apache projects should only distribute Apache software except as a dependency. Bigtop is only including Hue to provide it to their users with no dependency at all. It would be great if Cloudera were to contribute Hue to Apache. Unless they do, I really don't think it is appropriate for us to distribute standalone binary packages of their project from Apache's servers. -- Owen - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[CANCELED] [VOTE] Apache Syncope 1.0.0-RC1-incubating
Hi all, the vote [1] is canceled since the provided release artifacts did not meet all requirements, as highlighted in the mentioned mail thread by Sebb. I am going to delete the staging repository https://repository.apache.org/content/repositories/orgapachesyncope-034/ and the SCM tag https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/ Regards. [1] http://mail-archives.apache.org/mod_mbox/incubator-general/201205.mbox/%3C4FA7981E.8030403%40apache.org%3E -- Francesco Chicchiriccò Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating
On 8 May 2012 09:13, Francesco Chicchiriccò ilgro...@apache.org wrote: Hi Sebb, you can find my replies embedded below. I am going to send a [CANCEL] reply to this thread, remove Nexus staging repo and SVN tag, fix everything and start again the release process for 1.0.0-RC1-incubating from scratch. Regards. On 07/05/2012 14:47, sebb wrote: On 7 May 2012 10:38, Francesco Chicchiriccòilgro...@apache.org wrote: I've created a 1.0.0-RC1-incubating release, with the following artifacts up for a vote: SVN source tag (r1333797): https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/ There must be an Incubator DISCLAIMER. This is required in all distributions (and on the web-site, which has been done). Please add the DISCLAIMER file to SVN and make sure it gets added to all archives. Understood. The NOTICE file is very long; I suspect that not all of the entries are *required*. The LICENSE and NOTICE files were written against the parent POM: all the dependencies with scope != test were considered, then. The NL files must relate to what is actually included in the archive. For example, cglib is available under AL 2.0, so I don't think it needs to be mentioned in the NOTICE file. All the AL 2.0 dependencies not from ASF were added anyway to the LICENSE and NOTICE files; we preferred to have these two files with the same entries, even though for different purposes. The NOTICE file has a specific purpose; it should *only* contain required notices. The LICENSE file should mention all software included in the release. In both cases, the NL files should only mention software that is actually included in the release. The LICENSE file misspells Javassist. Already fixed in trunk: thanks for reporting! Maven staging repo: https://repository.apache.org/content/repositories/orgapachesyncope-034/ The syncope-root POM does not use the Apache POM as parent. ASF product Poms should normally chain back to a version of the Apache pom to ensure that the correct settings are established. [the other poms do chain back to the Apache pom] If there is a good reason for not doing so, it should be documented in the pom, and care must be taken to ensure that the required elements are copied from the Apache pom. As you might have noticed, the root POM is not the parent POM, and parent POM does extend Apache POM 10. The root POM is only functional to perform some actions: anyway we'll try to make it extend Apache POM as well. FYI, we have already planned to normalize POM structure in next major release (see SYNCOPE-79 on JIRA) Source release (checksums and signatures are available at the same location): https://repository.apache.org/content/repositories/orgapachesyncope-034/org/apache/syncope/syncope-root/1.0.0-RC1-incubating/syncope-root-1.0.0-RC1-incubating-source.tar.gz https://repository.apache.org/content/repositories/orgapachesyncope-034/org/apache/syncope/syncope-root/1.0.0-RC1-incubating/syncope-root-1.0.0-RC1-incubating-source.zip PGP release keys (signed using 273DF287): http://www.apache.org/dist/incubator/syncope/KEYS This has been voted through on the syncope-...@incubator.apache.org mailing list [1], and now requires a vote on general@incubator.apache.org Votes already cast (on syncope-dev): +1 (binding) * Francesco Chicchiriccò * Fabio Martelli * Marco Di Sabatino Di Diodoro * Massimiliano Perrone * Colm O hEigeartaigh (IPMC member) * Emmanuel Lécharny (IPMC member) * Simone Tripodi +1 (non binding) * Denis SIgnoretto * Riccardo Costa Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Best regards. [1] http://syncope-dev.1063484.n5.nabble.com/RESULT-VOTE-Apache-Syncope-1-0-0-RC1-incubating-4th-attempt-tt5690572.html -- Francesco Chicchiriccò Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Mesos 0.9.0-incubating (RC5)
+1 (binding) On Tue, Apr 24, 2012 at 8:15 PM, Brian McCallister bri...@skife.org wrote: +1 swept for licensing and general organization of everything :-) On Thu, Apr 19, 2012 at 5:54 PM, Matei Zaharia ma...@eecs.berkeley.edu wrote: +1 Tested it on Mac OS X, seems to work fine. Matei On Apr 19, 2012, at 12:53 PM, Benjamin Hindman wrote: Please vote on releasing the following candidate as Apache Mesos (incubating) version 0.9.0. This will be the first incubator release for Mesos in Apache, but the sixth release candidate. Changes since RC4: * Updated NOTICE to include project name and copyright date as well as to include third-party licences. * Changed one of our third-party components to be included as an archive of it's source rather than a binary bundle (Python egg). * Added DISCLAIMER. The candidate for Mesos 0.9.0-incubating release is available at: http://people.apache.org/~benh/mesos-0.9.0-incubating-RC5/mesos-0.9.0-incubating.tar.gz The tag to be voted on: https://svn.apache.org/repos/asf/incubator/mesos/tags/release-0.9.0-incubating-RC5 The MD5 checksum of the tarball can be found at: http://people.apache.org/~benh/mesos-0.9.0-incubating-RC5/mesos-0.9.0-incubating.tar.gz.md5 The signature of the tarball can be found at: http://people.apache.org/~benh/mesos-0.9.0-incubating-RC5/mesos-0.9.0-incubating.tar.gz.asc Mesos' KEYS file, containing the PGP keys used to sign the release: http://svn.apache.org/repos/asf/incubator/mesos/dist/KEYS Please vote on releasing this package as Apache Mesos 0.9.0-incubating! The vote is open until Monday, April 23rd at 8 pm (a bit more than 72 hours since it's over the weekend) and passes if a majority of at least 3 +1 IPMC votes are cast. [ ] +1 Release this package as Apache Mesos 0.9.0-incubating [ ] -1 Do not release this package because ... To learn more about Apache Mesos, please see http://incubator.apache.org/mesos. - 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - 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, not that I want to (immediately) become a mentor here, but I am happy to oversee future release votes, and see if the community needs some other guidance etc. -M On Fri, May 4, 2012 at 10:32 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - 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 Tue, May 8, 2012 at 12:03 AM, Bruno Mahé bm...@apache.org wrote: The output of Apache Bigtop (incubating) can be quite unusual since it is a deployable production quality big data stack. What does it take to get a product into the Bigtop stack? I don't see any legal problems, but is vendor neutrality an issue here? Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[ANNOUNCE] Apache OpenOffice 3.4 Released
The Apache OpenOffice Podling Project Management Committee is pleased to announce the release of Apache OpenOffice 3.4, available on Windows, MacOS and Linux. Downloads are available at: http://download.openoffice.org The full release announcement can be read here: http://www.openoffice.org/news/aoo34.html Regards, - The Apache OpenOffice PPMC - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
AMBER Status: let down by incubator?
As a shepherd I just reviewed the Amber project. In my opinion this project has been badly let down by the incubation process. Here are my notes from the review: Blocked from graduation by IP signoff from University of Newcastle. Report asks for guidance. Why are mentors not providing this? The projet has, IMHO, been unnecessarily blocked by this since October 2010. Legal JIRA raised on 30/4/2011 at https://issues.apache.org/jira/browse/LEGAL-134 - looks like it will be resolved soon but mentors should have provided this advice 18 months ago. Useful summary of timeline and status at http://markmail.org/message/y5aevzuiyaimoz3t Ross -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com - 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 Tue, May 8, 2012 at 3:20 PM, Ross Gardler rgard...@opendirective.com wrote: I've done my shepherd reviews and made one comment (about Amber) on this list). I'm not sure where you want general observations recording but I have moved the projects to the recommended status category That's perfect, thanks! I'll compose the report summary based on the comments people raise about individual reports (like the one you did about Amber). 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
I was late to volunteer. Do you have any leftover projects? On Tue, May 8, 2012 at 9:20 AM, Ross Gardler rgard...@opendirective.com wrote: I've done my shepherd reviews and made one comment (about Amber) on this list). I'm not sure where you want general observations recording but I have moved the projects to the recommended status category On 7 May 2012 21:03, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 5/4/2012 1:27 PM, Greg Stein 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. The approach would require just a couple of things; * designate a private report-review.txt file svn path which provides svn notification to the incubator-private list. Private, because both personal and confidential questions may be asked and answered in the scope of that approval/question/comment review file. * populate that file each month with the list of reports. Those reports themselves could continue to persist in the wiki or could be transfered into that internal edit/discuss report file. A comment to that svn review file would be broadcast, so that answers and the followup can either occur as a subsequent commit (asked and answered), or can evolve into an incubator-private mail list dialog (or be referred over to the podling-dev or podling-private list for clarification). In all I like the idea. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com - 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
On Tue, May 8, 2012 at 4:30 AM, Marvin Humphrey mar...@rectangular.com wrote: On Tue, May 8, 2012 at 12:03 AM, Bruno Mahé bm...@apache.org wrote: The output of Apache Bigtop (incubating) can be quite unusual since it is a deployable production quality big data stack. What does it take to get a product into the Bigtop stack? Two things are needed for a component to be proposed for addition to Bigtop: * The license has to be AL * There has to be a champion for it After that there's a vote by the community to include a component into the next release (whatever that may be). Bigtop follow a rigid date-drive quarterly release model and we vote on Bills Of Materials (BOMs) for every new release that we are about to work on. Finally, the work that is required for inclusion consists of: * providing packaging for the component on all supported platforms * providing deployment code for the component * providing smoke test code for the component One that patch including all 3 of the above is posted on a JIRA, +1ed and committed the component is considered to be part of the Bigtop. We do not have a notion of maintainers. Once something is added to Bigtop it is everybody's responsibility to maintain it. I don't see any legal problems, but is vendor neutrality an issue here? At this point I'm slightly confused as to what this thread is actually trying to accomplish. I thought the original intent was to: * screen for potential legal issues * help incubator mentors understand Bigtop I believe we've accomplished both. To the best of our collective knowledge there are no legal issues with adding Hue to Bigtop and it feels like the mission and charter of Bigtop is now well understood. Is there anything else left to be discussed? Thanks, Roman. - 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 Tue, May 8, 2012 at 12:50 AM, Daniel Shahaf d...@daniel.shahaf.name wrote: Greg Stein wrote on Tue, May 08, 2012 at 03:32:32 -0400: On Tue, May 8, 2012 at 3:03 AM, Bruno Mahé bm...@apache.org wrote: Note also that Infra has already been involved. Yup. Saw. What's the infra issue here? I see no new mentions of bigtop on infra list in the last day I don't think there's an issue to be resolved, but rather an awareness in the Bigtop community that given the size of our releases we have to be very proactive about coordinating them with the Apache Infra team. Bigtop community and its release managers are well aware of that and are very sensitive to making INFRA's job easier. We will definitely not surprise you with 0.4.0. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Shepherds for podling reports
No such thing as leftover. Doubling up (or more) is just fine. Q is whether there are some under-reviewed... On May 8, 2012 6:40 AM, Benson Margulies bimargul...@gmail.com wrote: I was late to volunteer. Do you have any leftover projects? On Tue, May 8, 2012 at 9:20 AM, Ross Gardler rgard...@opendirective.com wrote: I've done my shepherd reviews and made one comment (about Amber) on this list). I'm not sure where you want general observations recording but I have moved the projects to the recommended status category On 7 May 2012 21:03, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 5/4/2012 1:27 PM, Greg Stein 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. The approach would require just a couple of things; * designate a private report-review.txt file svn path which provides svn notification to the incubator-private list. Private, because both personal and confidential questions may be asked and answered in the scope of that approval/question/comment review file. * populate that file each month with the list of reports. Those reports themselves could continue to persist in the wiki or could be transfered into that internal edit/discuss report file. A comment to that svn review file would be broadcast, so that answers and the followup can either occur as a subsequent commit (asked and answered), or can evolve into an incubator-private mail list dialog (or be referred over to the podling-dev or podling-private list for clarification). In all I like the idea. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com - 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
Well, the Wiki page explicitly says that the chair will assign. On Tue, May 8, 2012 at 1:38 PM, Greg Stein gst...@gmail.com wrote: No such thing as leftover. Doubling up (or more) is just fine. Q is whether there are some under-reviewed... On May 8, 2012 6:40 AM, Benson Margulies bimargul...@gmail.com wrote: I was late to volunteer. Do you have any leftover projects? On Tue, May 8, 2012 at 9:20 AM, Ross Gardler rgard...@opendirective.com wrote: I've done my shepherd reviews and made one comment (about Amber) on this list). I'm not sure where you want general observations recording but I have moved the projects to the recommended status category On 7 May 2012 21:03, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 5/4/2012 1:27 PM, Greg Stein 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. The approach would require just a couple of things; * designate a private report-review.txt file svn path which provides svn notification to the incubator-private list. Private, because both personal and confidential questions may be asked and answered in the scope of that approval/question/comment review file. * populate that file each month with the list of reports. Those reports themselves could continue to persist in the wiki or could be transfered into that internal edit/discuss report file. A comment to that svn review file would be broadcast, so that answers and the followup can either occur as a subsequent commit (asked and answered), or can evolve into an incubator-private mail list dialog (or be referred over to the podling-dev or podling-private list for clarification). In all I like the idea. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com - 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
Droids status (Was: [Incubator Wiki] Update of May2012 by RichardFrovarp)
Hi, Thanks for the report, Droids! On Tue, May 1, 2012 at 3:53 PM, Apache Wiki wikidi...@apache.org wrote: + Droids is an Incubator project arrived from Apache Labs. Droids entered + incubation on October, 2008. That's 3.5 years of incubation, and unfortunately it looks like community activity has yet to bounce back to the levels before the drop I noted already in February. What's your plan towards graduation? Any concrete actions you're taking to increase community activity? Any blockers or problems you're facing? How about a new release, a blog post, or something similar to help drive interest? I'm hoping that with the new committer (great!) you'll have a chance to revitalize the project, but unless we start seeing some more positive developments by the next report I think we need to start considering alternative exit strategies for Droids. Incubation is not meant to last indefinitely. Is there any way that the greater Incubator or ComDev community could help push things forward for Droids? BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Graduation tasks : (was INFRA-4767)
Seeing INFRA-4767 ... Need to update the website 1) List of VPs Also, if a VP position changes, please update the web-site file at: http://www.apache.org/foundation/index.html using the CMS application, or update: https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/foundation/index.mdtext 2) Index of TLPs https://svn.apache.org/repos/asf/infrastructure/site/trunk/templates/blocks/projects.mdtext Is projects.mdtext something a graduating project needs to update? I'm happy to do it for Jena - it's not in http://i.a.o/guides/graduation.html#notes-on-hand-over so it hasn't been done so far. Anywhere else need doing? Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Droids status (Was: [Incubator Wiki] Update of May2012 by RichardFrovarp)
Hi, On Tue, May 8, 2012 at 3:11 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: ... I'm hoping that with the new committer (great!) you'll have a chance to revitalize the project, but unless we start seeing some more positive developments by the next report I think we need to start considering alternative exit strategies for Droids. Incubation is not meant to last indefinitely I'm wondering if Droids could graduate to commons.apache.org - it seems to be one of these projects that's useful, but on which people typically work on an off depending on their needs, so it's hard to have sustained activity. -Bertrand - 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)
Thanks for taking a look, Matthias! It's very much appreciated. Matei On May 8, 2012, at 2:43 AM, Matthias Wessendorf wrote: Hi, not that I want to (immediately) become a mentor here, but I am happy to oversee future release votes, and see if the community needs some other guidance etc. -M On Fri, May 4, 2012 at 10:32 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - 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
[RESULT] Re: [VOTE] Release Apache Mesos 0.9.0-incubating (RC5)
Thanks so much for taking a look Matthias! We have releases in the pipeline, so your continued involvement would be amazing! With 3 binding +1 votes, 0 +0 votes, and 0 -1 votes, this release candidate is promoted to a release! Tally: +1: Matei Zaharia (non-binding) Brian McCallister (binding) Tom White (binding) Matthias Wessendorf (binding) +0: -1: Ben. On Tue, May 8, 2012 at 2:43 AM, Matthias Wessendorf mat...@apache.orgwrote: Hi, not that I want to (immediately) become a mentor here, but I am happy to oversee future release votes, and see if the community needs some other guidance etc. -M On Fri, May 4, 2012 at 10:32 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating
On 8 May 2012 13:06, Emmanuel Lécharny elecha...@gmail.com wrote: Comments inline Le 5/8/12 11:05 AM, sebb a écrit : On 8 May 2012 09:13, Francesco Chicchiriccòilgro...@apache.org wrote: Hi Sebb, you can find my replies embedded below. I am going to send a [CANCEL] reply to this thread, remove Nexus staging repo and SVN tag, fix everything and start again the release process for 1.0.0-RC1-incubating from scratch. Regards. The NOTICE file is very long; I suspect that not all of the entries are *required*. The LICENSE and NOTICE files were written against the parent POM: all the dependencies with scope != test were considered, then. The NL files must relate to what is actually included in the archive. We release sources, so making a distinction between scope != test dependencies and scope=test dependencies does not make sense, AFAICT. If we use a 3rd party product to test Syncope, then I think we must refer their licenses in NOTICE and LICENSE. No, AIUI the NL files only relate to what is being released, not any external dependencies. For example, cglib is available under AL 2.0, so I don't think it needs to be mentioned in the NOTICE file. All the AL 2.0 dependencies not from ASF were added anyway to the LICENSE and NOTICE files; we preferred to have these two files with the same entries, even though for different purposes. The NOTICE file has a specific purpose; it should *only* contain required notices. The best would be to check the 3rd product licenses to see if they require you to add the licenses. Yes. But as we are not lawyers, and sometime Licenses are written in a way that only a couple of judges plus the suprem court can understand what is in it, I'd suggest that if you have a doubt, just include them. The NOTICE file should only include *required* notices. If in doubt, ask on legal-discuss or via the legal JIRA. In any case, as soon as the required notes are in the NOTICE file, it should not be a blocker. It's important not to include extra stuff in the NOTICE file, because that can place additional burdens on downstream consumers. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com - 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: Graduation tasks : (was INFRA-4767)
On 8 May 2012 23:22, Andy Seaborne a...@apache.org wrote: Seeing INFRA-4767 ... Need to update the website 1) List of VPs Also, if a VP position changes, please update the web-site file at: http://www.apache.org/foundation/index.html using the CMS application, or update: https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/foundation/index.mdtext 2) Index of TLPs https://svn.apache.org/repos/asf/infrastructure/site/trunk/templates/blocks/projects.mdtext Is projects.mdtext something a graduating project needs to update? Yes, once the TLP.apache.org website is available. I'm happy to do it for Jena - it's not in http://i.a.o/guides/graduation.html#notes-on-hand-over so it hasn't been done so far. Anywhere else need doing? DOAP file needs creating and adding to the list [1] If you already have one it will need updating, and files.xml updated with the new location. The PMC chair should have sufficient karma to update that. [1] https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/files.xml Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Airavata status (Was: [Incubator Wiki] Update of May2012 by SureshMarru)
Hi Jukka, On May 8, 2012, at 4:47 PM, Jukka Zitting wrote: Hi, Thanks for the great report, Airavata! Sounds like you're doing fine. Based on your report I still classified Airavata as lacking enough diversity to graduate in near future, but I'm looking forward to hearing about new committers or other community developments already in your next report. Also, it'll be interesting to hear about how the GSoC program works for you with so many students participating. And of course congrats on getting the first release out! Thanks for taking time to review. Yes we are very much looking forwarding to broadening the community. As you pointed out, waiting to see how GSoC students fare up. We have a diverse user base but the developer community is little focused now. Ross Chris have been actively mentoring the project helping us in the right direction. Big thanks to Ate in mentoring on legal requirements. We had the first release out and hoping that will stir some more momentum. We have seen some sporadic interests from community and we need to encourage that into more contributions [1] [2] [3] [4] [5]. Just to clarify: if we literally speak, the committers have currently diverse affiliations. Indiana University - 8 (Lahiru Gunathilake, Suresh Marru, Marlon Pierce, Thilina Gunaratne, Raminderjeet Singh, Barbara Hallock, Heshan Suriyaarachchi, Saminda Wijeratne) ; Lanka Software Foundation - 2 (Srinath Perera, Wathsala Vithanage); IBM - 1 (Aleksander Slominski); Chase - 1 (Archit Kulshrestha); Knight Capital (Chathura Herath), NexTag - 2 (Eran Chinthaka, Patanachai Tangchaisin). But practically speaking all active contributions are centered. Not just for graduation, but to let the software evolve with different use cases, we want to pro-actively encourage diverse participation. We hope to have few new committers come onboard before next report. Cheers, Suresh [1] - http://markmail.org/thread/p2kbay63hyv3co2h [2] - http://markmail.org/thread/zue6vjq2zxtpgm5m [3] - http://markmail.org/thread/tiyjlin4tanxqsxw [4] - http://markmail.org/thread/gksx25ab3gzzovpp [5] - http://markmail.org/thread/c635lpyly5uob3qv 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
