Re: [VOTE] Apache Tamaya for Incubation
+1 (binding) LieGrue, strub > On Tuesday, 11 November 2014, 12:20, John D. Ament > wrote: > > Anatole, > > Actually the name suitability is a long, drawn out process. i started it > here just now for the project: > https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-60 > You can read the details here: http://incubator.apache.org/guides/names.html > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT] [VOTE] Release Apache Calcite 0.9.2 (incubating)
This vote passes with 3 +1s and no 0 or -1 votes: +1 Steven Noels (mentor) +1 John D. Ament +1 Alan Gates (mentor) Thanks everyone. We’ll now roll the release out to the mirrors. Julian - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Release Apache Ranger 0.4.0 (incubating) - (formally known as Apache Argus)
The Apache Ranger community has voted on and approved a proposal to release Apache Ranger 0.4.0 (incubating). This will be our first release since the project entered incubation in July 2014 as Apache Argus and then, got it renamed as Apache Ranger. The ranger-0.4.0-rc3 release candidate is now available with the following artifacts up for a project vote : Git tag for the release: https://git-wip-us.apache.org/repos/asf?p=incubator-argus.git;a=shortlog;h=refs/tags/ranger-0.4.0-rc3 Source release: http://people.apache.org/~sneethir/ranger/ranger-0.4.0-rc3/ranger-0.4.0-rc3.tar.gz Source release verification: PGP Signature: http://people.apache.org/~sneethir/ranger/ranger-0.4.0-rc3/ranger-0.4.0-rc3.tar.gz.asc MD5/SHA Hash: http://people.apache.org/~sneethir/ranger/ranger-0.4.0-rc3/ranger-0.4.0-rc3.tar.gz.mds Keys to verify the signature of the release artifact are available at: https://people.apache.org/keys/group/argus.asc Build verification steps can be found at: http://argus.incubator.apache.org/quick_start_guide.html The vote will be open for at least 72 hours or until necessary number of votes are reached. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Here is my +1 (non binding) Thanks Selva- signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [VOTE] Apache Tamaya for Incubation
+1 regards, gerhard 2014-11-13 9:16 GMT+01:00 Mark Struberg : > +1 (binding) > > LieGrue, > strub > > > > > > On Tuesday, 11 November 2014, 12:20, John D. Ament < > john.d.am...@gmail.com> wrote: > > > Anatole, > > > > Actually the name suitability is a long, drawn out process. i started it > > here just now for the project: > > https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-60 > > You can read the details here: > http://incubator.apache.org/guides/names.html > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE][IP CLEARANCE] Sling Sightly and XSS modules
Hi, On Wed, Nov 12, 2014 at 11:36 PM, jan i wrote: > ...I am a bit concerned about the notation "Check and make sure that the files > that have been donated have been updated to reflect the new ASF copyright: > will be done once the donation is incorporated in the Sling codebase, > before releasing the software" not being completed... Turns out I was a bit too cautious on that one, I just checked the http://incubator.apache.org/ip-clearance/sling-sightly-xss.html code again and it looks good, source code files do have the Apache copyright/license headers. OTOH I think it's better to handle this right after committing the code to our code repositories, as we can better trace changes. Maybe import in a "quarantine" folder initially - I'll start another thread about this. > ...+1 (binding), IF the donation reflect the ASF copyright, see above... Thanks, that is the case indeed. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
IP clearance clarification: copyright notices
Hi, In the vote thread about [1] a question came up about the following clause, from our IP clearance form: > Check and make sure that the files that have been donated have been > updated to reflect the new ASF copyright. I think this actually covers two distinct things: 1) Moving any existing non-Apache copyright notices to a NOTICE file, if the owner of the donated code wants that, or otherwise removing them or making them smaller to avoid bloating the code with multiple copyright notices., if possible. All done by whoever donates the code - as per the "Should a project move non-ASF copyright notices from Apache source files to the NOTICE file?" section in [2], we don't want to that ourselves. 2) Adding Apache copyright/license headers where required IMO there's no need for 2) to happen before the donation, that just has to happen before the first release of that code. Do people agree? Shall we reformulate that requirement to better express that it's only 1) that's relevant before accepting the donated code? -Bertrand [1] http://incubator.apache.org/ip-clearance/sling-sightly-xss.html [2] http://www.apache.org/legal/src-headers.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP clearance clarification: copyright notices
On 13 November 2014 11:18, Bertrand Delacretaz wrote: > Hi, > > In the vote thread about [1] a question came up about the following > clause, from our IP clearance form: > > > Check and make sure that the files that have been donated have been > > updated to reflect the new ASF copyright. > > I think this actually covers two distinct things: > > 1) Moving any existing non-Apache copyright notices to a NOTICE file, > if the owner of the donated code wants that, or otherwise removing > them or making them smaller to avoid bloating the code with multiple > copyright notices., if possible. All done by whoever donates the code > - as per the "Should a project move non-ASF copyright notices from > Apache source files to the NOTICE file?" section in [2], we don't want > to that ourselves. > > 2) Adding Apache copyright/license headers where required > > IMO there's no need for 2) to happen before the donation, that just > has to happen before the first release of that code. > I dont agree with that statement. I would very much prefer: "that just has to happen as the first change (commit) to the files, and no later than the first release". In my opinion its important that all changes to the code happens after the license header is in place. > > Do people agree? Shall we reformulate that requirement to better > express that it's only 1) that's relevant before accepting the donated > code? > agreed, with my little change. rgds jan I. Ps. I like your idea of putting the original code in a quarantine area of svn/git. > > -Bertrand > > [1] http://incubator.apache.org/ip-clearance/sling-sightly-xss.html > [2] http://www.apache.org/legal/src-headers.html > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Apache Tamaya for Incubation
+1 On Thu, Nov 13, 2014 at 9:56 AM, Gerhard Petracek wrote: > +1 > > regards, > gerhard > > > > 2014-11-13 9:16 GMT+01:00 Mark Struberg : > > > +1 (binding) > > > > LieGrue, > > strub > > > > > > > > > > > On Tuesday, 11 November 2014, 12:20, John D. Ament < > > john.d.am...@gmail.com> wrote: > > > > Anatole, > > > > > > Actually the name suitability is a long, drawn out process. i started > it > > > here just now for the project: > > > https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-60 > > > You can read the details here: > > http://incubator.apache.org/guides/names.html > > > > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > >
Re: [VOTE] Apache Tamaya for Incubation
[ X ] +1 accept Tamaya in the Incubator [ ] ±0 [ ] -1 because... Cheers Daniel S. Haischt On Thu, Nov 13, 2014 at 3:49 PM, David Blevins wrote: > +1 > > On Thu, Nov 13, 2014 at 9:56 AM, Gerhard Petracek > wrote: > > > +1 > > > > regards, > > gerhard > > > > > > > > 2014-11-13 9:16 GMT+01:00 Mark Struberg : > > > > > +1 (binding) > > > > > > LieGrue, > > > strub > > > > > > > > > > > > > > > > On Tuesday, 11 November 2014, 12:20, John D. Ament < > > > john.d.am...@gmail.com> wrote: > > > > > Anatole, > > > > > > > > Actually the name suitability is a long, drawn out process. i > started > > it > > > > here just now for the project: > > > > https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-60 > > > > You can read the details here: > > > http://incubator.apache.org/guides/names.html > > > > > > > > > > - > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > >
Re: [VOTE] Release Apache Parquet Format (incubating) 2.2.0 RC2
On 11/12/2014 07:06 PM, John D. Ament wrote: The use of tags has come up several times on the incubator list in the past. They're not immutable, linking to a tag can be over-written. Please link to the appropriate commit, which in your case is likely https://git-wip-us.apache.org/repos/asf?p=incubator-parquet-format.git;a=commit;h=6979a6d60a319de6aab0b7743ef5b6a50a2f974e - John Thanks for finding the correct reference, John. You're right that the commit is 6979a6d60a319de6aab0b7743ef5b6a50a2f974e, which can be viewed at this URL: https://git-wip-us.apache.org/repos/asf?p=incubator-parquet-format.git;a=commit;h=6979a6d60a319de6aab0b7743ef5b6a50a2f974e This commit corresponds to the contents of the release candidate source tarball, which you can find here (along with checksums and signature): https://dist.apache.org/repos/dist/dev/incubator/parquet/2.2.0-rc2/ For future vote threads, I'll make sure we provide the right commit rather than a tag or branch reference. Thanks! rb On Mon, Nov 10, 2014 at 5:35 PM, Ryan Blue wrote: Hi everyone, I'd like to propose a vote to release parquet-format-2.2.0-rc2 as the official Parquet Format 2.2.0 release. This release candidate has passed a podling vote, which can be found here: https://mail-archives.apache.org/mod_mbox/incubator- parquet-dev/201411.mbox/%3C54613B48.6060602%40apache.org%3E The release candidate, signature, and checksums are available at: https://dist.apache.org/repos/dist/dev/incubator/parquet/2.2.0-rc2/ The branch used to create the release candidate is: https://git-wip-us.apache.org/repos/asf?p=incubator-parquet- format.git;hb=release-2.2.0-rc2 KEYS to validate the signature are available at: https://dist.apache.org/repos/dist/dev/incubator/parquet/KEYS Please download, verify, and test. [ ] +1: Release this tag as parquet-format-2.2.0 [ ] +0: [ ] -1: This release is not ready because . . . == More details == This will be the first release from the Parquet project. We are releasing parquet-format first because the other projects (parquet-mr and parquet-cpp) depend on it. This release uses the pre-Apache maven coordinate com.twitter:parquet-format and parquet.* package names. To make the transition to org.apache naming as smooth as possible for downstream projects, we are planning to release a com.twitter artifact immediately followed by an org.apache artifact. These artifacts will be identical except for naming changes: * com.twitter:parquet-format => org.apache.parquet:parquet-format * package parquet.* => package org.apache.parquet.* There are three major changes included in this release: * PARQUET-119: Add encoding stats to ColumnMetaData * PARQUET-79: Streaming thrift API * PARQUET-12: New logical types rb -- Ryan Blue - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Ryan Blue Software Engineer Cloudera, Inc. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP clearance clarification: copyright notices
On 11/13/14, 2:18 AM, "Bertrand Delacretaz" wrote: >Hi, > >In the vote thread about [1] a question came up about the following >clause, from our IP clearance form: > >> Check and make sure that the files that have been donated have been >> updated to reflect the new ASF copyright. > >I think this actually covers two distinct things: > >1) Moving any existing non-Apache copyright notices to a NOTICE file, >if the owner of the donated code wants that, or otherwise removing >them or making them smaller to avoid bloating the code with multiple >copyright notices., if possible. All done by whoever donates the code >- as per the "Should a project move non-ASF copyright notices from >Apache source files to the NOTICE file?" section in [2], we don't want >to that ourselves. > >2) Adding Apache copyright/license headers where required > >IMO there's no need for 2) to happen before the donation, that just >has to happen before the first release of that code. > >Do people agree? Shall we reformulate that requirement to better >express that it's only 1) that's relevant before accepting the donated >code? Hi Bertrand, The way I’ve interpreted this is that the “donation” occurs when the donor submits the software grant and secretary records it. All the donor is saying by submitting the grant is “I’m ok with you having this list of things” and makes no guarantees that the list of things are acceptable to Apache. A friend can give me a gift of a food basket without realizing I’m allergic to one of the things in there. The IP clearance process is where the receiving project makes the list of things acceptable to Apache. It can toss out things that Apache is allergic to and do other preparations before it lands in an Apache repo. Maybe it can wait until first release or first commit, but IMO, I’ve been trying to make the headers right before it hits the repo by running RAT before committing. Copyright law, AIUI, prevents the receiving project from moving copyrights without the copyright owner’s permission. Thus, if the donor has time to insert Apache headers and move copyrights to NOTICE, that is very helpful, but if the donor is short on time, he can give someone in the receiving project permission to do so. So, IMO, there is no need for any copyright mucking before the donation is accepted, as long as there are people with the time and permission to muck with it after, but it sure helps. Flex did take a donation where I fixed up the headers for the donor because the donor was short on time and didn’t want to create another place to store a branch of the code with modified headers. The donor’s code was already on GitHub and it felt strange to have him change his headers in the public GitHub copy or one of its branches. So I got explicit written (email) permission and fixed up the headers myself before submitting the package for IP clearance. That’s my understanding based on what I think I learned from you and the Adobe legal folks. -Alex
[PROPOSAL] OpenAZ as new Incubator project
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 semantics 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. AT&T has recently contributed their extensive XACML framework to the project. The AT&T framework represents the entire XACML 3.0 object set as a collection of Java interfaces and standard implementations of those interfaces. The AT&T 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 AT&T framework also includes interfaces and implementations to standardize development of PIP engines that are used by the AT&T PDP implementation, and can be used by other implementations built on top of the AT&T 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 striking the right balance between powerful expression and intelligibility to human beings. The OASIS XACML Standard exemplifies Attribute-Based Access Control (ABAC). In ABAC, the Policy Decision Point (PDP) is isolated from other components. The Policy Enforcement Point (PEP) must be located so as to be able to enforce the decision, typically near the resource. The PEP first asks the PDP if access should be allowed and pr
Re: [PROPOSAL] OpenAZ as new Incubator project
Could you add more description on what is PEP and PDP and other acronyms used in the proposal? If it is not directly relevant maybe you can rephrase it to more generic analogy. Thanks, Henry On Thu, Nov 13, 2014 at 1:14 PM, Hal Lockhart wrote: > 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 > semantics 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. > > AT&T has recently contributed their extensive XACML framework to the project. > > The AT&T framework represents the entire XACML 3.0 object set as a collection > of Java interfaces and standard implementations of those interfaces. The > AT&T 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 AT&T framework also includes interfaces and implementations to > standardize development of PIP engines that are used by the AT&T PDP > implementation, and can be used by other implementations built on top of the > AT&T 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 striking the > right balance between p
Re: [PROPOSAL] OpenAZ as new Incubator project
It'e really unlikely I will be able to contribute in any way to this any time soon, but I think it would be awesome if this was at apache. When I tried to investigate xacml a few years ago the major stumbling block I found was not being able to look at any reasonable implementation. (I remember something about the sun implementation but for some reason it was not in a form I could learn anything from). thanks david jencks On Nov 13, 2014, at 1:14 PM, Hal Lockhart wrote: > 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 > semantics 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. > > AT&T has recently contributed their extensive XACML framework to the project. > > The AT&T framework represents the entire XACML 3.0 object set as a collection > of Java interfaces and standard implementations of those interfaces. The > AT&T 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 AT&T framework also includes interfaces and implementations to > standardize development of PIP engines that are used by the AT&T PDP > implementation, and can be used by other implementations built on top of the > AT&T 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 >
Re: [PROPOSAL] OpenAZ as new Incubator project
Hal, Per customs, would you mind if we cancel this and start with a [DISCUSS] thread about OpenAZ? It's unclear if you meant this to be a vote or something. John On Thu, Nov 13, 2014 at 4:14 PM, Hal Lockhart wrote: > 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 > semantics 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. > > AT&T has recently contributed their extensive XACML framework to the > project. > > The AT&T framework represents the entire XACML 3.0 object set as a > collection of Java interfaces and standard implementations of those > interfaces. The AT&T 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 AT&T framework also includes interfaces and implementations to > standardize development of PIP engines that are used by the AT&T PDP > implementation, and can be used by other implementations built on top of > the AT&T 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 > striking the right balance between powerful expression and intelligibility > to human beings. > > The OASIS XA
Re: IP clearance clarification: copyright notices
I think it's good to be flexible here depending on the project's needs. A fresh project might need more help that is easiest to achieve after transitioning the code to Apache. Some of the terminology of the incubator assumes the incubator project is showing up on the Apache doorstep with a USB key full of source-code that have never before been on the Internet - this might need some updating to also cater for the modern reality of distributed and ad-hoc collaboration on open source using tools like git/mercurial, Github and Bitbucket. Being picky about "the first commit after incubation" seems a bit daft - after all a source code import should include the full history, and that historical source-code would most likely not have the "right" copyright/license headers. The hard deadline must be for the first release, though. For our incubator project (Taverna), we saw the need to reorganize our current git repositories (which were a bit too numerous) as part of the incubation process. We therefore have made a separate staging area on Github, and then basically we will move from github.com/taverna/* to github.com/taverna-incubator/* step by step. Another reason why we have to do this is that requesting additional git repositores at git.apache.org is a bit more heavyweight compared to [New repository] button on Github - so we must get the repository names etc. right to start with. But this also allows us to sort out bureaucratic things without affecting the existing repositories, which are still in daily use (in preparing a "last non-Apache-release"). It is therefore not any problem to change licenses, groupIds and copyrights within that staging repository. But that staging-incubation model would probably be too heavy for the hobby projects that are growing up and just have a single repository, or for large commercial projects which don't want to publish as open-source until it is under Apache. On 13 November 2014 18:32, Alex Harui wrote: > > > On 11/13/14, 2:18 AM, "Bertrand Delacretaz" wrote: > >>Hi, >> >>In the vote thread about [1] a question came up about the following >>clause, from our IP clearance form: >> >>> Check and make sure that the files that have been donated have been >>> updated to reflect the new ASF copyright. >> >>I think this actually covers two distinct things: >> >>1) Moving any existing non-Apache copyright notices to a NOTICE file, >>if the owner of the donated code wants that, or otherwise removing >>them or making them smaller to avoid bloating the code with multiple >>copyright notices., if possible. All done by whoever donates the code >>- as per the "Should a project move non-ASF copyright notices from >>Apache source files to the NOTICE file?" section in [2], we don't want >>to that ourselves. >> >>2) Adding Apache copyright/license headers where required >> >>IMO there's no need for 2) to happen before the donation, that just >>has to happen before the first release of that code. >> >>Do people agree? Shall we reformulate that requirement to better >>express that it's only 1) that's relevant before accepting the donated >>code? > > Hi Bertrand, > > The way I’ve interpreted this is that the “donation” occurs when the donor > submits the software grant and secretary records it. All the donor is > saying by submitting the grant is “I’m ok with you having this list of > things” and makes no guarantees that the list of things are acceptable to > Apache. A friend can give me a gift of a food basket without realizing > I’m allergic to one of the things in there. > > The IP clearance process is where the receiving project makes the list of > things acceptable to Apache. It can toss out things that Apache is > allergic to and do other preparations before it lands in an Apache repo. > Maybe it can wait until first release or first commit, but IMO, I’ve been > trying to make the headers right before it hits the repo by running RAT > before committing. > > Copyright law, AIUI, prevents the receiving project from moving copyrights > without the copyright owner’s permission. Thus, if the donor has time to > insert Apache headers and move copyrights to NOTICE, that is very helpful, > but if the donor is short on time, he can give someone in the receiving > project permission to do so. > > So, IMO, there is no need for any copyright mucking before the donation is > accepted, as long as there are people with the time and permission to muck > with it after, but it sure helps. Flex did take a donation where I fixed > up the headers for the donor because the donor was short on time and > didn’t want to create another place to store a branch of the code with > modified headers. The donor’s code was already on GitHub and it felt > strange to have him change his headers in the public GitHub copy or one of > its branches. So I got explicit written (email) permission and fixed up > the headers myself before submitting the package for IP clearance. > > That’s my understanding based on
Re: [VOTE] Release Apache Parquet Format (incubating) 2.2.0 RC2
+1 We need votes from the incubator PMC, right? Julien On Thu, Nov 13, 2014 at 8:51 AM, Ryan Blue wrote: > On 11/12/2014 07:06 PM, John D. Ament wrote: > >> The use of tags has come up several times on the incubator list in the >> past. They're not immutable, linking to a tag can be over-written. >> Please >> link to the appropriate commit, which in your case is likely >> >> https://git-wip-us.apache.org/repos/asf?p=incubator-parquet- >> format.git;a=commit;h=6979a6d60a319de6aab0b7743ef5b6a50a2f974e >> >> - John >> > > Thanks for finding the correct reference, John. You're right that the > commit is 6979a6d60a319de6aab0b7743ef5b6a50a2f974e, which can be viewed > at this URL: > > > https://git-wip-us.apache.org/repos/asf?p=incubator-parquet- > format.git;a=commit;h=6979a6d60a319de6aab0b7743ef5b6a50a2f974e > > This commit corresponds to the contents of the release candidate source > tarball, which you can find here (along with checksums and signature): > > https://dist.apache.org/repos/dist/dev/incubator/parquet/2.2.0-rc2/ > > For future vote threads, I'll make sure we provide the right commit rather > than a tag or branch reference. Thanks! > > rb > > > On Mon, Nov 10, 2014 at 5:35 PM, Ryan Blue wrote: >> >> Hi everyone, >>> >>> I'd like to propose a vote to release parquet-format-2.2.0-rc2 as the >>> official Parquet Format 2.2.0 release. >>> >>> This release candidate has passed a podling vote, which can be found >>> here: >>> >>> https://mail-archives.apache.org/mod_mbox/incubator- >>> parquet-dev/201411.mbox/%3C54613B48.6060602%40apache.org%3E >>> >>> The release candidate, signature, and checksums are available at: >>>https://dist.apache.org/repos/dist/dev/incubator/parquet/2.2.0-rc2/ >>> >>> The branch used to create the release candidate is: >>> >>> https://git-wip-us.apache.org/repos/asf?p=incubator-parquet- >>> format.git;hb=release-2.2.0-rc2 >>> >>> KEYS to validate the signature are available at: >>>https://dist.apache.org/repos/dist/dev/incubator/parquet/KEYS >>> >>> Please download, verify, and test. >>> >>> [ ] +1: Release this tag as parquet-format-2.2.0 >>> [ ] +0: >>> [ ] -1: This release is not ready because . . . >>> >>> >>> == More details == >>> >>> This will be the first release from the Parquet project. We are releasing >>> parquet-format first because the other projects (parquet-mr and >>> parquet-cpp) depend on it. >>> >>> This release uses the pre-Apache maven coordinate >>> com.twitter:parquet-format and parquet.* package names. To make the >>> transition to org.apache naming as smooth as possible for downstream >>> projects, we are planning to release a com.twitter artifact immediately >>> followed by an org.apache artifact. These artifacts will be identical >>> except for naming changes: >>> >>> * com.twitter:parquet-format => org.apache.parquet:parquet-format >>> * package parquet.* => package org.apache.parquet.* >>> >>> There are three major changes included in this release: >>> * PARQUET-119: Add encoding stats to ColumnMetaData >>> * PARQUET-79: Streaming thrift API >>> * PARQUET-12: New logical types >>> >>> >>> rb >>> >>> >>> -- >>> Ryan Blue >>> >>> - >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >>> >>> >> > > -- > Ryan Blue > Software Engineer > Cloudera, Inc. > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
RE: [PROPOSAL] OpenAZ as new Incubator project
No, I am sorry this process is all new to me. I also created a page in the wiki with same content. (OpenAZProposal) Do I need to do something or can you cancel it? Hal > -Original Message- > From: John D. Ament [mailto:john.d.am...@gmail.com] > Sent: Thursday, November 13, 2014 5:03 PM > To: general@incubator.apache.org > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project > > Hal, > > Per customs, would you mind if we cancel this and start with a > [DISCUSS] thread about OpenAZ? It's unclear if you meant this to be a > vote or something. > > John > > On Thu, Nov 13, 2014 at 4:14 PM, Hal Lockhart > wrote: > > > 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 semantics 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. > > > > AT&T has recently contributed their extensive XACML framework to the > > project. > > > > The AT&T framework represents the entire XACML 3.0 object set as a > > collection of Java interfaces and standard implementations of those > > interfaces. The AT&T 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 AT&T framework also includes interfaces and implementations to > > standardize development of PIP engines that are used by the AT&T PDP > > implementation, and can be used by other implementations built on top > > of the AT&T 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 decisio
RE: [PROPOSAL] OpenAZ as new Incubator project
Did you see the background section? I meant that to provide that information. I was unclear on how much to assume the audience already knows about the subject. Hal > -Original Message- > From: Henry Saputra [mailto:henry.sapu...@gmail.com] > Sent: Thursday, November 13, 2014 4:31 PM > To: general@incubator.apache.org > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project > > Could you add more description on what is PEP and PDP and other > acronyms used in the proposal? If it is not directly relevant maybe you > can rephrase it to more generic analogy. > > Thanks, > > Henry > > On Thu, Nov 13, 2014 at 1:14 PM, Hal Lockhart > wrote: > > 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 semantics 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. > > > > AT&T has recently contributed their extensive XACML framework to the > project. > > > > The AT&T framework represents the entire XACML 3.0 object set as a > collection of Java interfaces and standard implementations of those > interfaces. The AT&T 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 AT&T framework also includes interfaces and implementations to > standardize development of PIP engines that are used by the AT&T PDP > implementation, and can be used by other implementations built on top > of the AT&T 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
Re: [VOTE] Release Apache Parquet Format (incubating) 2.2.0 RC2
On 11/13/2014 02:21 PM, Julien Le Dem wrote: +1 We need votes from the incubator PMC, right? Julien That's right, this vote requires at least 3 +1s from IPMC members to pass. I know that some of our mentors are out of town, so it would be helpful if anyone has time to take a look at the RC. This is our first release vote for the Parquet project, so I'm hoping to get good feedback. rb On Thu, Nov 13, 2014 at 8:51 AM, Ryan Blue wrote: On Mon, Nov 10, 2014 at 5:35 PM, Ryan Blue wrote: Hi everyone, I'd like to propose a vote to release parquet-format-2.2.0-rc2 as the official Parquet Format 2.2.0 release. This release candidate has passed a podling vote, which can be found here: https://mail-archives.apache.org/mod_mbox/incubator- parquet-dev/201411.mbox/%3C54613B48.6060602%40apache.org%3E The release candidate, signature, and checksums are available at: https://dist.apache.org/repos/dist/dev/incubator/parquet/2.2.0-rc2/ The branch used to create the release candidate is: https://git-wip-us.apache.org/repos/asf?p=incubator-parquet- format.git;hb=release-2.2.0-rc2 KEYS to validate the signature are available at: https://dist.apache.org/repos/dist/dev/incubator/parquet/KEYS Please download, verify, and test. [ ] +1: Release this tag as parquet-format-2.2.0 [ ] +0: [ ] -1: This release is not ready because . . . == More details == This will be the first release from the Parquet project. We are releasing parquet-format first because the other projects (parquet-mr and parquet-cpp) depend on it. This release uses the pre-Apache maven coordinate com.twitter:parquet-format and parquet.* package names. To make the transition to org.apache naming as smooth as possible for downstream projects, we are planning to release a com.twitter artifact immediately followed by an org.apache artifact. These artifacts will be identical except for naming changes: * com.twitter:parquet-format => org.apache.parquet:parquet-format * package parquet.* => package org.apache.parquet.* There are three major changes included in this release: * PARQUET-119: Add encoding stats to ColumnMetaData * PARQUET-79: Streaming thrift API * PARQUET-12: New logical types rb -- Ryan Blue - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Ryan Blue Software Engineer Cloudera, Inc. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Ryan Blue Software Engineer Cloudera, Inc. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenAZ as new Incubator project
Ah my bad, I usually use abstract section to get main idea of the proposal. And as per John request, lets start with DISCUSS thread instead. - Henry On Thu, Nov 13, 2014 at 2:59 PM, Hal Lockhart wrote: > Did you see the background section? I meant that to provide that information. > I was unclear on how much to assume the audience already knows about the > subject. > > Hal > >> -Original Message- >> From: Henry Saputra [mailto:henry.sapu...@gmail.com] >> Sent: Thursday, November 13, 2014 4:31 PM >> To: general@incubator.apache.org >> Subject: Re: [PROPOSAL] OpenAZ as new Incubator project >> >> Could you add more description on what is PEP and PDP and other >> acronyms used in the proposal? If it is not directly relevant maybe you >> can rephrase it to more generic analogy. >> >> Thanks, >> >> Henry >> >> On Thu, Nov 13, 2014 at 1:14 PM, Hal Lockhart >> wrote: >> > 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 semantics 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. >> > >> > AT&T has recently contributed their extensive XACML framework to the >> project. >> > >> > The AT&T framework represents the entire XACML 3.0 object set as a >> collection of Java interfaces and standard implementations of those >> interfaces. The AT&T 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 AT&T framework also includes interfaces and implementations to >> standardize development of PIP engines that are used by the AT&T PDP >> implementation, and can be used by other implementations built on top >> of the AT&T 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
Re: [VOTE] Retire HDT
CC¹ing folks from general@incubator.a.o as they can likely explain (am currently getting ready for a flight back from Italy to Los Angeles and won¹t have time for a bit, Bob). ++ 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 ++ -Original Message- From: Bob Kerns Reply-To: "d...@hdt.incubator.apache.org" Date: Thursday, November 13, 2014 at 6:58 PM To: "d...@hdt.incubator.apache.org" Subject: Re: [VOTE] Retire HDT >As someone who has unfortunately been inactive, I'm going to abstain +0; >otherwise I'd vote -1 and try to be one of those 3 active folks. > >I still have hopes of doing more stuff with Hadoop and HDT in the future, >but job responsibilities keep shifting in unexpected directions, and >health >and family don't leave me enough time to do it if not actively involved at >work. > >If retired, will this list remain active? Otherwise, it might be hard to >gather the 3 active people... > >I think there's significant needs that are going unmet that we could be >addressing, if people (myself included) had the time to devote to it. > >I've not stopped monitoring the list, and I do hope to contribute in the >future. If it is retired, what will be the mechanics for contributing new >code? Would it have to be brought out of retirement before that could >happen via Apache? (Obviously, a fork on GitHub would be an option, but >that might detract from a path back to active Apache involvement). > > >On Wed, Nov 12, 2014 at 7:45 AM, Roman Shaposhnik wrote: > >> On Mon, Nov 10, 2014 at 12:45 AM, Rahul Sharma >>wrote: >> > Hi all, >> > >> > Based on the discussion happened on the mailing list [1] ,I'd like to >> call >> > a VOTE to retire[2] Apache HDT from Apache Incubator. It appears i >>that >> > the project has lost community interest with almost no activity on >> mailing >> > lists. >> > >> > This VOTE will be open for at least 72 hours and passes on achieving a >> > consensus. >> > >> > +1 [ ] Yes, I am in favor of retiring HDT from the Apache Incubator. >> > +0 [ ] >> > -1 [ ] No, I am not in favor of retiring HDT because... >> >> + 1 (binding). >> >> Thanks for all your efforts Rahul! >> >> I've also appreciated Mirko's comment, but I must say that >> retirement is NOT a death sentence. The code still will be >> available and if least 3 active folks were to show up the >> project can easily be reinstated. >> >> Thanks, >> Roman. >> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Parquet Format (incubating) 2.2.0 RC2
+1 (binding) Checked signature, md5 and that files were properly licensed. LGTM. St.Ack On Mon, Nov 10, 2014 at 2:35 PM, Ryan Blue wrote: > Hi everyone, > > I'd like to propose a vote to release parquet-format-2.2.0-rc2 as the > official Parquet Format 2.2.0 release. > > This release candidate has passed a podling vote, which can be found here: > > https://mail-archives.apache.org/mod_mbox/incubator- > parquet-dev/201411.mbox/%3C54613B48.6060602%40apache.org%3E > > The release candidate, signature, and checksums are available at: > https://dist.apache.org/repos/dist/dev/incubator/parquet/2.2.0-rc2/ > > The branch used to create the release candidate is: > > https://git-wip-us.apache.org/repos/asf?p=incubator-parquet- > format.git;hb=release-2.2.0-rc2 > > KEYS to validate the signature are available at: > https://dist.apache.org/repos/dist/dev/incubator/parquet/KEYS > > Please download, verify, and test. > > [ ] +1: Release this tag as parquet-format-2.2.0 > [ ] +0: > [ ] -1: This release is not ready because . . . > > > == More details == > > This will be the first release from the Parquet project. We are releasing > parquet-format first because the other projects (parquet-mr and > parquet-cpp) depend on it. > > This release uses the pre-Apache maven coordinate > com.twitter:parquet-format and parquet.* package names. To make the > transition to org.apache naming as smooth as possible for downstream > projects, we are planning to release a com.twitter artifact immediately > followed by an org.apache artifact. These artifacts will be identical > except for naming changes: > > * com.twitter:parquet-format => org.apache.parquet:parquet-format > * package parquet.* => package org.apache.parquet.* > > There are three major changes included in this release: > * PARQUET-119: Add encoding stats to ColumnMetaData > * PARQUET-79: Streaming thrift API > * PARQUET-12: New logical types > > > rb > > > -- > Ryan Blue > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Release Apache Parquet Format (incubating) 2.2.0 RC2
+1 sig/xsum are valid. RAT ran clean and the checklist looks fine to me (license/notice/disclaimer/etc... are all good, etc...) Patrick On Mon, Nov 10, 2014 at 2:35 PM, Ryan Blue wrote: > Hi everyone, > > I'd like to propose a vote to release parquet-format-2.2.0-rc2 as the > official Parquet Format 2.2.0 release. > > This release candidate has passed a podling vote, which can be found here: > > https://mail-archives.apache.org/mod_mbox/incubator-parquet-dev/201411.mbox/%3C54613B48.6060602%40apache.org%3E > > The release candidate, signature, and checksums are available at: > https://dist.apache.org/repos/dist/dev/incubator/parquet/2.2.0-rc2/ > > The branch used to create the release candidate is: > > https://git-wip-us.apache.org/repos/asf?p=incubator-parquet-format.git;hb=release-2.2.0-rc2 > > KEYS to validate the signature are available at: > https://dist.apache.org/repos/dist/dev/incubator/parquet/KEYS > > Please download, verify, and test. > > [ ] +1: Release this tag as parquet-format-2.2.0 > [ ] +0: > [ ] -1: This release is not ready because . . . > > > == More details == > > This will be the first release from the Parquet project. We are releasing > parquet-format first because the other projects (parquet-mr and parquet-cpp) > depend on it. > > This release uses the pre-Apache maven coordinate com.twitter:parquet-format > and parquet.* package names. To make the transition to org.apache naming as > smooth as possible for downstream projects, we are planning to release a > com.twitter artifact immediately followed by an org.apache artifact. These > artifacts will be identical except for naming changes: > > * com.twitter:parquet-format => org.apache.parquet:parquet-format > * package parquet.* => package org.apache.parquet.* > > There are three major changes included in this release: > * PARQUET-119: Add encoding stats to ColumnMetaData > * PARQUET-79: Streaming thrift API > * PARQUET-12: New logical types > > > rb > > > -- > Ryan Blue > > - > 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] OpenAZ as new Incubator project
So you want me to repost the proposal with the Subject changed to start with "[DISCUSS]"? Or should I simply reference the wiki page? Hal > -Original Message- > From: John D. Ament [mailto:john.d.am...@gmail.com] > Sent: Thursday, November 13, 2014 5:03 PM > To: general@incubator.apache.org > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project > > Hal, > > Per customs, would you mind if we cancel this and start with a > [DISCUSS] thread about OpenAZ? It's unclear if you meant this to be a > vote or something. > > John > > On Thu, Nov 13, 2014 at 4:14 PM, Hal Lockhart > wrote: > > > 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 semantics 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. > > > > AT&T has recently contributed their extensive XACML framework to the > > project. > > > > The AT&T framework represents the entire XACML 3.0 object set as a > > collection of Java interfaces and standard implementations of those > > interfaces. The AT&T 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 AT&T framework also includes interfaces and implementations to > > standardize development of PIP engines that are used by the AT&T PDP > > implementation, and can be used by other implementations built on top > > of the AT&T 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 re
Re: [PROPOSAL] OpenAZ as new Incubator project
I think so. There's a few things that you want to iron out first, before people start voting on this. - 3 is generally the "minimum" number of mentors. - I can't find a "Paul Freemantle" on the apache committers list. There's a Paul Fremantle, minor spelling difference. - You may want to review this section to get a better understanding of the goals: http://incubator.apache.org/guides/proposal.html#formulating the Discuss option just helps everyone look at your proposal a little bit better and determine if there's any gotchas. For example, I'm surprised to see a new incubator project using SVN. - Can you list out your issue tracking preference (should probably be JIRA unless you need something else) - Please also explicitly list the mailing lists your want. John On Thu, Nov 13, 2014 at 8:43 PM, Hal Lockhart wrote: > So you want me to repost the proposal with the Subject changed to start > with "[DISCUSS]"? Or should I simply reference the wiki page? > > Hal > > > -Original Message- > > From: John D. Ament [mailto:john.d.am...@gmail.com] > > Sent: Thursday, November 13, 2014 5:03 PM > > To: general@incubator.apache.org > > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project > > > > Hal, > > > > Per customs, would you mind if we cancel this and start with a > > [DISCUSS] thread about OpenAZ? It's unclear if you meant this to be a > > vote or something. > > > > John > > > > On Thu, Nov 13, 2014 at 4:14 PM, Hal Lockhart > > wrote: > > > > > 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 semantics 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. > > > > > > AT&T has recently contributed their extensive XACML framework to the > > > project. > > > > > > The AT&T framework represents the entire XACML 3.0 object set as a > > > collection of Java interfaces and standard implementations of those > > > interfaces. The AT&T 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 > >
Re: [VOTE] Graduation of Apache MetaModel from the Incubator
My vote: +1 (binding) On Thu, Nov 13, 2014 at 9:39 PM, Henry Saputra wrote: > Hi All, > > The Apache MetaModel community has wrapped up the VOTE to propose for > graduation from Apache incubator. The VOTE passed with result: > 9 binding +1s > zero 0s > zero -1s > (http://bit.ly/1u8n8eo) > > Apache MetaModel came into ASF incubator on 2013 and since then have > grown into small but active community. > > We have made several good releases with different release managers, > and also add new PPMC/committers [1]. > The project also has good traffic on the dev mailing list [2]. > > We would like to propose graduation of Apache MetaModel from ASF > incubator to top level project. > > > [ ] +1 Graduate Apache MetaModel from the Incubator. > [ ] +0 Don't care. > [ ] -1 Don't graduate Apache MetaModel from the Incubator because.. . > > > The VOTE will open for 72 hours (11/17/2014) > > > Here is the proposal for the board resolution for graduation: > > > === Board Resolution == > > Establish the Apache MetaModel Project > > WHEREAS, the Board of Directors deems it to be in the best interests > of the Foundation and consistent with the Foundation's purpose to > establish a Project Management Committee charged with the creation and > maintenance of open-source software, for distribution at no charge to > the public, related to providing an implementation of a > Platform-as-a-Service Framework. > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee > (PMC), to be known as the "Apache MetaModel Project", be and hereby is > established pursuant to Bylaws of the Foundation; and be it further > > RESOLVED, that the Apache MetaModel Project be and hereby is > responsible for the creation and maintenance of software related to > providing an implementation of a Platform-as-a-Service Framework; and > be it further > > RESOLVED, that the office of "Vice President, MetaModel" be and hereby > is created, the person holding such office to serve at the direction > of the Board of Directors as the chair of the Apache MetaModel > Project, and to have primary responsibility for management of the > projects within the scope of responsibility of the Apache MetaModel > Project; and be it further > > RESOLVED, that the persons listed immediately below be and hereby are > appointed to serve as the initial members of the Apache MetaModel > Project: > > * Alberto Rodriguez > * Ankit Kumar > * Arvind Prabhakar > * Henry Saputra > * Juan Jose van der Linden > * Kasper Sørensen > * Matt Franklin > * Noah Slater > * Sameer Arora > * Tomasz Guzialek > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Kasper Sørensen be > appointed to the office of Vice President, MetaModel, to serve in > accordance with and subject to the direction of the Board of Directors > and the Bylaws of the Foundation until death, resignation, retirement, > removal or disqualification, or until a successor is appointed; and be > it further > > RESOLVED, that the initial Apache MetaModel PMC be and hereby is > tasked with the creation of a set of bylaws intended to encourage open > development and increased participation in the Apache MetaModel > Project; and be it further > > RESOLVED, that the Apache MetaModel Project be and hereby is tasked > with the migration and rationalization of the Apache Incubator > MetaModel podling; and be it further > > RESOLVED, that all responsibilities pertaining to the Apache Incubator > MetaModel podling encumbered upon the Apache Incubator Project are > hereafter discharged. > > > > > Thanks, > > Henry > On behalf of Apache MetaModel incubating PPMCs > > [1] http://incubator.apache.org/projects/metamodel.html > [2] http://mail-archives.apache.org/mod_mbox/metamodel-dev - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Graduation of Apache MetaModel from the Incubator
Hi All, The Apache MetaModel community has wrapped up the VOTE to propose for graduation from Apache incubator. The VOTE passed with result: 9 binding +1s zero 0s zero -1s (http://bit.ly/1u8n8eo) Apache MetaModel came into ASF incubator on 2013 and since then have grown into small but active community. We have made several good releases with different release managers, and also add new PPMC/committers [1]. The project also has good traffic on the dev mailing list [2]. We would like to propose graduation of Apache MetaModel from ASF incubator to top level project. [ ] +1 Graduate Apache MetaModel from the Incubator. [ ] +0 Don't care. [ ] -1 Don't graduate Apache MetaModel from the Incubator because.. . The VOTE will open for 72 hours (11/17/2014) Here is the proposal for the board resolution for graduation: === Board Resolution == Establish the Apache MetaModel Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software, for distribution at no charge to the public, related to providing an implementation of a Platform-as-a-Service Framework. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache MetaModel Project", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache MetaModel Project be and hereby is responsible for the creation and maintenance of software related to providing an implementation of a Platform-as-a-Service Framework; and be it further RESOLVED, that the office of "Vice President, MetaModel" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache MetaModel Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache MetaModel Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache MetaModel Project: * Alberto Rodriguez * Ankit Kumar * Arvind Prabhakar * Henry Saputra * Juan Jose van der Linden * Kasper Sørensen * Matt Franklin * Noah Slater * Sameer Arora * Tomasz Guzialek NOW, THEREFORE, BE IT FURTHER RESOLVED, that Kasper Sørensen be appointed to the office of Vice President, MetaModel, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache MetaModel PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache MetaModel Project; and be it further RESOLVED, that the Apache MetaModel Project be and hereby is tasked with the migration and rationalization of the Apache Incubator MetaModel podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator MetaModel podling encumbered upon the Apache Incubator Project are hereafter discharged. Thanks, Henry On behalf of Apache MetaModel incubating PPMCs [1] http://incubator.apache.org/projects/metamodel.html [2] http://mail-archives.apache.org/mod_mbox/metamodel-dev - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduation of Apache MetaModel from the Incubator
+1 (binding). Henry great job helping to lead the way of a great project through the Incubator as a mentor. Good luck MetaModel! 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 ++ -Original Message- From: Henry Saputra Reply-To: "general@incubator.apache.org" Date: Friday, November 14, 2014 at 6:39 AM To: "general@incubator.apache.org" Subject: [VOTE] Graduation of Apache MetaModel from the Incubator >Hi All, > >The Apache MetaModel community has wrapped up the VOTE to propose for >graduation from Apache incubator. The VOTE passed with result: >9 binding +1s >zero 0s >zero -1s >(http://bit.ly/1u8n8eo) > >Apache MetaModel came into ASF incubator on 2013 and since then have >grown into small but active community. > >We have made several good releases with different release managers, >and also add new PPMC/committers [1]. >The project also has good traffic on the dev mailing list [2]. > >We would like to propose graduation of Apache MetaModel from ASF >incubator to top level project. > > >[ ] +1 Graduate Apache MetaModel from the Incubator. >[ ] +0 Don't care. >[ ] -1 Don't graduate Apache MetaModel from the Incubator because.. . > > >The VOTE will open for 72 hours (11/17/2014) > > >Here is the proposal for the board resolution for graduation: > > >=== Board Resolution == > >Establish the Apache MetaModel Project > >WHEREAS, the Board of Directors deems it to be in the best interests >of the Foundation and consistent with the Foundation's purpose to >establish a Project Management Committee charged with the creation and >maintenance of open-source software, for distribution at no charge to >the public, related to providing an implementation of a >Platform-as-a-Service Framework. > >NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee >(PMC), to be known as the "Apache MetaModel Project", be and hereby is >established pursuant to Bylaws of the Foundation; and be it further > >RESOLVED, that the Apache MetaModel Project be and hereby is >responsible for the creation and maintenance of software related to >providing an implementation of a Platform-as-a-Service Framework; and >be it further > >RESOLVED, that the office of "Vice President, MetaModel" be and hereby >is created, the person holding such office to serve at the direction >of the Board of Directors as the chair of the Apache MetaModel >Project, and to have primary responsibility for management of the >projects within the scope of responsibility of the Apache MetaModel >Project; and be it further > >RESOLVED, that the persons listed immediately below be and hereby are >appointed to serve as the initial members of the Apache MetaModel >Project: > >* Alberto Rodriguez >* Ankit Kumar >* Arvind Prabhakar >* Henry Saputra >* Juan Jose van der Linden >* Kasper Sørensen >* Matt Franklin >* Noah Slater >* Sameer Arora >* Tomasz Guzialek > >NOW, THEREFORE, BE IT FURTHER RESOLVED, that Kasper Sørensen be >appointed to the office of Vice President, MetaModel, to serve in >accordance with and subject to the direction of the Board of Directors >and the Bylaws of the Foundation until death, resignation, retirement, >removal or disqualification, or until a successor is appointed; and be >it further > >RESOLVED, that the initial Apache MetaModel PMC be and hereby is >tasked with the creation of a set of bylaws intended to encourage open >development and increased participation in the Apache MetaModel >Project; and be it further > >RESOLVED, that the Apache MetaModel Project be and hereby is tasked >with the migration and rationalization of the Apache Incubator >MetaModel podling; and be it further > >RESOLVED, that all responsibilities pertaining to the Apache Incubator >MetaModel podling encumbered upon the Apache Incubator Project are >hereafter discharged. > > > > >Thanks, > >Henry >On behalf of Apache MetaModel incubating PPMCs > >[1] http://incubator.apache.org/projects/metamodel.html >[2] http://mail-archives.apache.org/mod_mbox/metamodel-dev > >- >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduation of Apache MetaModel from the Incubator
+1 (binding) On Thu, Nov 13, 2014 at 9:39 PM, Henry Saputra wrote: > Hi All, > > The Apache MetaModel community has wrapped up the VOTE to propose for > graduation from Apache incubator. The VOTE passed with result: > 9 binding +1s > zero 0s > zero -1s > (http://bit.ly/1u8n8eo) > > Apache MetaModel came into ASF incubator on 2013 and since then have > grown into small but active community. > > We have made several good releases with different release managers, > and also add new PPMC/committers [1]. > The project also has good traffic on the dev mailing list [2]. > > We would like to propose graduation of Apache MetaModel from ASF > incubator to top level project. > > > [ ] +1 Graduate Apache MetaModel from the Incubator. > [ ] +0 Don't care. > [ ] -1 Don't graduate Apache MetaModel from the Incubator because.. . > > > The VOTE will open for 72 hours (11/17/2014) > > > Here is the proposal for the board resolution for graduation: > > > === Board Resolution == > > Establish the Apache MetaModel Project > > WHEREAS, the Board of Directors deems it to be in the best interests > of the Foundation and consistent with the Foundation's purpose to > establish a Project Management Committee charged with the creation and > maintenance of open-source software, for distribution at no charge to > the public, related to providing an implementation of a > Platform-as-a-Service Framework. > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee > (PMC), to be known as the "Apache MetaModel Project", be and hereby is > established pursuant to Bylaws of the Foundation; and be it further > > RESOLVED, that the Apache MetaModel Project be and hereby is > responsible for the creation and maintenance of software related to > providing an implementation of a Platform-as-a-Service Framework; and > be it further > > RESOLVED, that the office of "Vice President, MetaModel" be and hereby > is created, the person holding such office to serve at the direction > of the Board of Directors as the chair of the Apache MetaModel > Project, and to have primary responsibility for management of the > projects within the scope of responsibility of the Apache MetaModel > Project; and be it further > > RESOLVED, that the persons listed immediately below be and hereby are > appointed to serve as the initial members of the Apache MetaModel > Project: > > * Alberto Rodriguez > * Ankit Kumar > * Arvind Prabhakar > * Henry Saputra > * Juan Jose van der Linden > * Kasper Sørensen > * Matt Franklin > * Noah Slater > * Sameer Arora > * Tomasz Guzialek > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Kasper Sørensen be > appointed to the office of Vice President, MetaModel, to serve in > accordance with and subject to the direction of the Board of Directors > and the Bylaws of the Foundation until death, resignation, retirement, > removal or disqualification, or until a successor is appointed; and be > it further > > RESOLVED, that the initial Apache MetaModel PMC be and hereby is > tasked with the creation of a set of bylaws intended to encourage open > development and increased participation in the Apache MetaModel > Project; and be it further > > RESOLVED, that the Apache MetaModel Project be and hereby is tasked > with the migration and rationalization of the Apache Incubator > MetaModel podling; and be it further > > RESOLVED, that all responsibilities pertaining to the Apache Incubator > MetaModel podling encumbered upon the Apache Incubator Project are > hereafter discharged. > > > > > Thanks, > > Henry > On behalf of Apache MetaModel incubating PPMCs > > [1] http://incubator.apache.org/projects/metamodel.html > [2] http://mail-archives.apache.org/mod_mbox/metamodel-dev > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
