Re: Complications with Gradle wrapped projects and source releases (Samza, DataFu, Aurora)
So what now? Sent from my iPhone On Jun 15, 26 Heisei, at 20:36, Jake Farrell jfarr...@apache.org wrote: Hey Marvin That is correct, gradle.jar is the only binary and that is able to be a fixed repeatable build via a wrapper task in the build.gradle file. After re-reading the policies I'm in agreement with them and dont think that we need to make an exception for this. Each project can create a secondary binary release package which includes this file and the repo can still have it committed (which is the big benefit for it since it makes the initial development bootstrapping a little nicer). This is no different than what projects like Ant and Maven have been doing for some time now and I think is the better approach -Jake On Fri, Jun 13, 2014 at 6:52 PM, Marvin Humphrey mar...@rectangular.com wrote: On Fri, Jun 13, 2014 at 11:14 AM, Steve Loughran ste...@hortonworks.com wrote: On 10 June 2014 16:20, Marvin Humphrey mar...@rectangular.com wrote: One fundamental problem with compiled deps is that unlike source code, they cannot be reviewed by a PMC -- so they are potential trojan horses. Maybe it's possible to address that specific concern by compiling an ASF whitelist of individual jar files whose provenance can be guaranteed and whose identity is verified via PGP prior to committing? true, but who does a transitive validation of all mvn/ivy dependencies, validating the checksums from an HTTPS server while pulling them down from a normal HTTP link. Were I to perform a MITM intercept of maven central DNS/GETs at something like apachecon, I'd probably have everyone's password-less ssh keys within 48 hours. If I'm understanding the Gradle situation right, the task at hand is more limited: to get the Gradle wrapper alone into version control. There seems to be a closed set of files which we could build from source in a controlled environment, sign with PGP keys, and archive somewhere. Extrapolating out to arbitrary dependencies and arbitrary build systems is a worthwhile exercise when considering the potential for org-certified binaries -- is it feasible to assemble a collection of certified dependencies and use those in conjunction with disposable build servers running offline to compile releases securely? But that's a much bigger topic. Marvin Humphrey - 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] Retire the S4 podling
Retire the S4 polling Sent from my iPhone On Jun 15, 26 Heisei, at 16:58, Mark Struberg strub...@yahoo.de wrote: +1 (binding) LIeGrue, strub On Saturday, 14 June 2014, 16:10, Dave Fisher w...@apache.org wrote: +1, binding. Sent from my iPhone On Jun 13, 2014, at 3:18 PM, Roman Shaposhnik r...@apache.org wrote: On Fri, Jun 13, 2014 at 11:36 AM, Joe Brockmeier j...@zonker.net wrote: Hi all, Per recent discussions on general@[1] and s4-dev@ [2], I went ahead and called for a VOTE on the S4 dev@ mailing list [3] about retiring the podling. That VOTE has passed with no -1s and 4 (binding) +1s from the podling PMC/committers. (S4 only has committers, and doesn't distinguish between PPMC/committer.) We didn't get a weigh-in from all mentors/PPMC on the retirement VOTE, so I'm going ahead and asking for a vote here. This VOTE will be open for at least 72 hours. Please indicate (binding) or (non-binding) when casting your VOTE. +1 [ ] Yes, I am in favor of retiring S4 from the Apache Incubator. +0 [ ] -1 [ ] No, I am not in favor of retiring S4 because... +1 (binding) Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Request for mentor assessment
Hi Roman, On Thu, Jun 12, 2014 at 1:33 AM, Roman Shaposhnik r...@apache.org wrote: ... * DeviceMap has been in the incubator since 2012-01-03. It seems like it is still struggling with the basics: producing releases and growing its PMC. What's the recommendation here?... I agree with your view - as a mentor I see no urgency to shut the project down, it's fairly different from other projects in that it needs little code, the bulk of it is mobile device data. The (small) community is still struggling to find good ways to allow people to contribute that data, and if that happens the project could become viable quickly. My recommendation as a mentor is to give DeviceMap a bit more time to give it a chance to setup that data contribution mechanism. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Graduate Apache Celix as TLP
2014-06-16 0:36 GMT+02:00 Joe Brockmeier j...@zonker.net: On 06/13/2014 05:17 PM, Roman Shaposhnik wrote: Personally, I don't feel this is a big deal. The PMC size is appropriate given the overall project size. That said, I'd like to make two points: * in general, for a smaller project like Celix I'd like to encourage folks to consider PMC == committers That is the case with Celix, correct? Looking at the status page, I only see committers and no PMC list. Yes, for the TLP we decided to make all committers PMC members. I would note that the number of PMC members concerns me a bit since the most recent release process took more than a month b/c there weren't enough VOTEs. That is somewhat tempered by the fact that the project seems to have added two PMC/committers since 1.0.0. During incubation PPMC members are not allowed to vote if they are not part of the IPMC. So even if all committers where also on the PPMC, that wouldn't have helped with the release. Wrt the release taking a long time, as mentioned by Marvin, Roman is a mentor, but most of his time is consumed by the Incubator itself. So we had to wait on the IPMC for a while (and as can be seen by this thread, a while can turn out to be days or even weeks). Also of mild concern is that Celix missed its April report (it did report in May). This was an unlucky combination of factors, vacations, schedules etc. As you mentioned, we picked it up immediately in May. What would be the best way to go now? Reading all graduation guidelines we are ready, but if these guidelines are not correct, I'd like to see statement about that. We are now left in the middle, without a clear guide where to go.. -- Met vriendelijke groet, Alexander Broekhuis
Re: [DISCUSS] Graduate Apache Celix as TLP
Hi, On Sat, Jun 14, 2014 at 9:32 PM, Marvin Humphrey mar...@rectangular.com wrote: Here's current Board member Bertrand Delacretaz in 2012: ... People come and go, so to be realistic I'd say you need at least five active PMC members at graduation time, so as to get three votes when needed, with some spares. Mentors staying on board can of course count in those five Thanks Marvin for digging this up, and yes I still agree with myself ;-) The board might or might not object to graduation but regardless it would IMO be much better to have at least one more PMC member, otherwise the board might have to step in if the PMC becomes too small, and it would most probably do so without much context about the project which is far from ideal. A simple solution to that is for at least one of the mentors to stay on the new PMC, would one of them agree to do that? It doesn't mean you have to be very active, but at least stay there just in case. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Graduate Apache Celix as TLP
Hello Bertrand, On 16 Jun 2014, at 8:57 am, Bertrand Delacretaz bdelacre...@apache.org wrote: On Sat, Jun 14, 2014 at 9:32 PM, Marvin Humphrey mar...@rectangular.com wrote: Here's current Board member Bertrand Delacretaz in 2012: ... People come and go, so to be realistic I'd say you need at least five active PMC members at graduation time, so as to get three votes when needed, with some spares. Mentors staying on board can of course count in those five Thanks Marvin for digging this up, and yes I still agree with myself ;-) The board might or might not object to graduation but regardless it would IMO be much better to have at least one more PMC member, otherwise the board might have to step in if the PMC becomes too small, and it would most probably do so without much context about the project which is far from ideal. A simple solution to that is for at least one of the mentors to stay on the new PMC, would one of them agree to do that? It doesn't mean you have to be very active, but at least stay there just in case. Since I regularly get involved in discussions (but hardly ever commit code) I would like to stay involved. So, Alexander, feel free to update the graduation proposal and add me. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Graduate Apache Celix as TLP
Hi Marcel, On Mon, Jun 16, 2014 at 3:52 PM, Marcel Offermans marcel.offerm...@luminis.eu wrote: ...Since I regularly get involved in discussions (but hardly ever commit code) I would like to stay involved... Fantastic! Thanks. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Graduate Apache Celix as TLP
On Mon, Jun 16, 2014 at 6:52 AM, Marcel Offermans marcel.offerm...@luminis.eu wrote: Since I regularly get involved in discussions (but hardly ever commit code) I would like to stay involved. So, Alexander, feel free to update the graduation proposal and add me. I am exactly in the same boat and would love to stay as part of the project to help with minutia (when needed ;-)). Alexander, feel free to update the graduation proposal and add me if needed. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Complications with Gradle wrapped projects and source releases (Samza, DataFu, Aurora)
We've gone ahead and built a separate build script that will bootstrap a source release. (https://issues.apache.org/jira/browse/SAMZA-283). This works but is a bit clunky. -jakob On Sun, Jun 15, 2014 at 9:38 AM, abiola balogun a_gucc...@me.com wrote: So what now? Sent from my iPhone On Jun 15, 26 Heisei, at 20:36, Jake Farrell jfarr...@apache.org wrote: Hey Marvin That is correct, gradle.jar is the only binary and that is able to be a fixed repeatable build via a wrapper task in the build.gradle file. After re-reading the policies I'm in agreement with them and dont think that we need to make an exception for this. Each project can create a secondary binary release package which includes this file and the repo can still have it committed (which is the big benefit for it since it makes the initial development bootstrapping a little nicer). This is no different than what projects like Ant and Maven have been doing for some time now and I think is the better approach -Jake On Fri, Jun 13, 2014 at 6:52 PM, Marvin Humphrey mar...@rectangular.com wrote: On Fri, Jun 13, 2014 at 11:14 AM, Steve Loughran ste...@hortonworks.com wrote: On 10 June 2014 16:20, Marvin Humphrey mar...@rectangular.com wrote: One fundamental problem with compiled deps is that unlike source code, they cannot be reviewed by a PMC -- so they are potential trojan horses. Maybe it's possible to address that specific concern by compiling an ASF whitelist of individual jar files whose provenance can be guaranteed and whose identity is verified via PGP prior to committing? true, but who does a transitive validation of all mvn/ivy dependencies, validating the checksums from an HTTPS server while pulling them down from a normal HTTP link. Were I to perform a MITM intercept of maven central DNS/GETs at something like apachecon, I'd probably have everyone's password-less ssh keys within 48 hours. If I'm understanding the Gradle situation right, the task at hand is more limited: to get the Gradle wrapper alone into version control. There seems to be a closed set of files which we could build from source in a controlled environment, sign with PGP keys, and archive somewhere. Extrapolating out to arbitrary dependencies and arbitrary build systems is a worthwhile exercise when considering the potential for org-certified binaries -- is it feasible to assemble a collection of certified dependencies and use those in conjunction with disposable build servers running offline to compile releases securely? But that's a much bigger topic. Marvin Humphrey - 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] Graduate Apache Celix as TLP
I had an honor to shepherd Celix ones and I like the dynamics of it. I am sure the community will grow as the time goes. In my opinion, it worth moving it into TLP. I will be happy to help the project moving forward if my help is required. Cos On Tue, Jun 10, 2014 at 07:06AM, Alexander Broekhuis wrote: Hi All, Since entering Incubation in November 2010, the Celix podling been working towards graduation. The community has grown, releases have been made and new committers have been added. Over the last couple of months all items on the checklist for graduation have been ticked of [1]. This resulted in a, positive, vote on te dev list of Celix itself [2]. Also the namesearch has been performed [3]. As far as we can tell the project status is up to date [4], and Celix is ready for graduation. This thread is to start the IPMC discussion for the graduation of Apache Celix. The proposed resolution can be found at the bottom of this email. Any feedback is appreciated, and where needed we will any remaining issues as soon as possible. Thanks in advance Alexander Broekhuis (PPMC member of Apache Celix) [1]: http://incubator.apache.org/guides/graduation.html#checklist [2]: http://markmail.org/thread/7y3a2l6qqm56cvud [3]: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-50 [4]: http://incubator.apache.org/projects/celix.html === Board Resolution == X. Establish the Apache Celix Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software, for distribution at no charge to the public, related to a native implementation of the OSGi specification. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Celix Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Celix Project be and hereby is responsible for the creation and maintenance of software related to a native implementation of the OSGi specification; and be it further RESOLVED, that the office of Vice President, Apache Celix 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 Celix Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Celix 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 Celix Project: * Alexander Broekhuis abro...@apache.org * Pepijn Noltes pnol...@apache.org * Bjoern Petribpe...@apache.org * Erik Jansman ejan...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Alexander Broekhuis be appointed to the office of Vice President, Apache Celix, 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 Celix 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 Celix Project; and be it further RESOLVED, that the Apache Celix Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Celix podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Celix podling encumbered upon the Apache Incubator Project are hereafter discharged. -- Met vriendelijke groet, Alexander Broekhuis - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Retire the S4 podling
+1 (non-binding) On Fri, Jun 13, 2014 at 04:23PM, John D. Ament wrote: +1 Please go ahead and retire from the incubator. (binding) On Fri, Jun 13, 2014 at 2:36 PM, Joe Brockmeier j...@zonker.net wrote: Hi all, Per recent discussions on general@[1] and s4-dev@ [2], I went ahead and called for a VOTE on the S4 dev@ mailing list [3] about retiring the podling. That VOTE has passed with no -1s and 4 (binding) +1s from the podling PMC/committers. (S4 only has committers, and doesn't distinguish between PPMC/committer.) We didn't get a weigh-in from all mentors/PPMC on the retirement VOTE, so I'm going ahead and asking for a vote here. This VOTE will be open for at least 72 hours. Please indicate (binding) or (non-binding) when casting your VOTE. +1 [ ] Yes, I am in favor of retiring S4 from the Apache Incubator. +0 [ ] -1 [ ] No, I am not in favor of retiring S4 because... Note that we have one IPMC vote from Patrick already. [1] http://s.apache.org/7Gz [2] http://s.apache.org/ig [3] http://s.apache.org/OAU -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Request for mentor assessment
I share the sentiment with NPanday - doesn't seem like anything is happening there really. If it of an interest to the incubator, I will volunteer to help mentoring Tez. Cos On Fri, Jun 13, 2014 at 12:55AM, Mattmann, Chris A (3980) wrote: I think Tez needs some more help mentoring. I myself haven't had as much time as possible so the more folks over there that can help mentor the better. Good job starting this thread, Roman. -Original Message- From: Roman Shaposhnik ro...@shaposhnik.org Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Thursday, June 12, 2014 5:44 PM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Request for mentor assessment On Wed, Jun 11, 2014 at 5:47 PM, Henry Saputra henry.sapu...@gmail.com wrote: Seems like NPanday should go to attic. One mentor I asked did not even monitor it anymore I've had exactly the same experience. My plan here is to wait for folks to chime in on this thread and for those mentors who are MiA start different threads asking for additional (replacement) mentors. I really would like for things like retirement proposals to come from somebody who's spent time getting to know the community in greater details. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Request for mentor assessment
On Thu, Jun 12, 2014 at 11:31PM, Joe Brockmeier wrote: On 06/12/2014 07:56 PM, Roman Shaposhnik wrote: This is one of the questions, I'd like to explore in greater details: are we comfortable with having professional student projects in the incubator? In response to the general question, it seems that professional student podlings are inconsistent with the idea that the Incubator is a process that should result in graduation or termination. In the case of Wave, it really strikes me as odd that the community is not capable of even a single release in more than 3.5 years: http://incubator.apache.org/wave/downloads.html This suggests that ASF is being used as a GitHub of sorts. Are we comfortable with this? Speaking for myself, no. I'd be uncomfortable having a specific deadline for graduation, but a podling that's not making progress towards graduation (in general, not pointing a finger specifically at Wave here) should be terminated. For what it worth, I think you're right: a permanent incubator project doesn't make sense. For once, there's a lot of people mechanics involved into podlings' mentoring, reporting, etc. And it doesn't feel exactly right to forever handhold something that doesn't have an intention to evolve. Cos - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Complications with Gradle wrapped projects and source releases (Samza, DataFu, Aurora)
I want to concur on that. Say, in Bigtop that has Gradle build system, we aren't checking in the wrappers. Instead they are created in the build time, and consequently might be added into a binary assembly. Cos On Tue, Jun 10, 2014 at 07:23PM, Jake Farrell wrote: Hey Jakob We did run into this while packaging our first rc in Aurora. There was some discussion around this on our dev list and we ended up removed the gradle.jar and gradlew from the source dist and added the wrapper task to build.gradle so it will always generate the same gradlew that we have committed in our repo for dev use. We will be creating a binary dist to accompany our source dist which will include the gradle.jar. This is similar to how Ant and Maven generate packages for their releases. -Jake On Tue, Jun 10, 2014 at 4:18 PM, Jakob Homan jgho...@gmail.com wrote: We're currently working on the first release for Samza and have run into a problem involving the source release and our build system, Gradle. Both DataFu and Aurora use Gradle and will run into this issue as well when they do a source release. Gradle provides a wrapper script, gradlew that allows the end user to run all the usual build tools without having gradle itself installed on the system. This script and its required resources are intended to be checked [1] to the source control this. This is contrast to Ant or Maven, which require those tools to be pre-installed on the system before executing a build against a build.xml or pom.xml, respectively. However, for the gradlew script to work, it downloads the a version of the gradle jar and requires that jar to be checked in as well. Counterintuitively, a project using gradlew must be bootstrapped by an install with gradle installed, or have the result of that bootstrapping checked into the repo. The problem lies with the Release Check List [2], which prohibits the inclusion of jars in a source release. Under this rule we effectively can't use gradlew as our build system in that we can't distribute it (absent some hacky solution like us trying to download the script and jar ourselves. We'd obviously prefer to avoid this.) I'm thinking we should make an exception to this no-jar rule for the gradlew jar. The Gradle project is open source [3], Apache 2 licensed [4] and intends for this jar to be included as part of the source of projects [1]. Finally, the jar itself contains only Gradle-generated classes with no other code fat-jarred [5]. The gradlew wrapper actually makes it easier for users to get and play with our code as it removes the need for any particular version of Gradle to be availabe beforehand (it also hides much of the complexity of the rapidly evolving gradle spec). Thoughts? -Jakob [1] The wrapper is something you should check into version control. http://www.gradle.org/docs/current/userguide/gradle_wrapper.html [2] This package may not contain compiled components (such as jar files) because compiled components are not open source, even if they were built from open source. http://incubator.apache.org/guides/releasemanagement.html#check-list [3] https://github.com/gradle/gradle [4] http://www.gradle.org/license [5] https://gist.github.com/jghoman/42f683bd92c3599cdf26 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Graduate Apache Celix as TLP
On 16 June 2014 08:56, Alexander Broekhuis a.broekh...@gmail.com wrote: 2014-06-16 0:36 GMT+02:00 Joe Brockmeier j...@zonker.net: On 06/13/2014 05:17 PM, Roman Shaposhnik wrote: Personally, I don't feel this is a big deal. The PMC size is appropriate given the overall project size. That said, I'd like to make two points: * in general, for a smaller project like Celix I'd like to encourage folks to consider PMC == committers That is the case with Celix, correct? Looking at the status page, I only see committers and no PMC list. Yes, for the TLP we decided to make all committers PMC members. I would note that the number of PMC members concerns me a bit since the most recent release process took more than a month b/c there weren't enough VOTEs. That is somewhat tempered by the fact that the project seems to have added two PMC/committers since 1.0.0. During incubation PPMC members are not allowed to vote if they are not part of the IPMC. That is not quite true; anyone is allowed to vote, even non-PPMC members. However only IPMC member votes count towards a *release* vote. So even if all committers where also on the PPMC, that wouldn't have helped with the release. Wrt the release taking a long time, as mentioned by Marvin, Roman is a mentor, but most of his time is consumed by the Incubator itself. So we had to wait on the IPMC for a while (and as can be seen by this thread, a while can turn out to be days or even weeks). Also of mild concern is that Celix missed its April report (it did report in May). This was an unlucky combination of factors, vacations, schedules etc. As you mentioned, we picked it up immediately in May. What would be the best way to go now? Reading all graduation guidelines we are ready, but if these guidelines are not correct, I'd like to see statement about that. We are now left in the middle, without a clear guide where to go.. -- Met vriendelijke groet, Alexander Broekhuis - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Complications with Gradle wrapped projects and source releases (Samza, DataFu, Aurora)
thinking about this, hadoop branch-1 used to GET ivy.jar, didn't it? On 16 June 2014 10:46, Jakob Homan jgho...@gmail.com wrote: We've gone ahead and built a separate build script that will bootstrap a source release. (https://issues.apache.org/jira/browse/SAMZA-283). This works but is a bit clunky. -jakob On Sun, Jun 15, 2014 at 9:38 AM, abiola balogun a_gucc...@me.com wrote: So what now? Sent from my iPhone On Jun 15, 26 Heisei, at 20:36, Jake Farrell jfarr...@apache.org wrote: Hey Marvin That is correct, gradle.jar is the only binary and that is able to be a fixed repeatable build via a wrapper task in the build.gradle file. After re-reading the policies I'm in agreement with them and dont think that we need to make an exception for this. Each project can create a secondary binary release package which includes this file and the repo can still have it committed (which is the big benefit for it since it makes the initial development bootstrapping a little nicer). This is no different than what projects like Ant and Maven have been doing for some time now and I think is the better approach -Jake On Fri, Jun 13, 2014 at 6:52 PM, Marvin Humphrey mar...@rectangular.com wrote: On Fri, Jun 13, 2014 at 11:14 AM, Steve Loughran ste...@hortonworks.com wrote: On 10 June 2014 16:20, Marvin Humphrey mar...@rectangular.com wrote: One fundamental problem with compiled deps is that unlike source code, they cannot be reviewed by a PMC -- so they are potential trojan horses. Maybe it's possible to address that specific concern by compiling an ASF whitelist of individual jar files whose provenance can be guaranteed and whose identity is verified via PGP prior to committing? true, but who does a transitive validation of all mvn/ivy dependencies, validating the checksums from an HTTPS server while pulling them down from a normal HTTP link. Were I to perform a MITM intercept of maven central DNS/GETs at something like apachecon, I'd probably have everyone's password-less ssh keys within 48 hours. If I'm understanding the Gradle situation right, the task at hand is more limited: to get the Gradle wrapper alone into version control. There seems to be a closed set of files which we could build from source in a controlled environment, sign with PGP keys, and archive somewhere. Extrapolating out to arbitrary dependencies and arbitrary build systems is a worthwhile exercise when considering the potential for org-certified binaries -- is it feasible to assemble a collection of certified dependencies and use those in conjunction with disposable build servers running offline to compile releases securely? But that's a much bigger topic. Marvin Humphrey - 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 -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: Request for mentor assessment
Tez is ready to graduate. Cos, if you can help us manage that process, it'd certainly be appreciated. -C On Mon, Jun 16, 2014 at 12:53 PM, Konstantin Boudnik c...@apache.org wrote: I share the sentiment with NPanday - doesn't seem like anything is happening there really. If it of an interest to the incubator, I will volunteer to help mentoring Tez. Cos On Fri, Jun 13, 2014 at 12:55AM, Mattmann, Chris A (3980) wrote: I think Tez needs some more help mentoring. I myself haven't had as much time as possible so the more folks over there that can help mentor the better. Good job starting this thread, Roman. -Original Message- From: Roman Shaposhnik ro...@shaposhnik.org Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Thursday, June 12, 2014 5:44 PM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Request for mentor assessment On Wed, Jun 11, 2014 at 5:47 PM, Henry Saputra henry.sapu...@gmail.com wrote: Seems like NPanday should go to attic. One mentor I asked did not even monitor it anymore I've had exactly the same experience. My plan here is to wait for folks to chime in on this thread and for those mentors who are MiA start different threads asking for additional (replacement) mentors. I really would like for things like retirement proposals to come from somebody who's spent time getting to know the community in greater details. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Graduate Apache Celix as TLP
2014-06-16 23:32 GMT+02:00 sebb seb...@gmail.com: During incubation PPMC members are not allowed to vote if they are not part of the IPMC. That is not quite true; anyone is allowed to vote, even non-PPMC members. However only IPMC member votes count towards a *release* vote. That is of course what I meant to say. Thanks for correcting. -- Met vriendelijke groet, Alexander Broekhuis
