RE: What is The Apache Way?
Good suggestion. Sent from my Windows Phone From: Jim Jagielskimailto:j...@jagunet.com Sent: 1/13/2015 9:33 AM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: What is The Apache Way? Perhaps it is time we hired a contractor to draw up the one document of truth? My thoughts are that Sally certainly groks the Apache Way, and knows who to contact for more detailed info and clarification. Why not add this as a task to HALO, and put some $$$ towards it? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: What is The Apache Way?
Even better suggestion. Do you want to take it up with Sally directly? (and big thanks in advance) Sent from my Windows Phone From: Jim Jagielskimailto:j...@jagunet.com Sent: 1/13/2015 9:33 AM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: What is The Apache Way? If we go that route, I'll own it, since it makes sense as a VP Legal responsibility in a lot of ways. On Jan 13, 2015, at 12:29 PM, Jim Jagielski j...@jagunet.com wrote: Perhaps it is time we hired a contractor to draw up the one document of truth? My thoughts are that Sally certainly groks the Apache Way, and knows who to contact for more detailed info and clarification. Why not add this as a task to HALO, and put some $$$ towards it? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE][Proposal] TinkerPop: A Graph Computing Framework [RE-SUBMISSION]
+1. Colm. On Tue, Jan 13, 2015 at 11:33 AM, Daniel Gruno humbed...@apache.org wrote: +1 binding as well. On 2015-01-10 07:07, Alan D. Cabrera wrote: +1 binding Regards, Alan On Jan 9, 2015, at 8:58 AM, Hadrian Zbarcea hzbar...@gmail.com wrote: +1 From the conversation with Marko, he intended to submit this as a formal vote, but didn't use the regular voting template. Voting will remain open until at least January 15, 2015 18:00 ET. Cheers, Hadrian On 01/09/2015 11:35 AM, Marko Rodriguez wrote: Hello everyone, Over the last 2 weeks, TinkerPop's proposal has been worked on with support from: * David Nalley (champion) * Rich Bowen (mentor) * Hadrian Zbarcea (mentor) * Daniel Gruno (mentor) * Marko Rodriguez (submitting on behalf of TinkerPop) We feel it is now in prime shape from submission to vote. Enjoy!. (URL to wiki version: https://wiki.apache.org/ incubator/TinkerPopProposal) A. Abstract TinkerPop http://tinkerpop.com/ is a graph computing framework written in Java. A graph http://en.wikipedia.org/wiki/ Graph_%28mathematics%29 is a data structure composed of vertices and edges and is useful for modeling complex domains with arbitrary relations (edges, links, lines) between entities (vertices, objects, dots). TinkerPop https://wiki.apache.org/incubator/TinkerPop provides a core API that graph system vendors can implement. There are various types of graph systems including in-memory graph libraries, OLTP graph databases, and OLAP graph processors (see On Graph Computing http://markorodriguez.com/ 2013/01/09/on-graph-computing/ for more information). Once the core interfaces are implemented, the underlying graph system can be queried using the graph traversal language Gremlin and processed withTinkerPop https://wiki.apache.org/incubator/TinkerPop-enabled algorithms. For many, TinkerPop https://wiki.apache.org/incubator/TinkerPop is seen as the JDBC http://en.wikipedia.org/wiki/Java_Database_Connectivity of the graph computing community. B. Proposal TinkerPop https://wiki.apache.org/incubator/TinkerPop was formed in 2009 and is currently in the milestone series of 3.0.0. From the start, TinkerPop https://wiki.apache.org/incubator/TinkerPop has provided its software open source and free to use for which ever reason (commercial or otherwise). Initially the license was BSD, but as of TinkerPop3 https://wiki.apache.org/incubator/TinkerPop3, the license was changed to Apache2. The TinkerPop https://wiki.apache.org/incubator/TinkerPop team is composed of developers, evangelists, and representatives from graph system vendors (see TinkerPop Contributors http://www.tinkerpop.com/ docs/3.0.0-SNAPSHOT/#tinkerpop-contributors for more information). TinkerPop https://wiki.apache.org/incubator/TinkerPop has done its best to remain vendor agnostic and works closely with all vendors to ensure that the constructs within TinkerPop https://wiki.apache.org/ incubator/TinkerPop are able to accommodate the requirements of the underlying graph system. To date, 12 TinkerPop https://wiki.apache.org/incubator/TinkerPop recognized graph system vendors provide TinkerPop https://wiki.apache.org/incubator/TinkerPop implementations. We believe that by joining The Apache Software Foundation, our vendors, users, and contributors will feel more comfortable in terms of legal protected, in terms of wider-adoption, and in terms of project stability. C. Background TinkerPop https://wiki.apache.org/incubator/TinkerPop has had steady, active development since 2009 when it was founded. Over the years, the Gremlin query language within TinkerPop https://wiki.apache.org/ incubator/TinkerPop has been adopted by various JVM languages and as such, there exists Gremlin-Groovy, Gremlin-Scala, Gremlin-Clojure, Gremlin-JavaScript https://wiki.apache.org/incubator/JavaScript, and the like. In many ways, Gremlin is seen as a traversal style that can be readily adopted within the programming constructs of the developer's native language --- both on and off the JVM. TinkerPop https://wiki.apache.org/incubator/TinkerPop is not bound to the JVM in that developers wishing to interact with a TinkerPop https://wiki.apache.org/incubator/TinkerPop-enabled graph system can leverage Gremlin Server which provides over the wire communication as well as the entry point for non-JVM language bindings. TinkerPop https://wiki.apache.org/incubator/TinkerPop is being used is production graph-based applications around the world and is only getting better with age. D. Rationale The graph computing space has grown over the years to encompass numerous graph database and graph processing systems. TinkerPop https://wiki.apache.org/incubator/TinkerPop was created as a unifying framework for interoperability, language standardization, and data model standardization. This framework makes it simple to plug and play the back-end graph
Re: [Proposal] TinkerPop: A Graph Computing Framework [RE-SUBMISSION]
On 01/10/2015 01:18 AM, Ted Dunning wrote: This still only has 3 committers. How is the project going to function with such a small group? I don't see that there has been a realistic answer to this question. This has been discussed by the (proposed) mentors along with the community members, and we have also identified this as a place where work needs to be done to identify what people in the community might be added to that list during incubation. We do not, however, feel that it is a barrier to entering incubation - merely something to be addressed during incubation. On Fri, Jan 9, 2015 at 10:35 AM, Marko Rodriguez okramma...@gmail.com mailto:okramma...@gmail.com wrote: Hello everyone, Over the last 2 weeks, TinkerPop's proposal has been worked on with support from: * David Nalley (champion) * Rich Bowen (mentor) * Hadrian Zbarcea (mentor) * Daniel Gruno (mentor) * Marko Rodriguez (submitting on behalf of TinkerPop) We feel it is now in prime shape from submission to vote. Enjoy!. (URL to wiki version: https://wiki.apache.org/incubator/TinkerPopProposal) A. Abstract TinkerPop http://tinkerpop.com/ is a graph computing framework written in Java. A graph http://en.wikipedia.org/wiki/Graph_%28mathematics%29 is a data structure composed of vertices and edges and is useful for modeling complex domains with arbitrary relations (edges, links, lines) between entities (vertices, objects, dots). TinkerPop https://wiki.apache.org/incubator/TinkerPop provides a core API that graph system vendors can implement. There are various types of graph systems including in-memory graph libraries, OLTP graph databases, and OLAP graph processors (see On Graph Computing http://markorodriguez.com/2013/01/09/on-graph-computing/ for more information). Once the core interfaces are implemented, the underlying graph system can be queried using the graph traversal language Gremlin and processed withTinkerPop https://wiki.apache.org/incubator/TinkerPop-enabled algorithms. For many, TinkerPop https://wiki.apache.org/incubator/TinkerPop is seen as the JDBC http://en.wikipedia.org/wiki/Java_Database_Connectivity of the graph computing community. B. Proposal TinkerPop https://wiki.apache.org/incubator/TinkerPop was formed in 2009 and is currently in the milestone series of 3.0.0. From the start, TinkerPop https://wiki.apache.org/incubator/TinkerPop has provided its software open source and free to use for which ever reason (commercial or otherwise). Initially the license was BSD, but as of TinkerPop3 https://wiki.apache.org/incubator/TinkerPop3, the license was changed to Apache2. The TinkerPop https://wiki.apache.org/incubator/TinkerPop team is composed of developers, evangelists, and representatives from graph system vendors (see TinkerPop Contributors http://www.tinkerpop.com/docs/3.0.0-SNAPSHOT/#tinkerpop-contributors for more information). TinkerPop https://wiki.apache.org/incubator/TinkerPop has done its best to remain vendor agnostic and works closely with all vendors to ensure that the constructs within TinkerPop https://wiki.apache.org/incubator/TinkerPop are able to accommodate the requirements of the underlying graph system. To date, 12 TinkerPop https://wiki.apache.org/incubator/TinkerPop recognized graph system vendors provide TinkerPop https://wiki.apache.org/incubator/TinkerPop implementations. We believe that by joining The Apache Software Foundation, our vendors, users, and contributors will feel more comfortable in terms of legal protected, in terms of wider-adoption, and in terms of project stability. C. Background TinkerPop https://wiki.apache.org/incubator/TinkerPop has had steady, active development since 2009 when it was founded. Over the years, the Gremlin query language within TinkerPop https://wiki.apache.org/incubator/TinkerPop has been adopted by various JVM languages and as such, there exists Gremlin-Groovy, Gremlin-Scala, Gremlin-Clojure, Gremlin-JavaScript https://wiki.apache.org/incubator/JavaScript, and the like. In many ways, Gremlin is seen as a traversal style that can be readily adopted within the programming constructs of the developer's native language --- both on and off the JVM. TinkerPop https://wiki.apache.org/incubator/TinkerPop is not bound to the JVM in that developers wishing to interact with a TinkerPop https://wiki.apache.org/incubator/TinkerPop-enabled graph system can leverage Gremlin Server which provides over the wire communication as well as the entry point for non-JVM language bindings. TinkerPop https://wiki.apache.org/incubator/TinkerPop is being used is production graph-based applications around the world and is only getting better with
Re: What is The Apache Way?
Perhaps it is time we hired a contractor to draw up the one document of truth? My thoughts are that Sally certainly groks the Apache Way, and knows who to contact for more detailed info and clarification. Why not add this as a task to HALO, and put some $$$ towards it? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: What is The Apache Way?
If we go that route, I'll own it, since it makes sense as a VP Legal responsibility in a lot of ways. On Jan 13, 2015, at 12:29 PM, Jim Jagielski j...@jagunet.com wrote: Perhaps it is time we hired a contractor to draw up the one document of truth? My thoughts are that Sally certainly groks the Apache Way, and knows who to contact for more detailed info and clarification. Why not add this as a task to HALO, and put some $$$ towards it? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: What is The Apache Way?
On Tue, Jan 13, 2015 at 11:23 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Well, David, I'm afraid you are the authoritative source on the policy you use as an example. :) Well - I suppose I did open myself up for that. If it's not documented and that's a problem then it's *your* problem. You could (given even more time to volunteer to the ASF, solve it however you like (e.g. Write the doc, ask the community to write it, ask for budget to have a contract write it, something else), but it's you and the infra team that own this. So, infra has a number of policies - like not keeping more than the current release on dist, giving us a heads up if your artifacts are going to be more 1GB, but they are largely centered around efficient operation of infrastructure, and not Apache Doctrine. Defining (and by extension enforcing) Apache Doctrine, means that infrastructure becomes the Foundation's policeman, at least in certain matters. Infrastructure, derives authority from the office of the President. Based on my reading of the bylaws, and the almost recent discussion around Brand issues - I walked away with the fact that the office of the President may not be able to set binding policy on projects. (differentiated from binding policy of how you may use resources of the Foundation). In the specific example I referenced - which came up in May (on board-private because there was a security issue related to it) I was told to carry the issue to the public board mailing list after the security issue was dealt with because it needed discussing. It did get discussed - release policy (which I think was later declared to be a legal issue), which is a board committee. After that thread revealed that there was no written policy, I explicitly asked several directors (individually) if that was within my scope to define, so as to remove the ambiguity and walked away with the impression that most of them felt it was not within my level of authority. I hope you won't take this personally, its not meant that way. As a volunteer you do a fantastic job and we are all immensely grateful. However, you did feed me a perfect way to illustrate the point I've been trying to make when highlighting docs and saying patches welcome. Not at all. My assumption was that 'setting binding policy on projects' was something specifically excluded from my level of authority, as an officer derived from the Office of the President. If that is not the case, I am happy to define and publish such things within the realm of infrastructure. Perhaps it is time we hired a contractor to draw up the one document of truth? I'm working on the 2015 budget now. Any volunteers to own this? Ownership is ensuring that the individual gets access to all the appropriate VPs and that those VPs are able to provide the necessary input. I think Marvin could manage this well (yes, this is me pushing you in front of the bus, Marvin. My apologies). Failing that, I'm happy to tackle management of that. --David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: What is The Apache Way?
Thanks for taking my comment the way it was intended (to fuel productive debate) :-) You are right that VPs don't set policy but they should write policy and submit to the board for tuning and/or approval/rejection. In turn those VPs will typically consult with their committee members. It really should be bottom up. This scales well. Looking to a board of 9 overworked directors to do everything for 150+ projects (and potentially adding podlings based on some IPMC recommendations) does not scale. That being said, you are correct the release policy is really a legal issue and thus is under VP Legal, with VP Infra needing to approve any policy since it has impact on what infra needs to deliver. Fortunately Jim has indicated he feels he owns much of this as VP Legal so you are off the hook and made your point well - a good result for you I think :-) Here's to Jim for stepping up and offering to try to heard the sheep on this one. Ross -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Tuesday, January 13, 2015 9:37 AM To: general@incubator.apache.org Subject: Re: What is The Apache Way? On Tue, Jan 13, 2015 at 11:23 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Well, David, I'm afraid you are the authoritative source on the policy you use as an example. :) Well - I suppose I did open myself up for that. If it's not documented and that's a problem then it's *your* problem. You could (given even more time to volunteer to the ASF, solve it however you like (e.g. Write the doc, ask the community to write it, ask for budget to have a contract write it, something else), but it's you and the infra team that own this. So, infra has a number of policies - like not keeping more than the current release on dist, giving us a heads up if your artifacts are going to be more 1GB, but they are largely centered around efficient operation of infrastructure, and not Apache Doctrine. Defining (and by extension enforcing) Apache Doctrine, means that infrastructure becomes the Foundation's policeman, at least in certain matters. Infrastructure, derives authority from the office of the President. Based on my reading of the bylaws, and the almost recent discussion around Brand issues - I walked away with the fact that the office of the President may not be able to set binding policy on projects. (differentiated from binding policy of how you may use resources of the Foundation). In the specific example I referenced - which came up in May (on board-private because there was a security issue related to it) I was told to carry the issue to the public board mailing list after the security issue was dealt with because it needed discussing. It did get discussed - release policy (which I think was later declared to be a legal issue), which is a board committee. After that thread revealed that there was no written policy, I explicitly asked several directors (individually) if that was within my scope to define, so as to remove the ambiguity and walked away with the impression that most of them felt it was not within my level of authority. I hope you won't take this personally, its not meant that way. As a volunteer you do a fantastic job and we are all immensely grateful. However, you did feed me a perfect way to illustrate the point I've been trying to make when highlighting docs and saying patches welcome. Not at all. My assumption was that 'setting binding policy on projects' was something specifically excluded from my level of authority, as an officer derived from the Office of the President. If that is not the case, I am happy to define and publish such things within the realm of infrastructure. Perhaps it is time we hired a contractor to draw up the one document of truth? I'm working on the 2015 budget now. Any volunteers to own this? Ownership is ensuring that the individual gets access to all the appropriate VPs and that those VPs are able to provide the necessary input. I think Marvin could manage this well (yes, this is me pushing you in front of the bus, Marvin. My apologies). Failing that, I'm happy to tackle management of that. --David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator
+1 binding have fun jan i On Tuesday, January 13, 2015, Alan D. Cabrera l...@toolazydogs.com javascript:_e(%7B%7D,'cvml','l...@toolazydogs.com'); wrote: +1 binding Regards, Alan On Jan 5, 2015, at 10:15 AM, Hal Lockhart hal.lockh...@oracle.com wrote: I call a vote to accept OpenAz as a new Incubator project. The proposal can be found here: https://wiki.apache.org/incubator/OpenAZProposal and is included below in this email. Voting will remain open until at least January 20, 2015 23:00 ET. Hal Lockhart --- Abstract OpenAz is a project to create tools and libraries to enable the development of Attribute-based Access Control (ABAC) Systems in a variety of languages. In general the work is at least consistent with or actually conformant to the OASIS XACML Standard. Proposal Generally the work falls into two categories: ready to use tools which implement standardized or well understood components of an ABAC system and design proposals and proof of concept code relating to less well understood or experimental aspects of the problem. Much of the work to date has revolved around defining interfaces enabling a PEP to request an access control decision from a PDP. The XACML standard defines an abstract request format in xml and protocol wire formats in xaml and json, but it does not specify programmatic interfaces in any language. The standard says that the use of XML (or JSON) is not required only the semantic equivalent. The first Interface, AzAPI is modeled closely on the XACML defined interface, expressed in Java. One of the goals was to support calls to both a PDP local to the same process and a PDP in a remote server. AzAPI includes the interface, reference code to handle things like the many supported datatypes in XACML and glue code to mate it to the open source Sun XACML implementation. Because of the dependence on Sun XACML (which is XACML 2.0) the interface was missing some XACML 3.0 features. More recently this was corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was done by the JPMC team to support calling a remote PDP. WSo2 is also pursuing this capability. A second, higher level interface, PEPAPI was also defined. PEPAPI is more intended for application developers with little knowledge of XACML. It allows Java objects which contain attribute information to be passed in. Conversion methods, called mappers extract information from the objects and present it in the format expected by XACML. Some implementers have chosen to implement PEPAPI directly against their PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface which closely matches the Java one. Examples of more speculative work include: proposals for registration and dispatch of Obligation and Advice handlers, a scheme called AMF to tell PIPs how to retrieve attributes and PIP code to implement it, discussion of PoC code to demonstrate the use of XACML policies to drive OAuth interations and a proposal to use XACML policies to express OAuth scope. ATT has recently contributed their extensive XACML framework to the project. The ATT framework represents the entire XACML 3.0 object set as a collection of Java interfaces and standard implementations of those interfaces. The ATT PDP engine is built on top of this framework and represents a complete implementation of a XACML 3.0 PDP, including all of the multi-decision profiles. In addition, the framework also contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and XACML JSON Profile v1.0 WD 14. The PEP API includes annotation functionality, allowing application developers to simply annotate a Java class to provide attributes for a request. The annotation support removes the need for application developers to learn much of the API. The ATT framework also includes interfaces and implementations to standardize development of PIP engines that are used by the ATT PDP implementation, and can be used by other implementations built on top of the ATT framework. The framework also includes interfaces and implementations for a PAP distributed cloud infrastructure of PDP nodes that includes support for policy distribution and pip configurations. This PAP infrastructure includes a web application administrative console that contains a XACML 3.0 policy editor, attribute dictionary support, and management of PDP RESTful node instances. In addition, there are tools available for policy simulation. Background Access Control is in some ways the most basic IT Security service. It consists of making a decision about whether a particular request should be allowed and enforcing that decision. Aside from schemes like permission bits and Access Control Lists (ACLs) the most common way access control is implemented is as code in a server or application
Re: Clear expectations
On Tue, Jan 13, 2015 at 1:36 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Can you please expand on I think the answer starts with the very skepticism of top-down governance which has in large part kept us from having clear rules up till now. I'm not clear on what the skepticism is that you refer to as these threads have indicated that there are at least two very different views on whether there is, or is not, top down governance in the ASF. I meant to tip my hat to those who have spared Apache from adopting cumbersome absolute rules over the years. By skeptics, I was thinking of people who, when presented with an elaborate policy proposal, question whether some or all of it is truly required. It's clear that this undertaking calls for a governs best which governs least approach. We want the simplest rules possible; committing to concrete language is inherently constraining, and we want to minimize that effect. But just because Apache's requirements are underspecified right now doesn't mean we don't have any. Establishing where the rules begin and end will allow projects to spend less time researching and arguing over what is required. Projects may even discover newfound flexibility. For example, when the Incubator PMC clarified its collective understanding of release policy, it became able to reach consensus on approving many release candidates which would previously have been sent back. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Clear expectations
Well with that clarification I'm a very strong +1 on everything you said :-) Ross -Original Message- From: Marvin Humphrey [mailto:mar...@rectangular.com] Sent: Tuesday, January 13, 2015 6:49 PM To: general@incubator.apache.org Cc: Shane Curcuru Subject: Re: Clear expectations On Tue, Jan 13, 2015 at 1:36 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Can you please expand on I think the answer starts with the very skepticism of top-down governance which has in large part kept us from having clear rules up till now. I'm not clear on what the skepticism is that you refer to as these threads have indicated that there are at least two very different views on whether there is, or is not, top down governance in the ASF. I meant to tip my hat to those who have spared Apache from adopting cumbersome absolute rules over the years. By skeptics, I was thinking of people who, when presented with an elaborate policy proposal, question whether some or all of it is truly required. It's clear that this undertaking calls for a governs best which governs least approach. We want the simplest rules possible; committing to concrete language is inherently constraining, and we want to minimize that effect. But just because Apache's requirements are underspecified right now doesn't mean we don't have any. Establishing where the rules begin and end will allow projects to spend less time researching and arguing over what is required. Projects may even discover newfound flexibility. For example, when the Incubator PMC clarified its collective understanding of release policy, it became able to reach consensus on approving many release candidates which would previously have been sent back. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator
+1 from me! Paul On Thu, Jan 8, 2015 at 6:10 PM, Dilli Arumugam darumu...@hortonworks.com wrote: +1 On Thu, Jan 8, 2015 at 7:14 PM, DRAGOSH, PAMELA L (PAM) pdrag...@research.att.com wrote: +1 Pam Pamela L. Dragosh PMTS Research One ATT Way 4D-170P Bedminster, NJ 07921 908-901-2120 - Office pdrag...@research.att.com On 1/5/15, 2:04 PM, Hal Lockhart hal.lockh...@oracle.com wrote: I added a comma and the word and to the Mentors section. The Mentors are: Emmanuel Lécharny, Colm O hEigeartaigh and Hadrian Zbarcea Do you see any other formatting errors? Hal -Original Message- From: Roman Shaposhnik [mailto:ro...@shaposhnik.org] Sent: Monday, January 05, 2015 1:24 PM To: general@incubator.apache.org Subject: Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator Hi! can you please fix the formatting issues? For example, I can't even tell the exact list of mentors you're proposing. Thanks, Roman. On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart hal.lockh...@oracle.com wrote: I call a vote to accept OpenAz as a new Incubator project. The proposal can be found here: https://wiki.apache.org/incubator/OpenAZProposal and is included below in this email. Voting will remain open until at least January 20, 2015 23:00 ET. Hal Lockhart - - - Abstract OpenAz is a project to create tools and libraries to enable the development of Attribute-based Access Control (ABAC) Systems in a variety of languages. In general the work is at least consistent with or actually conformant to the OASIS XACML Standard. Proposal Generally the work falls into two categories: ready to use tools which implement standardized or well understood components of an ABAC system and design proposals and proof of concept code relating to less well understood or experimental aspects of the problem. Much of the work to date has revolved around defining interfaces enabling a PEP to request an access control decision from a PDP. The XACML standard defines an abstract request format in xml and protocol wire formats in xaml and json, but it does not specify programmatic interfaces in any language. The standard says that the use of XML (or JSON) is not required only the semantic equivalent. The first Interface, AzAPI is modeled closely on the XACML defined interface, expressed in Java. One of the goals was to support calls to both a PDP local to the same process and a PDP in a remote server. AzAPI includes the interface, reference code to handle things like the many supported datatypes in XACML and glue code to mate it to the open source Sun XACML implementation. Because of the dependence on Sun XACML (which is XACML 2.0) the interface was missing some XACML 3.0 features. More recently this was corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was done by the JPMC team to support calling a remote PDP. WSo2 is also pursuing this capability. A second, higher level interface, PEPAPI was also defined. PEPAPI is more intended for application developers with little knowledge of XACML. It allows Java objects which contain attribute information to be passed in. Conversion methods, called mappers extract information from the objects and present it in the format expected by XACML. Some implementers have chosen to implement PEPAPI directly against their PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface which closely matches the Java one. Examples of more speculative work include: proposals for registration and dispatch of Obligation and Advice handlers, a scheme called AMF to tell PIPs how to retrieve attributes and PIP code to implement it, discussion of PoC code to demonstrate the use of XACML policies to drive OAuth interations and a proposal to use XACML policies to express OAuth scope. ATT has recently contributed their extensive XACML framework to the project. The ATT framework represents the entire XACML 3.0 object set as a collection of Java interfaces and standard implementations of those interfaces. The ATT PDP engine is built on top of this framework and represents a complete implementation of a XACML 3.0 PDP, including all of the multi-decision profiles. In addition, the framework also contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and XACML JSON Profile v1.0 WD 14. The PEP API includes annotation functionality, allowing application developers to simply annotate a Java class to provide attributes for a request. The annotation support removes the need for application developers to learn much of the API.
Re: [VOTE][Proposal] TinkerPop: A Graph Computing Framework [RE-SUBMISSION]
+1 binding as well. On 2015-01-10 07:07, Alan D. Cabrera wrote: +1 binding Regards, Alan On Jan 9, 2015, at 8:58 AM, Hadrian Zbarcea hzbar...@gmail.com wrote: +1 From the conversation with Marko, he intended to submit this as a formal vote, but didn't use the regular voting template. Voting will remain open until at least January 15, 2015 18:00 ET. Cheers, Hadrian On 01/09/2015 11:35 AM, Marko Rodriguez wrote: Hello everyone, Over the last 2 weeks, TinkerPop's proposal has been worked on with support from: * David Nalley (champion) * Rich Bowen (mentor) * Hadrian Zbarcea (mentor) * Daniel Gruno (mentor) * Marko Rodriguez (submitting on behalf of TinkerPop) We feel it is now in prime shape from submission to vote. Enjoy!. (URL to wiki version: https://wiki.apache.org/incubator/TinkerPopProposal) A. Abstract TinkerPop http://tinkerpop.com/ is a graph computing framework written in Java. A graph http://en.wikipedia.org/wiki/Graph_%28mathematics%29 is a data structure composed of vertices and edges and is useful for modeling complex domains with arbitrary relations (edges, links, lines) between entities (vertices, objects, dots). TinkerPop https://wiki.apache.org/incubator/TinkerPop provides a core API that graph system vendors can implement. There are various types of graph systems including in-memory graph libraries, OLTP graph databases, and OLAP graph processors (see On Graph Computing http://markorodriguez.com/2013/01/09/on-graph-computing/ for more information). Once the core interfaces are implemented, the underlying graph system can be queried using the graph traversal language Gremlin and processed withTinkerPop https://wiki.apache.org/incubator/TinkerPop-enabled algorithms. For many, TinkerPop https://wiki.apache.org/incubator/TinkerPop is seen as the JDBC http://en.wikipedia.org/wiki/Java_Database_Connectivity of the graph computing community. B. Proposal TinkerPop https://wiki.apache.org/incubator/TinkerPop was formed in 2009 and is currently in the milestone series of 3.0.0. From the start, TinkerPop https://wiki.apache.org/incubator/TinkerPop has provided its software open source and free to use for which ever reason (commercial or otherwise). Initially the license was BSD, but as of TinkerPop3 https://wiki.apache.org/incubator/TinkerPop3, the license was changed to Apache2. The TinkerPop https://wiki.apache.org/incubator/TinkerPop team is composed of developers, evangelists, and representatives from graph system vendors (see TinkerPop Contributors http://www.tinkerpop.com/docs/3.0.0-SNAPSHOT/#tinkerpop-contributors for more information). TinkerPop https://wiki.apache.org/incubator/TinkerPop has done its best to remain vendor agnostic and works closely with all vendors to ensure that the constructs within TinkerPop https://wiki.apache.org/incubator/TinkerPop are able to accommodate the requirements of the underlying graph system. To date, 12 TinkerPop https://wiki.apache.org/incubator/TinkerPop recognized graph system vendors provide TinkerPop https://wiki.apache.org/incubator/TinkerPop implementations. We believe that by joining The Apache Software Foundation, our vendors, users, and contributors will feel more comfortable in terms of legal protected, in terms of wider-adoption, and in terms of project stability. C. Background TinkerPop https://wiki.apache.org/incubator/TinkerPop has had steady, active development since 2009 when it was founded. Over the years, the Gremlin query language within TinkerPop https://wiki.apache.org/incubator/TinkerPop has been adopted by various JVM languages and as such, there exists Gremlin-Groovy, Gremlin-Scala, Gremlin-Clojure, Gremlin-JavaScript https://wiki.apache.org/incubator/JavaScript, and the like. In many ways, Gremlin is seen as a traversal style that can be readily adopted within the programming constructs of the developer's native language --- both on and off the JVM. TinkerPop https://wiki.apache.org/incubator/TinkerPop is not bound to the JVM in that developers wishing to interact with a TinkerPop https://wiki.apache.org/incubator/TinkerPop-enabled graph system can leverage Gremlin Server which provides over the wire communication as well as the entry point for non-JVM language bindings. TinkerPop https://wiki.apache.org/incubator/TinkerPop is being used is production graph-based applications around the world and is only getting better with age. D. Rationale The graph computing space has grown over the years to encompass numerous graph database and graph processing systems. TinkerPop https://wiki.apache.org/incubator/TinkerPop was created as a unifying framework for interoperability, language standardization, and data model standardization. This framework makes it simple to plug and play the back-end graph implementation without affecting the developer's code. This is analogous to the way in which the JDBC allows users to swap relational databases while keeping the
Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator
+1 On Jan 13, 2015, at 4:58 AM, Paul Fremantle pzf...@gmail.com wrote: +1 from me! Paul On Thu, Jan 8, 2015 at 6:10 PM, Dilli Arumugam darumu...@hortonworks.com wrote: +1 On Thu, Jan 8, 2015 at 7:14 PM, DRAGOSH, PAMELA L (PAM) pdrag...@research.att.com wrote: +1 Pam Pamela L. Dragosh PMTS Research One ATT Way 4D-170P Bedminster, NJ 07921 908-901-2120 - Office pdrag...@research.att.com On 1/5/15, 2:04 PM, Hal Lockhart hal.lockh...@oracle.com wrote: I added a comma and the word and to the Mentors section. The Mentors are: Emmanuel Lécharny, Colm O hEigeartaigh and Hadrian Zbarcea Do you see any other formatting errors? Hal -Original Message- From: Roman Shaposhnik [mailto:ro...@shaposhnik.org] Sent: Monday, January 05, 2015 1:24 PM To: general@incubator.apache.org Subject: Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator Hi! can you please fix the formatting issues? For example, I can't even tell the exact list of mentors you're proposing. Thanks, Roman. On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart hal.lockh...@oracle.com wrote: I call a vote to accept OpenAz as a new Incubator project. The proposal can be found here: https://wiki.apache.org/incubator/OpenAZProposal and is included below in this email. Voting will remain open until at least January 20, 2015 23:00 ET. Hal Lockhart - - - Abstract OpenAz is a project to create tools and libraries to enable the development of Attribute-based Access Control (ABAC) Systems in a variety of languages. In general the work is at least consistent with or actually conformant to the OASIS XACML Standard. Proposal Generally the work falls into two categories: ready to use tools which implement standardized or well understood components of an ABAC system and design proposals and proof of concept code relating to less well understood or experimental aspects of the problem. Much of the work to date has revolved around defining interfaces enabling a PEP to request an access control decision from a PDP. The XACML standard defines an abstract request format in xml and protocol wire formats in xaml and json, but it does not specify programmatic interfaces in any language. The standard says that the use of XML (or JSON) is not required only the semantic equivalent. The first Interface, AzAPI is modeled closely on the XACML defined interface, expressed in Java. One of the goals was to support calls to both a PDP local to the same process and a PDP in a remote server. AzAPI includes the interface, reference code to handle things like the many supported datatypes in XACML and glue code to mate it to the open source Sun XACML implementation. Because of the dependence on Sun XACML (which is XACML 2.0) the interface was missing some XACML 3.0 features. More recently this was corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was done by the JPMC team to support calling a remote PDP. WSo2 is also pursuing this capability. A second, higher level interface, PEPAPI was also defined. PEPAPI is more intended for application developers with little knowledge of XACML. It allows Java objects which contain attribute information to be passed in. Conversion methods, called mappers extract information from the objects and present it in the format expected by XACML. Some implementers have chosen to implement PEPAPI directly against their PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface which closely matches the Java one. Examples of more speculative work include: proposals for registration and dispatch of Obligation and Advice handlers, a scheme called AMF to tell PIPs how to retrieve attributes and PIP code to implement it, discussion of PoC code to demonstrate the use of XACML policies to drive OAuth interations and a proposal to use XACML policies to express OAuth scope. ATT has recently contributed their extensive XACML framework to the project. The ATT framework represents the entire XACML 3.0 object set as a collection of Java interfaces and standard implementations of those interfaces. The ATT PDP engine is built on top of this framework and represents a complete implementation of a XACML 3.0 PDP, including all of the multi-decision profiles. In addition, the framework also contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and XACML JSON Profile v1.0 WD 14. The PEP API includes annotation functionality, allowing application developers to simply annotate a Java class to provide attributes for a request. The annotation support removes the need for application developers to learn much of the API. The ATT framework also includes interfaces and implementations to standardize development of PIP engines that are used by the ATT PDP
Re: What is The Apache Way?
On Mon, Jan 12, 2015 at 12:55 PM, Doug Cutting cutt...@apache.org wrote: On Sun, Jan 11, 2015 at 9:49 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: I think a better analogy would be US Culture. Yes it is as nebulous as it gets, but the fact that US Constitution exists as a written document makes a LOT of things WAY easier. Apache's constitution is the corporate bylaws: http://www.apache.org/foundation/bylaws.html US Culture is stuff like Starbucks, Elvis, Manifest Destiny, etc. Most of that is not coded as law, thankfully. Except that there generally aren't authority figures to whom I am answerable to telling me I am doing it wrong if I don't drink Pumpkin Spice Latte's while listening to Blue Suede Shoes. Going back to a conversation from the middle of last year as an example, there is no documented expectation (unless you consider Shane's recently created page authoritative) that the canonical source code repository must live on ASF hardware. Which is fine, we all know the reason why, but when newcomers show up, they don't, and it seems like we are a mass of unwritten rules that MUST be followed. --David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator
+1 --- I call a vote to accept OpenAz as a new Incubator project. The proposal can be found here: https://wiki.apache.org/incubator/OpenAZProposal and is included below in this email. Voting will remain open until at least January 20, 2015 23:00 ET. Hal Lockhart --- Abstract OpenAz is a project to create tools and libraries to enable the development of Attribute-based Access Control (ABAC) Systems in a variety of languages. In general the work is at least consistent with or actually conformant to the OASIS XACML Standard. Proposal Generally the work falls into two categories: ready to use tools which implement standardized or well understood components of an ABAC system and design proposals and proof of concept code relating to less well understood or experimental aspects of the problem. Much of the work to date has revolved around defining interfaces enabling a PEP to request an access control decision from a PDP. The XACML standard defines an abstract request format in xml and protocol wire formats in xaml and json, but it does not specify programmatic interfaces in any language. The standard says that the use of XML (or JSON) is not required only the semantic equivalent. The first Interface, AzAPI is modeled closely on the XACML defined interface, expressed in Java. One of the goals was to support calls to both a PDP local to the same process and a PDP in a remote server. AzAPI includes the interface, reference code to handle things like the many supported datatypes in XACML and glue code to mate it to the open source Sun XACML implementation. Because of the dependence on Sun XACML (which is XACML 2.0) the interface was missing some XACML 3.0 features. More recently this was corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was done by the JPMC team to support calling a remote PDP. WSo2 is also pursuing this capability. A second, higher level interface, PEPAPI was also defined. PEPAPI is more intended for application developers with little knowledge of XACML. It allows Java objects which contain attribute information to be passed in. Conversion methods, called mappers extract information from the objects and present it in the format expected by XACML. Some implementers have chosen to implement PEPAPI directly against their PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface which closely matches the Java one. Examples of more speculative work include: proposals for registration and dispatch of Obligation and Advice handlers, a scheme called AMF to tell PIPs how to retrieve attributes and PIP code to implement it, discussion of PoC code to demonstrate the use of XACML policies to drive OAuth interations and a proposal to use XACML policies to express OAuth scope. ATT has recently contributed their extensive XACML framework to the project. The ATT framework represents the entire XACML 3.0 object set as a collection of Java interfaces and standard implementations of those interfaces. The ATT PDP engine is built on top of this framework and represents a complete implementation of a XACML 3.0 PDP, including all of the multi-decision profiles. In addition, the framework also contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and XACML JSON Profile v1.0 WD 14. The PEP API includes annotation functionality, allowing application developers to simply annotate a Java class to provide attributes for a request. The annotation support removes the need for application developers to learn much of the API. The ATT framework also includes interfaces and implementations to standardize development of PIP engines that are used by the ATT PDP implementation, and can be used by other implementations built on top of the ATT framework. The framework also includes interfaces and implementations for a PAP distributed cloud infrastructure of PDP nodes that includes support for policy distribution and pip configurations. This PAP infrastructure includes a web application administrative console that contains a XACML 3.0 policy editor, attribute dictionary support, and management of PDP RESTful node instances. In addition, there are tools available for policy simulation. Background Access Control is in some ways the most basic IT Security service. It consists of making a decision about whether a particular request should be allowed and enforcing that decision. Aside from schemes like permission bits and Access Control Lists (ACLs) the most common way access control is implemented is as code in a server or application which typically intertwines access control logic with business logic, User interface and other software. This makes it difficult to understand, modify, analyze or even locate the security policy. The primary challenge of Access Control is
Re: What is The Apache Way?
On Tue, Jan 13, 2015 at 10:43 AM, David Nalley da...@gnsa.us wrote: On Mon, Jan 12, 2015 at 12:55 PM, Doug Cutting cutt...@apache.org wrote: On Sun, Jan 11, 2015 at 9:49 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: I think a better analogy would be US Culture. Yes it is as nebulous as it gets, but the fact that US Constitution exists as a written document makes a LOT of things WAY easier. Apache's constitution is the corporate bylaws: http://www.apache.org/foundation/bylaws.html US Culture is stuff like Starbucks, Elvis, Manifest Destiny, etc. Most of that is not coded as law, thankfully. Except that there generally aren't authority figures to whom I am answerable to telling me I am doing it wrong if I don't drink Pumpkin Spice Latte's while listening to Blue Suede Shoes. Going back to a conversation from the middle of last year as an example, there is no documented expectation (unless you consider Shane's recently created page authoritative) that the canonical source code repository must live on ASF hardware. Which is fine, we all know the reason why, but when newcomers show up, they don't, and it seems like we are a mass of unwritten rules that MUST be followed. And the fact that it seems a blindly obvious implication of the general principles to the 'old original' people around here does not help. At the Incubator, we're trying to teach people these principles via practice. Expecting them to draw the implications naturally from the principles at the outset of this process is asking too much of them and of us. A concrete idea that I doubt I have the time to volunteer for: Write a description of a prototypical, middle-of-the-road, Apache project. For as many salient characteristics as possible, write up the explanation of why the particular thing is the way it is. Use a practical example of the 'way' in operation to teach principles, instead of expecting it to work the other way around. --David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: What is The Apache Way?
Well, David, I'm afraid you are the authoritative source on the policy you use as an example. If it's not documented and that's a problem then it's *your* problem. You could (given even more time to volunteer to the ASF, solve it however you like (e.g. Write the doc, ask the community to write it, ask for budget to have a contract write it, something else), but it's you and the infra team that own this. I hope you won't take this personally, its not meant that way. As a volunteer you do a fantastic job and we are all immensely grateful. However, you did feed me a perfect way to illustrate the point I've been trying to make when highlighting docs and saying patches welcome. Perhaps it is time we hired a contractor to draw up the one document of truth? I'm working on the 2015 budget now. Any volunteers to own this? Ownership is ensuring that the individual gets access to all the appropriate VPs and that those VPs are able to provide the necessary input. Sent from my Windows Phone From: David Nalleymailto:da...@gnsa.us Sent: 1/13/2015 7:45 AM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: What is The Apache Way? On Mon, Jan 12, 2015 at 12:55 PM, Doug Cutting cutt...@apache.org wrote: On Sun, Jan 11, 2015 at 9:49 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: I think a better analogy would be US Culture. Yes it is as nebulous as it gets, but the fact that US Constitution exists as a written document makes a LOT of things WAY easier. Apache's constitution is the corporate bylaws: http://www.apache.org/foundation/bylaws.html US Culture is stuff like Starbucks, Elvis, Manifest Destiny, etc. Most of that is not coded as law, thankfully. Except that there generally aren't authority figures to whom I am answerable to telling me I am doing it wrong if I don't drink Pumpkin Spice Latte's while listening to Blue Suede Shoes. Going back to a conversation from the middle of last year as an example, there is no documented expectation (unless you consider Shane's recently created page authoritative) that the canonical source code repository must live on ASF hardware. Which is fine, we all know the reason why, but when newcomers show up, they don't, and it seems like we are a mass of unwritten rules that MUST be followed. --David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: What is The Apache Way?
On Tue, Jan 13, 2015 at 5:23 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: ...Perhaps it is time we hired a contractor to draw up the one document of truth?... If we do that we'd better make it modular, so that one would be the truth *about infrastructure matters*. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator
+1 binding Regards, Alan On Jan 5, 2015, at 10:15 AM, Hal Lockhart hal.lockh...@oracle.com wrote: I call a vote to accept OpenAz as a new Incubator project. The proposal can be found here: https://wiki.apache.org/incubator/OpenAZProposal and is included below in this email. Voting will remain open until at least January 20, 2015 23:00 ET. Hal Lockhart --- Abstract OpenAz is a project to create tools and libraries to enable the development of Attribute-based Access Control (ABAC) Systems in a variety of languages. In general the work is at least consistent with or actually conformant to the OASIS XACML Standard. Proposal Generally the work falls into two categories: ready to use tools which implement standardized or well understood components of an ABAC system and design proposals and proof of concept code relating to less well understood or experimental aspects of the problem. Much of the work to date has revolved around defining interfaces enabling a PEP to request an access control decision from a PDP. The XACML standard defines an abstract request format in xml and protocol wire formats in xaml and json, but it does not specify programmatic interfaces in any language. The standard says that the use of XML (or JSON) is not required only the semantic equivalent. The first Interface, AzAPI is modeled closely on the XACML defined interface, expressed in Java. One of the goals was to support calls to both a PDP local to the same process and a PDP in a remote server. AzAPI includes the interface, reference code to handle things like the many supported datatypes in XACML and glue code to mate it to the open source Sun XACML implementation. Because of the dependence on Sun XACML (which is XACML 2.0) the interface was missing some XACML 3.0 features. More recently this was corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was done by the JPMC team to support calling a remote PDP. WSo2 is also pursuing this capability. A second, higher level interface, PEPAPI was also defined. PEPAPI is more intended for application developers with little knowledge of XACML. It allows Java objects which contain attribute information to be passed in. Conversion methods, called mappers extract information from the objects and present it in the format expected by XACML. Some implementers have chosen to implement PEPAPI directly against their PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface which closely matches the Java one. Examples of more speculative work include: proposals for registration and dispatch of Obligation and Advice handlers, a scheme called AMF to tell PIPs how to retrieve attributes and PIP code to implement it, discussion of PoC code to demonstrate the use of XACML policies to drive OAuth interations and a proposal to use XACML policies to express OAuth scope. ATT has recently contributed their extensive XACML framework to the project. The ATT framework represents the entire XACML 3.0 object set as a collection of Java interfaces and standard implementations of those interfaces. The ATT PDP engine is built on top of this framework and represents a complete implementation of a XACML 3.0 PDP, including all of the multi-decision profiles. In addition, the framework also contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and XACML JSON Profile v1.0 WD 14. The PEP API includes annotation functionality, allowing application developers to simply annotate a Java class to provide attributes for a request. The annotation support removes the need for application developers to learn much of the API. The ATT framework also includes interfaces and implementations to standardize development of PIP engines that are used by the ATT PDP implementation, and can be used by other implementations built on top of the ATT framework. The framework also includes interfaces and implementations for a PAP distributed cloud infrastructure of PDP nodes that includes support for policy distribution and pip configurations. This PAP infrastructure includes a web application administrative console that contains a XACML 3.0 policy editor, attribute dictionary support, and management of PDP RESTful node instances. In addition, there are tools available for policy simulation. Background Access Control is in some ways the most basic IT Security service. It consists of making a decision about whether a particular request should be allowed and enforcing that decision. Aside from schemes like permission bits and Access Control Lists (ACLs) the most common way access control is implemented is as code in a server or application which typically intertwines access control logic with business logic, User interface and other software. This makes it difficult to
Re: What is The Apache Way?
Will do :) On Jan 13, 2015, at 1:21 PM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Even better suggestion. Do you want to take it up with Sally directly? (and big thanks in advance) Sent from my Windows Phone From: Jim Jagielskimailto:j...@jagunet.com Sent: 1/13/2015 9:33 AM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: What is The Apache Way? If we go that route, I'll own it, since it makes sense as a VP Legal responsibility in a lot of ways. On Jan 13, 2015, at 12:29 PM, Jim Jagielski j...@jagunet.com wrote: Perhaps it is time we hired a contractor to draw up the one document of truth? My thoughts are that Sally certainly groks the Apache Way, and knows who to contact for more detailed info and clarification. Why not add this as a task to HALO, and put some $$$ towards it? - 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: [Proposal] TinkerPop: A Graph Computing Framework [RE-SUBMISSION]
On Tuesday, January 13, 2015, Rich Bowen rbo...@rcbowen.com wrote: On 01/10/2015 01:18 AM, Ted Dunning wrote: This still only has 3 committers... ...We do not, however, feel that it is a barrier to entering incubation - merely something to be addressed during incubation... I agree with that, and it looks like you have more than enough mentors to make this happen ;-) -Bertrand
Re: Clear expectations
On Sun, Jan 11, 2015 at 7:18 PM, Benson Margulies bimargul...@gmail.com wrote: Does it help anything to look at this, again, as failure modes? How about this failure mode? A podling receives thorough instruction on some policy during incubation. After graduation, that policy gets violated, but most PMC members don't speak up because the rules are messy and poorly documented and they don't have enough confidence in their understanding to pursue the matter. Is that failure mode even related to the Incubator? Though you could argue that the passive PMC members did not learn to escalate, the main lesson I take from it is that unclear requirments are a problem for TLPs and the larger organization. The Incubator is teaching from an inadequate spec. That's a problem for us in that it wastes the time of Mentors and podlings. But the spec's inadequacy does not originate with the Incubator. The Incubator doesn't own that problem. The question I'd ask is, How can Apache create an awesome spec that's easy to teach, easy to learn, and easy to follow? I think the answer starts with the very skepticism of top-down governance which has in large part kept us from having clear rules up till now. That skepticism must be applied aggressively at every step of the way to ensure that we require no more than the bare minimum. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: What is The Apache Way?
On Tue, Jan 13, 2015 at 9:37 AM, David Nalley da...@gnsa.us wrote: ross.gard...@microsoft.com wrote: Perhaps it is time we hired a contractor to draw up the one document of truth? I'm working on the 2015 budget now. Any volunteers to own this? Ownership is ensuring that the individual gets access to all the appropriate VPs and that those VPs are able to provide the necessary input. I think Marvin could manage this well (yes, this is me pushing you in front of the bus, Marvin. My apologies). I would pour my heart and soul into such a role. I would give everything I have to coordinate the delivery of minimalist authoritative documentation worthy of Apache's traditions. It would be a huge contribution to open source software, lightening the load for hundreds of projects and thousands of developers. For the record, I have doubts about structuring it as a contract position. This is an editing task, and what I have observed in the past is that VPs have sometimes created policy documents which the Board felt were too expansive. It seems odd to budget for a process of potentially open-ended negotiation. Simply assigning this task, connoting Board endorsement of the concept, is enough for me. Bertrand cares deeply about these issues and has been working on them for a long time (http://s.apache.org/JNH). Recently, he has been occupied with a maturity model initiative (http://s.apache.org/apache_maturity_model) close in spirit to Shane's work on project requirements . Drawing on resources like Bertrand and Shane, I am confident that we can hammer out a top-level requirements document which would be complete, authentic enough to satisfy Jim, yet spartan enough to satisfy skeptics like Doug. If the Board is willing to commission such a document, I will make it happen. And I would be delighted to work with our VPs at the Board's request to refine project requirement documentation for their separate areas. Please assign me this task. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: What is The Apache Way?
On Tuesday, January 13, 2015, Marvin Humphrey mar...@rectangular.com wrote: ...If the Board is willing to commission such a document, I will make it happen That would be fantastic, I think you'd do a great job in coordinating this effort. As you say I do care a lot about those things, but I often lack the continuous attention that's needed to finalize the set of document that we need. If you're willing to take on this coordination and leadership effort (on comdev I guess) you have my big +1. -Bertrand
RE: What is The Apache Way?
Marvin, it doesn't need assigning. Just step up and do it. There may not be full consensus on the value of this, but I think there are enough people saying it has value to mean that it has some value. Note the overlapping mails from Jim. I think it makes a huge amount of sense to have budget to deliver the words on a page (as opposed to doing the hard work of building consensus on what needs to be said by those words). That being said if you can deliver without budget to support the effort that's all the better. Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] Sent: Tuesday, January 13, 2015 12:59 PM To: general@incubator.apache.org Subject: Re: What is The Apache Way? On Tuesday, January 13, 2015, Marvin Humphrey mar...@rectangular.com wrote: ...If the Board is willing to commission such a document, I will make it happen That would be fantastic, I think you'd do a great job in coordinating this effort. As you say I do care a lot about those things, but I often lack the continuous attention that's needed to finalize the set of document that we need. If you're willing to take on this coordination and leadership effort (on comdev I guess) you have my big +1. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: What is The Apache Way?
On Tue, Jan 13, 2015 at 2:28 PM, Marvin Humphrey mar...@rectangular.com wrote: I would pour my heart and soul into such a role. I would give everything I have to coordinate the delivery of minimalist authoritative documentation worthy of Apache's traditions. It would be a huge contribution to open source software, lightening the load for hundreds of projects and thousands of developers. This point is absolutely huge. A well written minimalist policy could easily be forked by lots of non-Apache projects in much the way that the ASL itself is widely used. Improving the quality of Apache releases is great. Improving the quality of open source releases generally would be quite a bit greater.
RE: Clear expectations
Marvin, Can you please expand on I think the answer starts with the very skepticism of top-down governance which has in large part kept us from having clear rules up till now. I'm not clear on what the skepticism is that you refer to as these threads have indicated that there are at least two very different views on whether there is, or is not, top down governance in the ASF. Ross -Original Message- From: Marvin Humphrey [mailto:mar...@rectangular.com] Sent: Tuesday, January 13, 2015 1:27 PM To: general@incubator.apache.org; Shane Curcuru Subject: Re: Clear expectations On Sun, Jan 11, 2015 at 7:18 PM, Benson Margulies bimargul...@gmail.com wrote: Does it help anything to look at this, again, as failure modes? How about this failure mode? A podling receives thorough instruction on some policy during incubation. After graduation, that policy gets violated, but most PMC members don't speak up because the rules are messy and poorly documented and they don't have enough confidence in their understanding to pursue the matter. Is that failure mode even related to the Incubator? Though you could argue that the passive PMC members did not learn to escalate, the main lesson I take from it is that unclear requirments are a problem for TLPs and the larger organization. The Incubator is teaching from an inadequate spec. That's a problem for us in that it wastes the time of Mentors and podlings. But the spec's inadequacy does not originate with the Incubator. The Incubator doesn't own that problem. The question I'd ask is, How can Apache create an awesome spec that's easy to teach, easy to learn, and easy to follow? I think the answer starts with the very skepticism of top-down governance which has in large part kept us from having clear rules up till now. That skepticism must be applied aggressively at every step of the way to ensure that we require no more than the bare minimum. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Streams 0.1-incubating
Could you send the [CANCEL] thread to officially kill this VOTE? On Fri, Jan 9, 2015 at 1:52 AM, Ate Douma a...@douma.nu wrote: -1 (binding) Besides the findings already reported by Justin Mclean in addition I noticed: - binary artifacts, including the -sources and -javadoc jars, do not contain the required DISCLAIMER file alongside the NOTICE and LICENSE files I also encountered build test failures. For the next release candidate I strongly suggest to provide at least a basic getting started either online or with the source because for outsiders it is totally unclear how to use Streams or even what it does ... Regards, Ate For the IPMC: I'm a mentor on Streams but was on holiday when this vote ran on the streams-dev list. On 2014-12-21 23:06, Steve Blackmon wrote: This is the first incubator release for Apache Streams, with the artifacts being versioned as 0.1-incubating. We are requesting at least two additional IPMC member votes, as we have received 1 binding IPMC +1 vote during the release voting on streams-dev. VOTE: http://markmail.org/thread/kbgr73ndhztwybsh RESULT: http://markmail.org/thread/fz53tiiqnadwyagg IPMC member votes from the streams-dev list: Matthew Franklin: +1 Git tag streams-project-0.1-incubating-rc1 (commit 8e561d6) https://git-wip-us.apache.org/repos/asf?p=incubator-streams.git;a=commit;h=8e561d60bae3fb74baad05ed5a0d1be6631ceab1 Maven staging repo: https://repository.apache.org/content/repositories/orgapachestreams-1000 Source release: http://repository.apache.org/content/repositories/orgapachestreams-1000/org/apache/streams/streams-project/0.1-incubating/streams-project-0.1-incubating-source-release.zip Release artifacts are signed with the following key: https://people.apache.org/keys/committer/sblackmon.asc Vote open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Steve Blackmon sblack...@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
[CANCELLED] [VOTE] Release Apache Streams 0.1-incubating
We will address the issues identified by Justin and Ate and submit again. On Fri, Jan 9, 2015 at 3:52 AM, Ate Douma a...@douma.nu wrote: -1 (binding) Besides the findings already reported by Justin Mclean in addition I noticed: - binary artifacts, including the -sources and -javadoc jars, do not contain the required DISCLAIMER file alongside the NOTICE and LICENSE files I also encountered build test failures. For the next release candidate I strongly suggest to provide at least a basic getting started either online or with the source because for outsiders it is totally unclear how to use Streams or even what it does ... Regards, Ate For the IPMC: I'm a mentor on Streams but was on holiday when this vote ran on the streams-dev list. On 2014-12-21 23:06, Steve Blackmon wrote: This is the first incubator release for Apache Streams, with the artifacts being versioned as 0.1-incubating. We are requesting at least two additional IPMC member votes, as we have received 1 binding IPMC +1 vote during the release voting on streams-dev. VOTE: http://markmail.org/thread/kbgr73ndhztwybsh RESULT: http://markmail.org/thread/fz53tiiqnadwyagg IPMC member votes from the streams-dev list: Matthew Franklin: +1 Git tag streams-project-0.1-incubating-rc1 (commit 8e561d6) https://git-wip-us.apache.org/repos/asf?p=incubator-streams. git;a=commit;h=8e561d60bae3fb74baad05ed5a0d1be6631ceab1 Maven staging repo: https://repository.apache.org/content/repositories/orgapachestreams-1000 Source release: http://repository.apache.org/content/repositories/ orgapachestreams-1000/org/apache/streams/streams-project/0.1-incubating/ streams-project-0.1-incubating-source-release.zip Release artifacts are signed with the following key: https://people.apache.org/keys/committer/sblackmon.asc Vote open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Steve Blackmon sblack...@apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
