Re: [DISCUSS] Whimsy PMC
On 04/27/2015 10:18 PM, Mattmann, Chris A (3980) wrote: I’ll note that the only person I see from infra that has been proposed in the current PMC is Jake Ferrel: * Acquia: Jake Farrell Someone also correct me in that I don’t think Jake is a paid infra contractor. In addition the way I see this is that it is no different e.g., than contributing upstream to FreeBSD or whatever - Infra contractors may fix something and decide it’s in the ASF’s best interests to contribute it upstream - same may happen for Whimsy. But to date, ASF infra folk that are contractors I believe are not proposed to be directly paid to contribute to Whimsy. Should they do so, great. But in the famous words of Sam Ruby let’s deal with this if there is an actual data point instead of hypotheticals. David states in his initial email that he has a paid contractor who hase working on Whimsy as one of his paid duties. This is not a hypothetical. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Whimsy PMC
On 04/27/2015 10:17 PM, Ross Gardler (MS OPEN TECH) wrote: +1, that's what I was trying to convey. -Original Message- From: Greg Stein [mailto:gst...@gmail.com] Sent: Monday, April 27, 2015 7:05 PM To: general@incubator.apache.org Subject: Re: [DISCUSS] Whimsy PMC On Mon, Apr 27, 2015 at 8:51 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: It's a tough one. We could be setting a precedence here that we absolutely do not want to set. On the other hand, it's problematic (not to mention simply ridiculous) if the foundation not being able to use Apache software because we don't pay for development and might want to submit a patch upstream. As long as all committers are equal and earn their merit in the traditional way I don't see a problem from the projects side. IN this instance the ASF is just another contributor to the project. This means the foundation never pays for development to something like the foundation never pays for development except where the modification is made as part of our normal infrastructure operations. On these rare occasions the foundation is just another employer and the contributor is just another community member. Changes are contributed upstream through the normal contribution process. There is no special role for ASF infra contractors. The ASF pays for Infra contractors. Their job/role is to maintain our systems. Sometimes their duty *may* be to contribute software to $Project (wherever that may be). That is *very* distinct from paying a person to contribute directly to $ASFProject. ok, you both make very good points. Let's be clear that these are the reasons, and when this comes up again - the desire for the Foundation to hire a developer to work on Apache Foo - we remember this distinction. -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [DISCUSS] Whimsy PMC
Not sure if your concern is diversity or scale, so I'll address both separately. If your concern is something else please be more explicit. Graduation does not require diversity of the PMC. It requires that the project be run according to the Apache Way which includes being open to any viewpoint brought to the project, regardless of the source. Furthermore, the initial set of committers covers a wide range of contributing orgs (although we are all doing this with ASF hats). Graduation does not require scale. Apache TLPs must be able to make a release. This boils down to at least three active PMC members. As for going straight to TLP I agree. Sam did say this was a possibility but I believe he (rightly so) wants to ensure that the proposal is solid before asking the board and IPMC to consider this path. Ross -Original Message- From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman Shaposhnik Sent: Tuesday, April 28, 2015 8:28 AM To: general@incubator.apache.org Subject: Re: [DISCUSS] Whimsy PMC Apologies if this has been asked, but Rich's points got me thinking. As it stands, I'm not sure I can see how Whimsy can graduate without us squinting just so. Basically, I don't see a clear way for the community to grow much beyond the initial list of committers. In a way, I'd rather see Whimsy got straight to TLP. I honestly see no point for it to go through the Incubator motions. Thoughts? Thanks, Roman. On Thu, Apr 23, 2015 at 11:46 AM, Sam Ruby ru...@intertwingly.net wrote: Initial sketch placed on the wiki: https://wiki.apache.org/incubator/WhimsyProposal Anyone who is so inclined is welcome to edit the proposal directly. No urgency or timeframe in mind (other than preferably starting sometime in 2015ish). My current thinking is to follow in Steve's footprints and go directly to TLP, but I'm starting a discussion here (in Incubator) to see if there are any other thoughts on the matter. - Sam Ruby - 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
[IP CLEARANCE] ec2stack donated to Apache CloudStack
Apache CloudStack is receiving code for an EC2 interface to the CloudStack API. http://incubator.apache.org/ip-clearance/cloudstack-ec2stack.html Please vote to approve this contribution. Lazy consensus applies. If no -1 votes are cast within the next 72 hours, the vote passes. Thanks, -Sebastien - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[IP CLEARANCE] gstack donation to Apache CloudStack
Apache CloudStack is receiving code for a Google GCE interface to the CloudStack API. http://incubator.apache.org/ip-clearance/cloudstack-gstack.html Please vote to approve this contribution. Lazy consensus applies. If no -1 votes are cast within the next 72 hours, the vote passes. Thanks, -Sebastien - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Whimsy PMC
I'd like to be on the initial list as well, so I've added myself. On 24 April 2015 at 04:46, Sam Ruby ru...@intertwingly.net wrote: Initial sketch placed on the wiki: https://wiki.apache.org/incubator/WhimsyProposal Anyone who is so inclined is welcome to edit the proposal directly. No urgency or timeframe in mind (other than preferably starting sometime in 2015ish). My current thinking is to follow in Steve's footprints and go directly to TLP, but I'm starting a discussion here (in Incubator) to see if there are any other thoughts on the matter. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Brett Porter http://brettporter.wordpress.com/
Re: [DISCUSS] Whimsy PMC
Apologies if this has been asked, but Rich's points got me thinking. As it stands, I'm not sure I can see how Whimsy can graduate without us squinting just so. Basically, I don't see a clear way for the community to grow much beyond the initial list of committers. In a way, I'd rather see Whimsy got straight to TLP. I honestly see no point for it to go through the Incubator motions. Thoughts? Thanks, Roman. On Thu, Apr 23, 2015 at 11:46 AM, Sam Ruby ru...@intertwingly.net wrote: Initial sketch placed on the wiki: https://wiki.apache.org/incubator/WhimsyProposal Anyone who is so inclined is welcome to edit the proposal directly. No urgency or timeframe in mind (other than preferably starting sometime in 2015ish). My current thinking is to follow in Steve's footprints and go directly to TLP, but I'm starting a discussion here (in Incubator) to see if there are any other thoughts on the matter. - Sam Ruby - 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] Whimsy PMC
On 4/27/15 10:05 PM, Greg Stein wrote: On Mon, Apr 27, 2015 at 8:51 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: It's a tough one. We could be setting a precedence here that we absolutely do not want to set. On the other hand, it's problematic (not to mention simply ridiculous) if the foundation not being able to use Apache software because we don't pay for development and might want to submit a patch upstream. As long as all committers are equal and earn their merit in the traditional way I don't see a problem from the projects side. IN this instance the ASF is just another contributor to the project. This means the foundation never pays for development to something like the foundation never pays for development except where the modification is made as part of our normal infrastructure operations. On these rare occasions the foundation is just another employer and the contributor is just another community member. Changes are contributed upstream through the normal contribution process. There is no special role for ASF infra contractors. Yes, that's a separate and important point. Every project PMC determines merit for their project independently. Just because someone is root@ does not mean they get a free committer bit on project X or binding votes - unless that PMC votes them in. The ASF pays for Infra contractors. Their job/role is to maintain our systems. Sometimes their duty *may* be to contribute software to $Project (wherever that may be). It's pretty simple. Infra contractors are responsible to code/maintain software and systems that the ASF needs to operate, including a variety of services that we provide to our projects. Their duty is to build stuff the ASF needs for our own operations. It doesn't matter where that code goes; Whimsy is no more special than STeVe is for that matter. That is *very* distinct from paying a person to contribute directly to $ASFProject. Exactly. The ASF does not pay infra contractors to write code for anyone else - only for our own organization's needs. Luckily, some of those needs require software that may also be useful for the rest of the world - but our own needs are what we do paid work for. I don't see this being a problem. 8-) - Shane Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Whimsy PMC
On Tue, Apr 28, 2015 at 9:08 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Not sure if your concern is diversity or scale, so I'll address both separately. If your concern is something else please be more explicit. Graduation does not require diversity of the PMC. It requires that the project be run according to the Apache Way which includes being open to any viewpoint brought to the project, regardless of the source. Furthermore, the initial set of committers covers a wide range of contributing orgs (although we are all doing this with ASF hats). It is actually neither. It is viability of the community outside of requirements of a very particular organization. IOW, the only way for me to make sure that community is not joined at the hip with ASF INFRA would be to see other foundations adopt the tools and joining the community. As for going straight to TLP I agree. Sam did say this was a possibility but I believe he (rightly so) wants to ensure that the proposal is solid before asking the board and IPMC to consider this path. Good. That would be my preferred way there then. Honestly, given the composition of the initial Whimsy community straight to TLP path is much more efficient way to go about it. IMHO, there's not much that Incubator experience would bring to the table for Whimsy. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Whimsy PMC
On Tue, Apr 28, 2015 at 9:42 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: I don't see how this is any different from any other project. The initial contributors will work on it to satisfy their needs. If organization X wants to use it they can contribute code to generalize the software and make it useful to their use case. As long as it doesn't break things for other users we would expect such a contribution to be accepted. It is different in the likelihood of applicability. *In my opinion*, the likelihood of the following statement being true organization X wants to use it (where X != ASF) is small enough for me to bother with asking the question. That said, we're discussing hypotheticals here. Both viewpoints are pure opinions. You offered yours, I offered mine. In case you're curious -- I'd ask the same question, for example, about a community that decided to produce software that is be only applicable as an add-on for a small market share commercial offering. There are plenty such potential contributors. Whether any of them will care we don't know, but making it a TLP increases the chances. Isn't that what we do here? No. We will make Whimsy a TLP because we feel like it is a useful community for us. Same way that IPMC or ComDev are, strictly speaking, TLPs. It would make no sense for ComDev to go through the incubation. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [DISCUSS] Whimsy PMC
Sam, I don't *want* the role, but if you want one less task to do each month I'd be happy to take on the chair role. If someone actually *wants* the role then let them take it. Ross -Original Message- From: sa3r...@gmail.com [mailto:sa3r...@gmail.com] On Behalf Of Sam Ruby Sent: Tuesday, April 28, 2015 10:04 AM To: general@incubator.apache.org Subject: Re: [DISCUSS] Whimsy PMC On Tue, Apr 28, 2015 at 12:08 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: As for going straight to TLP I agree. Sam did say this was a possibility but I believe he (rightly so) wants to ensure that the proposal is solid before asking the board and IPMC to consider this path. Suffice it to say that the response has exceeded my expectations. My plans now are to add a resolution to the May agenda unless somebody identifies a problem that needs to be addressed. Meanwhile, two items that need attention: 1) podling name search. I've opened https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-75. I don't see a problem. If others do, please speak up. 2) naming of a chair. If anybody wants that position, please speak up. If nobody does, I'll put my name down. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Whimsy PMC
On Thu, Apr 23, 2015 at 2:47 PM Sam Ruby ru...@intertwingly.net Anyone who is so inclined is welcome to edit the proposal directly. No urgency or timeframe in mind (other than preferably starting sometime in 2015ish). My current thinking is to follow in Steve's footprints and go directly to TLP, but I'm starting a discussion here (in Incubator) to see if there are any other thoughts on the matter. Added myself as an initial committer, in case I want to jump in and get my hands dirty. :)
Re: [DISCUSS] Whimsy PMC
On Tue, Apr 28, 2015 at 12:08 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: As for going straight to TLP I agree. Sam did say this was a possibility but I believe he (rightly so) wants to ensure that the proposal is solid before asking the board and IPMC to consider this path. Suffice it to say that the response has exceeded my expectations. My plans now are to add a resolution to the May agenda unless somebody identifies a problem that needs to be addressed. Meanwhile, two items that need attention: 1) podling name search. I've opened https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-75. I don't see a problem. If others do, please speak up. 2) naming of a chair. If anybody wants that position, please speak up. If nobody does, I'll put my name down. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Whimsy PMC
On Tue, Apr 28, 2015 at 11:57 AM, Roman Shaposhnik ro...@shaposhnik.org wrote: ... In case you're curious -- I'd ask the same question, for example, about a community that decided to produce software that is be only applicable as an add-on for a small market share commercial offering. The Foundation does not care about a project's market size. If a *community* wants to be part of the ASF, then they are welcome. The maturity of their codebase, the size of it, the language, whether 1 person uses it, or 1 million use it. We are interested in supporting communities, not cherry-picking successful projects (by whatever definition you may care to use to define success). Cheers, -g
Re: [DISCUSS] Whimsy PMC
On Mon, Apr 27, 2015 at 10:18 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: I’ll note that the only person I see from infra that has been proposed in the current PMC is Jake Ferrel: The other person is Dan Norris. Dan is a paid contractor, but talked with me before volunteering himself. I told him about my concerns, and that I'd start this conversation since he is an infra contractor and primarily focused on contributing to fulfilling whimsy feature requests from folks like secretary@, improving testability, monitor-ability, and deployability, etc. --David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Whimsy PMC
On Mon, Apr 27, 2015 at 10:18 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: I’ll note that the only person I see from infra that has been proposed in the current PMC is Jake Ferrel: * Acquia: Jake Farrell Someone also correct me in that I don’t think Jake is a paid infra contractor. In addition the way I see this is that it is no different e.g., than contributing upstream to FreeBSD or whatever - Infra contractors may fix something and decide it’s in the ASF’s best interests to contribute it upstream - same may happen for Whimsy. But to date, ASF infra folk that are contractors I believe are not proposed to be directly paid to contribute to Whimsy. Should they do so, great. But in the famous words of Sam Ruby let’s deal with this if there is an actual data point instead of hypotheticals. I apologize for the double post. Yes, infra frequently submits patches to upstream projects. We also maintain our own set of patches for software that we use. And we write a decent amount of software. gitpubsub, all of the github integration, CMS, etc. Earlier this year, I was looking at what needed to be prioritized from an allocation of people. I spoke about a number of things with Ross and Rich, commented about conversations I had had earlier in 2014 about Whimsy. The timesaving and workflow benefits to exec officers and board members was emphasized. To be perfectly explicit - since mid-January - Dan Norris, a paid infra contractor, has been focused on Whimsy, the secretary workbench, etc. Some of that time has been understanding how things work today, defining a plan on making Whimsy better supported, improving monitoring ability, getting us closer aligned to how we want software to be deployed, and dealing with feature requests. And here is where my conflict comes in. With my VP Infra hat on, assuming there are no objections, my plan is to continue to task Dan Norris with that work. Whimsy is important to the operation of the foundation; and people come to infra when it isn't working. As long as those two remain true, Whimsy will remain something that I allocate folks time to, and in the case of Dan, I plan on allocating the bulk of his time there. With my ASF member/Board member hat on, I see this as the Foundation deciding that a project is important to the Foundation; and despite the fact that 'we don't pay for development' and that 'we pick runners not winners', we've effectively decided that this TLP is worth expending money on development for. That does worry me from a precedent standpoint. Is there a difference in us allocating developer time to a TLP as opposed to a codebase in the private infra svn tree? There are some; whether they matter or not remains a question. We don't release internal software. We don't brand it as Apache $foo. If this path is good for whimsy, it might be good for other projects infra has as well that are primarily written (now) by infra contractors. Gitpubsub, svngit2jira, etc. but could be used more widely. --David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [DISCUSS] Whimsy PMC
I've often wondered why we don't open source more of the infra code. Maybe this is the reason. Perhaps we need a new brand for such projects. Something like Apache Foo (Infra). This would be similar to the (Incubator) branding. We could even adopt some of the same policies (e.g. no press releases). If we find third parties start using and contributing to such code we can drop the (Infra) part. I'm really not sure this is necessary (see my earlier response), but since come folks have a concern I thought I'd throw it out there. If it makes you, David, as VP Infra more comfortable making infra produced code available then we should probably do it. Ross -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Tuesday, April 28, 2015 10:55 AM To: general@incubator.apache.org Subject: Re: [DISCUSS] Whimsy PMC On Mon, Apr 27, 2015 at 10:18 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: I’ll note that the only person I see from infra that has been proposed in the current PMC is Jake Ferrel: * Acquia: Jake Farrell Someone also correct me in that I don’t think Jake is a paid infra contractor. In addition the way I see this is that it is no different e.g., than contributing upstream to FreeBSD or whatever - Infra contractors may fix something and decide it’s in the ASF’s best interests to contribute it upstream - same may happen for Whimsy. But to date, ASF infra folk that are contractors I believe are not proposed to be directly paid to contribute to Whimsy. Should they do so, great. But in the famous words of Sam Ruby let’s deal with this if there is an actual data point instead of hypotheticals. I apologize for the double post. Yes, infra frequently submits patches to upstream projects. We also maintain our own set of patches for software that we use. And we write a decent amount of software. gitpubsub, all of the github integration, CMS, etc. Earlier this year, I was looking at what needed to be prioritized from an allocation of people. I spoke about a number of things with Ross and Rich, commented about conversations I had had earlier in 2014 about Whimsy. The timesaving and workflow benefits to exec officers and board members was emphasized. To be perfectly explicit - since mid-January - Dan Norris, a paid infra contractor, has been focused on Whimsy, the secretary workbench, etc. Some of that time has been understanding how things work today, defining a plan on making Whimsy better supported, improving monitoring ability, getting us closer aligned to how we want software to be deployed, and dealing with feature requests. And here is where my conflict comes in. With my VP Infra hat on, assuming there are no objections, my plan is to continue to task Dan Norris with that work. Whimsy is important to the operation of the foundation; and people come to infra when it isn't working. As long as those two remain true, Whimsy will remain something that I allocate folks time to, and in the case of Dan, I plan on allocating the bulk of his time there. With my ASF member/Board member hat on, I see this as the Foundation deciding that a project is important to the Foundation; and despite the fact that 'we don't pay for development' and that 'we pick runners not winners', we've effectively decided that this TLP is worth expending money on development for. That does worry me from a precedent standpoint. Is there a difference in us allocating developer time to a TLP as opposed to a codebase in the private infra svn tree? There are some; whether they matter or not remains a question. We don't release internal software. We don't brand it as Apache $foo. If this path is good for whimsy, it might be good for other projects infra has as well that are primarily written (now) by infra contractors. Gitpubsub, svngit2jira, etc. but could be used more widely. --David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Helping Neo4j Release an Apache2 API for Apache Projects
On Tue, Apr 28, 2015 at 11:34 AM Marko Rodriguez okramma...@gmail.com wrote: Hello, TinkerPop (http://tinkerpop.incubator.apache.org/), prior to being an Apache project, provided a tinkerpop-neo4j adaptor with each release. TinkerPop sees Neo4j as the reference OLTP implementation of TinkerPop. With TinkerPop's migration to the Apache Software Foundation, TinkerPop 3.0.0.M8-incubating (just released) had to gut Neo4j because Neo4j is licensed GPL/AGPL. Neo4j wants to continue to be TinkerPop's reference implementation. As such, Neo4j is interested in providing an Apache2 licensed version of their neo4j-api dependency/. They want to do this not only for TinkerPop, but also for other Apache projects that want to depend on Neo4j (or have in the past and gutted it for licensing reasons -- e.g. Apache Camel). However, before they go down this road of altering their product modules and licenses, they want to make sure their proposed module will be accepted as something that Apache projects can legally depend/ on. If anyone is an expert in the area of licensing (or has past experience with a similar situation), can you please review the following proposal. * Neo4j would re-license their neo4j-api module as Apache2. * This dependency would NOT depend on anything GPL/AGPL. * Neo4j would then have their neo4j-kernal module depend/ on the Apache2 neo4j-api module. * Thus, no transitive dependency and therefore, no viral GPL/APGL. * TinkerPop (or any Apache2 projects) would then ONLY depend on neo4j-api. * For testing, TinkerPop's pom.xml would have some sort of config/ stating where Neo4j is. * Thus, the tester would be responsible for manually downloading Neo4j. * Some reflection based model would be used to instantiate the connection (or some META-INF/services-style model). If kernel depends on neo4j-api and just provides an implementation of an interface that is injected at runtime, I don't see that reflection is a requirement, unless I am missing something. * TinkerPop users would also, like testers, be responsible for manually downloading Neo4j. In short, TinkerPop would depend on an Apache2 licensed neo4j-api. Some manual downloads from testers/users would be required to use the tinkerpop-neo4j component with a Neo4j database. Is this a correct way forward for Neo4j? As laid out above, this plan makes sense to me. If you want a more official ruling, re-send this e-mail to legal-discuss@; but I don't see a risk so long as Tinkerpop does not distribute any kind of GPL dependent code. Thank you very much for your time, Marko. http://markorodriguez.com
Re: [DISCUSS] Whimsy PMC
On Mon, Apr 27, 2015 at 9:25 PM, Rich Bowen rbo...@rcbowen.com wrote: ...Our mission is software for the public good. Whimsy is software for the ASF's good. How does the public benefit from Whimsy?... It makes us more efficient. As a board member, Whimsy helps me spend less time on the boring mechanics of our board meetings, which translates to more brain cycles available to make decisions that (hopefully) help us in our primary mission. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Whimsy PMC
On Tue, Apr 28, 2015 at 9:37 AM, Roman Shaposhnik ro...@shaposhnik.org wrote: Graduation does not require diversity of the PMC. It requires that the project be run according to the Apache Way which includes being open to any viewpoint brought to the project, regardless of the source. Furthermore, the initial set of committers covers a wide range of contributing orgs (although we are all doing this with ASF hats). It is actually neither. It is viability of the community outside of requirements of a very particular organization. IOW, the only way for me to make sure that community is not joined at the hip with ASF INFRA would be to see other foundations adopt the tools and joining the community. Frankly, I can easily see that other aspects of the ASF could make good use of this same sort of capability. Generating the draft incubator report is an example of a task that currently requires a command line program to be run in a partially documented environment with partially documented inputs. A stable web application environment would make this much, much simpler, especially for new chairs like me. I can see that there might be a wish to keep missions separate, but it isn't implausible to broaden the mission here to support inward facing capabilities. This would provide an opportunity to grow the community as well.
Re: [DISCUSS] Whimsy PMC
On Tue, Apr 28, 2015 at 3:21 PM, Ted Dunning ted.dunn...@gmail.com wrote: On Tue, Apr 28, 2015 at 9:37 AM, Roman Shaposhnik ro...@shaposhnik.org wrote: Graduation does not require diversity of the PMC. It requires that the project be run according to the Apache Way which includes being open to any viewpoint brought to the project, regardless of the source. Furthermore, the initial set of committers covers a wide range of contributing orgs (although we are all doing this with ASF hats). It is actually neither. It is viability of the community outside of requirements of a very particular organization. IOW, the only way for me to make sure that community is not joined at the hip with ASF INFRA would be to see other foundations adopt the tools and joining the community. Frankly, I can easily see that other aspects of the ASF could make good use of this same sort of capability. Generating the draft incubator report is an example of a task that currently requires a command line program to be run in a partially documented environment with partially documented inputs. A stable web application environment would make this much, much simpler, especially for new chairs like me. I can see that there might be a wish to keep missions separate, but it isn't implausible to broaden the mission here to support inward facing capabilities. This would provide an opportunity to grow the community as well. +1 Over time, I'd like to move into a teach the teachers role. I see no reason why the IPMC couldn't have a tool that is as functional and user friendly as the board agenda tool that assembles reports. This would be a wonderful topic to explore on the dev list once whimsy is approved. What I would be looking for is a volunteer. To prep for this, it would be helpful if that volunteer was able to get the board agenda tool up and running on their own machine. With a working base, we can explore together what changes could be made to the existing tool, or if a new tool is required (and if, so, what common code should be factored out to support both tools). https://github.com/rubys/whimsy-agenda#readme - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Whimsy PMC
On Tue, Apr 28, 2015 at 12:21 PM, Shane Curcuru a...@shanecurcuru.org wrote: On 4/27/15 10:05 PM, Greg Stein wrote: On Mon, Apr 27, 2015 at 8:51 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: It's a tough one. We could be setting a precedence here that we absolutely do not want to set. On the other hand, it's problematic (not to mention simply ridiculous) if the foundation not being able to use Apache software because we don't pay for development and might want to submit a patch upstream. As long as all committers are equal and earn their merit in the traditional way I don't see a problem from the projects side. IN this instance the ASF is just another contributor to the project. This means the foundation never pays for development to something like the foundation never pays for development except where the modification is made as part of our normal infrastructure operations. On these rare occasions the foundation is just another employer and the contributor is just another community member. Changes are contributed upstream through the normal contribution process. There is no special role for ASF infra contractors. Yes, that's a separate and important point. Every project PMC determines merit for their project independently. Just because someone is root@ does not mean they get a free committer bit on project X or binding votes - unless that PMC votes them in. The ASF pays for Infra contractors. Their job/role is to maintain our systems. Sometimes their duty *may* be to contribute software to $Project (wherever that may be). It's pretty simple. Infra contractors are responsible to code/maintain software and systems that the ASF needs to operate, including a variety of services that we provide to our projects. Their duty is to build stuff the ASF needs for our own operations. It doesn't matter where that code goes; Whimsy is no more special than STeVe is for that matter. That is *very* distinct from paying a person to contribute directly to $ASFProject. Exactly. The ASF does not pay infra contractors to write code for anyone else - only for our own organization's needs. Luckily, some of those needs require software that may also be useful for the rest of the world - but our own needs are what we do paid work for. I don't see this being a problem. 8-) We seem to be in agreement, but I still sense reluctance from Rich and David. I'd like to suggest a frame of reference that will make future discussions on topics like this one easier. The concern is that if the ASF directly or indirectly funds project X, what happens when project Y wants to be funded? The frame of reference I'd suggest is who makes the call. The Whimsy PMC is not asking for money. No sponsor is directly asking for money to be earmarked for Whimsy development. The board is not asking for this. The board does ask that the President look after operations (a.k.a., keep the foundation running). The President has identified tools such as the board agenda and secretary workbench as strategic. VP of operations is investigating a what it will take to support such tools. Where it all comes together is in the board approving budget requests. TL;DR: Since Whimsy didn't ask for this, I don't believe that we setting a dangerous precedent whereby future projects can lobby to be funded. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Whimsy PMC
Hi Rich, -Original Message- From: Rich Bowen rbo...@rcbowen.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Tuesday, April 28, 2015 at 5:44 AM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: [DISCUSS] Whimsy PMC On 04/27/2015 10:18 PM, Mattmann, Chris A (3980) wrote: I’ll note that the only person I see from infra that has been proposed in the current PMC is Jake Ferrel: * Acquia: Jake Farrell Someone also correct me in that I don’t think Jake is a paid infra contractor. In addition the way I see this is that it is no different e.g., than contributing upstream to FreeBSD or whatever - Infra contractors may fix something and decide it’s in the ASF’s best interests to contribute it upstream - same may happen for Whimsy. But to date, ASF infra folk that are contractors I believe are not proposed to be directly paid to contribute to Whimsy. Should they do so, great. But in the famous words of Sam Ruby let’s deal with this if there is an actual data point instead of hypotheticals. David states in his initial email that he has a paid contractor who hase working on Whimsy as one of his paid duties. This is not a hypothetical. Sorry I missed that email I guess (huge shock). I’ll go try and find it. Cheers, Chris ++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
Helping Neo4j Release an Apache2 API for Apache Projects
Hello, TinkerPop (http://tinkerpop.incubator.apache.org/), prior to being an Apache project, provided a tinkerpop-neo4j adaptor with each release. TinkerPop sees Neo4j as the reference OLTP implementation of TinkerPop. With TinkerPop's migration to the Apache Software Foundation, TinkerPop 3.0.0.M8-incubating (just released) had to gut Neo4j because Neo4j is licensed GPL/AGPL. Neo4j wants to continue to be TinkerPop's reference implementation. As such, Neo4j is interested in providing an Apache2 licensed version of their neo4j-api dependency/. They want to do this not only for TinkerPop, but also for other Apache projects that want to depend on Neo4j (or have in the past and gutted it for licensing reasons -- e.g. Apache Camel). However, before they go down this road of altering their product modules and licenses, they want to make sure their proposed module will be accepted as something that Apache projects can legally depend/ on. If anyone is an expert in the area of licensing (or has past experience with a similar situation), can you please review the following proposal. * Neo4j would re-license their neo4j-api module as Apache2. * This dependency would NOT depend on anything GPL/AGPL. * Neo4j would then have their neo4j-kernal module depend/ on the Apache2 neo4j-api module. * Thus, no transitive dependency and therefore, no viral GPL/APGL. * TinkerPop (or any Apache2 projects) would then ONLY depend on neo4j-api. * For testing, TinkerPop's pom.xml would have some sort of config/ stating where Neo4j is. * Thus, the tester would be responsible for manually downloading Neo4j. * Some reflection based model would be used to instantiate the connection (or some META-INF/services-style model). * TinkerPop users would also, like testers, be responsible for manually downloading Neo4j. In short, TinkerPop would depend on an Apache2 licensed neo4j-api. Some manual downloads from testers/users would be required to use the tinkerpop-neo4j component with a Neo4j database. Is this a correct way forward for Neo4j? Thank you very much for your time, Marko. http://markorodriguez.com
