Re: [PROPOSAL] Apache AsterixDB Incubator
Hi Henry, thanks! It’s great that you’ve seen (and liked) AsterixDB before. Even if your time is very limited we would be very happy to have you on board as a mentor. I’ll add you to the proposal. Cheers, Till On Jan 19, 2015, at 10:26 AM, Henry Saputra henry.sapu...@gmail.com wrote: +1 This is GREAT News! Was watching and trying AsterixDB last year and looked in awesome shape. I have my plate full but would love to help mentor this project to get it going to ASF if needed! - Henry On Wed, Jan 14, 2015 at 6:21 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: Hi Folks, I am pleased to bring forth the Apache AsterixDB proposal to the Apache Incubator as Champion, working in collaboration with the team. Please find the wiki proposal here: https://wiki.apache.org/incubator/AsterixDBProposal Full text of the proposal is below. Please discuss and enjoy. I’ll leave the discussion open for a week, and then look to call a VOTE hopefully end of next week if all is well. Cheers! Chris Mattmann = Apache AsterixDB Proposal Abstract Apache AsterixDB is a scalable big data management system (BDMS) that provides storage, management, and query capabilities for large collections of semi-structured data. Proposal AsterixDB is a big data management system (BDMS) that makes it well-suited to needs such as web data warehousing and social data storage and analysis. Feature-wise, AsterixDB has: * A NoSQL style data model (ADM) based on extending JSON with object database concepts. * An expressive and declarative query language (AQL) for querying semi-structured data. * A runtime query execution engine, Hyracks, for partitioned-parallel execution of query plans. * Partitioned LSM-based data storage and indexing for efficient ingestion of newly arriving data. * Support for querying and indexing external data (e.g., in HDFS) as well as data stored within AsterixDB. * A rich set of primitive data types, including support for spatial, temporal, and textual data. * Indexing options that include B+ trees, R trees, and inverted keyword index support. * Basic transactional (concurrency and recovery) capabilities akin to those of a NoSQL store. Background and Rationale In the world of relational databases, the need to tackle data volumes that exceed the capabilities of a single server led to the development of “shared-nothing” parallel database systems several decades ago. These systems spread data over a cluster based on a partitioning strategy, such as hash partitioning, and queries are processed by employing partitioned-parallel divide-and-conquer techniques. Since these systems are fronted by a high-level, declarative language (SQL), their users are shielded from the complexities of parallel programming. Parallel database systems have been an extremely successful application of parallel computing, and quite a number of commercial products exist today. In the distributed systems world, the Web brought a need to index and query its huge content. SQL and relational databases were not the answer, though shared-nothing clusters again emerged as the hardware platform of choice. Google developed the Google File System (GFS) and MapReduce programming model to allow programmers to store and process Big Data by writing a few user-defined functions. The MapReduce framework applies these functions in parallel to data instances in distributed files (map) and to sorted groups of instances sharing a common key (reduce) -- not unlike the partitioned parallelism in parallel database systems. Apache's Hadoop MapReduce platform is the most prominent implementation of this paradigm for the rest of the Big Data community. On top of Hadoop and HDFS sit declarative languages like Pig and Hive that each compile down to Hadoop MapReduce jobs. The big Web companies were also challenged by extreme user bases (100s of millions of users) and needed fast simple lookups and updates to very large keyed data sets like user profiles. SQL databases were deemed either too expensive or not scalable, so the “NoSQL movement” was born. The ASF now has HBase and Cassandra, two popular key-value stores, in this space. MongoDB and Couchbase are other open source alternatives (document stores). It is evident from the rapidly growing popularity of NoSQL stores, as well as the strong demand for Big Data analytics engines today, that there is a strong (and growing!) need to store, process, *and* query large volumes of semi-structured data in many application areas. Until very recently, developers have had to ``choose'' between using big data analytics engines like Apache Hive or Apache Spark, which can do complex query processing and analysis over HDFS-resident files, and flexible but low-function data stores like MongoDB or Apache HBase. (The Apache Phoenix
Re: [PROPOSAL] Apache AsterixDB Incubator
On Jan 19, 2015, at 11:34 AM, jan i j...@apache.org wrote: Looks like a real challenging project, and the proposal looks as if it has already been through a couple of refinement rounds. Count on my +1, when it comes to voting. Will do! Thanks, Till rgds jan i On 19 January 2015 at 19:26, Henry Saputra henry.sapu...@gmail.com mailto:henry.sapu...@gmail.com wrote: +1 This is GREAT News! Was watching and trying AsterixDB last year and looked in awesome shape. I have my plate full but would love to help mentor this project to get it going to ASF if needed! - Henry On Wed, Jan 14, 2015 at 6:21 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov mailto:chris.a.mattm...@jpl.nasa.gov wrote: Hi Folks, I am pleased to bring forth the Apache AsterixDB proposal to the Apache Incubator as Champion, working in collaboration with the team. Please find the wiki proposal here: https://wiki.apache.org/incubator/AsterixDBProposal https://wiki.apache.org/incubator/AsterixDBProposal Full text of the proposal is below. Please discuss and enjoy. I’ll leave the discussion open for a week, and then look to call a VOTE hopefully end of next week if all is well. Cheers! Chris Mattmann = Apache AsterixDB Proposal Abstract Apache AsterixDB is a scalable big data management system (BDMS) that provides storage, management, and query capabilities for large collections of semi-structured data. Proposal AsterixDB is a big data management system (BDMS) that makes it well-suited to needs such as web data warehousing and social data storage and analysis. Feature-wise, AsterixDB has: * A NoSQL style data model (ADM) based on extending JSON with object database concepts. * An expressive and declarative query language (AQL) for querying semi-structured data. * A runtime query execution engine, Hyracks, for partitioned-parallel execution of query plans. * Partitioned LSM-based data storage and indexing for efficient ingestion of newly arriving data. * Support for querying and indexing external data (e.g., in HDFS) as well as data stored within AsterixDB. * A rich set of primitive data types, including support for spatial, temporal, and textual data. * Indexing options that include B+ trees, R trees, and inverted keyword index support. * Basic transactional (concurrency and recovery) capabilities akin to those of a NoSQL store. Background and Rationale In the world of relational databases, the need to tackle data volumes that exceed the capabilities of a single server led to the development of “shared-nothing” parallel database systems several decades ago. These systems spread data over a cluster based on a partitioning strategy, such as hash partitioning, and queries are processed by employing partitioned-parallel divide-and-conquer techniques. Since these systems are fronted by a high-level, declarative language (SQL), their users are shielded from the complexities of parallel programming. Parallel database systems have been an extremely successful application of parallel computing, and quite a number of commercial products exist today. In the distributed systems world, the Web brought a need to index and query its huge content. SQL and relational databases were not the answer, though shared-nothing clusters again emerged as the hardware platform of choice. Google developed the Google File System (GFS) and MapReduce programming model to allow programmers to store and process Big Data by writing a few user-defined functions. The MapReduce framework applies these functions in parallel to data instances in distributed files (map) and to sorted groups of instances sharing a common key (reduce) -- not unlike the partitioned parallelism in parallel database systems. Apache's Hadoop MapReduce platform is the most prominent implementation of this paradigm for the rest of the Big Data community. On top of Hadoop and HDFS sit declarative languages like Pig and Hive that each compile down to Hadoop MapReduce jobs. The big Web companies were also challenged by extreme user bases (100s of millions of users) and needed fast simple lookups and updates to very large keyed data sets like user profiles. SQL databases were deemed either too expensive or not scalable, so the “NoSQL movement” was born. The ASF now has HBase and Cassandra, two popular key-value stores, in this space. MongoDB and Couchbase are other open source alternatives (document stores). It is evident from the rapidly growing popularity of NoSQL stores, as well as the strong demand for Big Data analytics engines today, that there is a strong (and growing!) need to store, process, *and* query large volumes of semi-structured data in many application areas. Until very recently, developers have had
Re: [PROPOSAL] Apache AsterixDB Incubator
Thank you. So for we’ve added 3 slots for mentors on the proposal - I hope that’ll be sufficient even for the relatively large number of new committers. Till On Jan 19, 2015, at 8:17 PM, Henry Saputra henry.sapu...@gmail.com wrote: Thanks Till, Will try to solicit more mentors to help. Especially with initial committers mostly have not been exposed to contributing the Apache way. - Henry On Mon, Jan 19, 2015 at 5:28 PM, Till Westmann t...@westmann.org wrote: Hi Henry, thanks! It’s great that you’ve seen (and liked) AsterixDB before. Even if your time is very limited we would be very happy to have you on board as a mentor. I’ll add you to the proposal. Cheers, Till On Jan 19, 2015, at 10:26 AM, Henry Saputra henry.sapu...@gmail.com wrote: +1 This is GREAT News! Was watching and trying AsterixDB last year and looked in awesome shape. I have my plate full but would love to help mentor this project to get it going to ASF if needed! - Henry On Wed, Jan 14, 2015 at 6:21 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: Hi Folks, I am pleased to bring forth the Apache AsterixDB proposal to the Apache Incubator as Champion, working in collaboration with the team. Please find the wiki proposal here: https://wiki.apache.org/incubator/AsterixDBProposal Full text of the proposal is below. Please discuss and enjoy. I’ll leave the discussion open for a week, and then look to call a VOTE hopefully end of next week if all is well. Cheers! Chris Mattmann = Apache AsterixDB Proposal Abstract Apache AsterixDB is a scalable big data management system (BDMS) that provides storage, management, and query capabilities for large collections of semi-structured data. Proposal AsterixDB is a big data management system (BDMS) that makes it well-suited to needs such as web data warehousing and social data storage and analysis. Feature-wise, AsterixDB has: * A NoSQL style data model (ADM) based on extending JSON with object database concepts. * An expressive and declarative query language (AQL) for querying semi-structured data. * A runtime query execution engine, Hyracks, for partitioned-parallel execution of query plans. * Partitioned LSM-based data storage and indexing for efficient ingestion of newly arriving data. * Support for querying and indexing external data (e.g., in HDFS) as well as data stored within AsterixDB. * A rich set of primitive data types, including support for spatial, temporal, and textual data. * Indexing options that include B+ trees, R trees, and inverted keyword index support. * Basic transactional (concurrency and recovery) capabilities akin to those of a NoSQL store. Background and Rationale In the world of relational databases, the need to tackle data volumes that exceed the capabilities of a single server led to the development of “shared-nothing” parallel database systems several decades ago. These systems spread data over a cluster based on a partitioning strategy, such as hash partitioning, and queries are processed by employing partitioned-parallel divide-and-conquer techniques. Since these systems are fronted by a high-level, declarative language (SQL), their users are shielded from the complexities of parallel programming. Parallel database systems have been an extremely successful application of parallel computing, and quite a number of commercial products exist today. In the distributed systems world, the Web brought a need to index and query its huge content. SQL and relational databases were not the answer, though shared-nothing clusters again emerged as the hardware platform of choice. Google developed the Google File System (GFS) and MapReduce programming model to allow programmers to store and process Big Data by writing a few user-defined functions. The MapReduce framework applies these functions in parallel to data instances in distributed files (map) and to sorted groups of instances sharing a common key (reduce) -- not unlike the partitioned parallelism in parallel database systems. Apache's Hadoop MapReduce platform is the most prominent implementation of this paradigm for the rest of the Big Data community. On top of Hadoop and HDFS sit declarative languages like Pig and Hive that each compile down to Hadoop MapReduce jobs. The big Web companies were also challenged by extreme user bases (100s of millions of users) and needed fast simple lookups and updates to very large keyed data sets like user profiles. SQL databases were deemed either too expensive or not scalable, so the “NoSQL movement” was born. The ASF now has HBase and Cassandra, two popular key-value stores, in this space. MongoDB and Couchbase are other open source alternatives (document stores). It is evident from the rapidly growing popularity of NoSQL stores, as well as the strong demand for
Re: When is an ICLA needed?
Rob, I recommend projects to request ICLAs whenever accepting a contribution. Signing an ICLA has no correlation to being accepted as a committer. John On Tue Jan 20 2015 at 6:04:25 AM Rob Vesse rve...@dotnetrdf.org wrote: All I keep an eye on the Lucene.Net TLP since I use it in some of my other projects and after a long hiatus the activity in that community has picked up considerably. However there is one thing that has caught my eye that they've been doing recently which I'm not sure is strictly necessary. I noticed that as they've been recruiting new contributors (not committers) for their porting efforts they've been asking these contributors to sign the ICLA before they will accept a pull request. My understanding was always that the ICLA is only required if you are a committer though may still be desirable for larger contributions, quoting from http://www.apache.org/licenses/#clas - The ASF desires that all contributors of ideas, code, or documentation to the Apache projects complete, sign, and submit (via postal mail, fax or email) an Individual Contributor License Agreement http://www.apache.org/licenses/icla.txt (1) (CLA) [ PDF form http://www.apache.org/licenses/icla.pdf ]. The purpose of this agreement is to clearly define the terms under which intellectual property has been contributed to the ASF and thereby allow us to defend the project should there be a legal dispute regarding the software at some future time. A signed CLA is required to be on file before an individual is given commit rights to an ASF project. Note the use of the word desires here, only committers are required to have an agreement on file. Contributors can always make contributions without one since the Apache License explicitly has a clause that covers this (http://www.apache.org/licenses/LICENSE-2.0#contributions). Actual committers still have to merge and push the pull requests made by contributors to the ASF repos so from an ASF perspective the provenance of the contributions is OK since we know they were pushed by a committer (though obviously committers still need to be reviewing the contributions to check for any possible IP violations) Is my understanding on this right? If so I shall be pinging their dev list to remind them of this since IMO they are putting a potentially unnecessary hurdle in front of new contributors. Additionally they don't appear to have offered committership/PMC membership to any of these new people who have signed ICLAs and whose pull requests are getting merged so I will be pinging the list to remind them about this regardless. I've seen that there are several people who've made considerable sustained contributions which in any other ASF project I've been involved in would have earned them sufficient merit to be offered at least committership (if not PMC membership) by now. Regards, Rob - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
When is an ICLA needed?
All I keep an eye on the Lucene.Net TLP since I use it in some of my other projects and after a long hiatus the activity in that community has picked up considerably. However there is one thing that has caught my eye that they've been doing recently which I'm not sure is strictly necessary. I noticed that as they've been recruiting new contributors (not committers) for their porting efforts they've been asking these contributors to sign the ICLA before they will accept a pull request. My understanding was always that the ICLA is only required if you are a committer though may still be desirable for larger contributions, quoting from http://www.apache.org/licenses/#clas - The ASF desires that all contributors of ideas, code, or documentation to the Apache projects complete, sign, and submit (via postal mail, fax or email) an Individual Contributor License Agreement http://www.apache.org/licenses/icla.txt (1) (CLA) [ PDF form http://www.apache.org/licenses/icla.pdf ]. The purpose of this agreement is to clearly define the terms under which intellectual property has been contributed to the ASF and thereby allow us to defend the project should there be a legal dispute regarding the software at some future time. A signed CLA is required to be on file before an individual is given commit rights to an ASF project. Note the use of the word desires here, only committers are required to have an agreement on file. Contributors can always make contributions without one since the Apache License explicitly has a clause that covers this (http://www.apache.org/licenses/LICENSE-2.0#contributions). Actual committers still have to merge and push the pull requests made by contributors to the ASF repos so from an ASF perspective the provenance of the contributions is OK since we know they were pushed by a committer (though obviously committers still need to be reviewing the contributions to check for any possible IP violations) Is my understanding on this right? If so I shall be pinging their dev list to remind them of this since IMO they are putting a potentially unnecessary hurdle in front of new contributors. Additionally they don't appear to have offered committership/PMC membership to any of these new people who have signed ICLAs and whose pull requests are getting merged so I will be pinging the list to remind them about this regardless. I've seen that there are several people who've made considerable sustained contributions which in any other ASF project I've been involved in would have earned them sufficient merit to be offered at least committership (if not PMC membership) by now. Regards, Rob - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: When is an ICLA needed?
Hi, On Tue, Jan 20, 2015 at 11:57 AM, Rob Vesse rve...@dotnetrdf.org wrote: ...My understanding was always that the ICLA is only required if you are a committer though may still be desirable for larger contributions,... That's my understanding, requiring an iCLA for minor contributions is not needed. What's important for all contributions IMO is to have documented evidence (dev list, jira, bugzilla) that the contribution is voluntary, and to indicate when committing where the contribution comes from. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: When is an ICLA needed?
On 20 January 2015 at 11:57, Rob Vesse rve...@dotnetrdf.org wrote: All I keep an eye on the Lucene.Net TLP since I use it in some of my other projects and after a long hiatus the activity in that community has picked up considerably. However there is one thing that has caught my eye that they've been doing recently which I'm not sure is strictly necessary. I noticed that as they've been recruiting new contributors (not committers) for their porting efforts they've been asking these contributors to sign the ICLA before they will accept a pull request. My understanding was always that the ICLA is only required if you are a committer though may still be desirable for larger contributions, quoting from http://www.apache.org/licenses/#clas - The ASF desires that all contributors of ideas, code, or documentation to the Apache projects complete, sign, and submit (via postal mail, fax or email) an Individual Contributor License Agreement http://www.apache.org/licenses/icla.txt (1) (CLA) [ PDF form http://www.apache.org/licenses/icla.pdf ]. The purpose of this agreement is to clearly define the terms under which intellectual property has been contributed to the ASF and thereby allow us to defend the project should there be a legal dispute regarding the software at some future time. A signed CLA is required to be on file before an individual is given commit rights to an ASF project. Note the use of the word desires here, only committers are required to have an agreement on file. Contributors can always make contributions without one since the Apache License explicitly has a clause that covers this (http://www.apache.org/licenses/LICENSE-2.0#contributions). Actual committers still have to merge and push the pull requests made by contributors to the ASF repos so from an ASF perspective the provenance of the contributions is OK since we know they were pushed by a committer (though obviously committers still need to be reviewing the contributions to check for any possible IP violations) Is my understanding on this right? In my opinion your understanding is correct, an ICLA is only needed to become committer, but can also be signed before such an invitaion. I too try to have contributors sign an ICLA if they are active, because then we have less license problems. When the contributor have not signed an ICLA the committer needs to more carefully examine the license state of the code (e.g. the contributor included the false header info, compared to what the project uses). There is also a marketing aspect, having people sign a ICLA is a way to test their interest before running DISCUSS/VOTE on making them committers. rgds jan i If so I shall be pinging their dev list to remind them of this since IMO they are putting a potentially unnecessary hurdle in front of new contributors. Additionally they don't appear to have offered committership/PMC membership to any of these new people who have signed ICLAs and whose pull requests are getting merged so I will be pinging the list to remind them about this regardless. I've seen that there are several people who've made considerable sustained contributions which in any other ASF project I've been involved in would have earned them sufficient merit to be offered at least committership (if not PMC membership) by now. Regards, Rob - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Jan 19, 2015, at 11:57 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jan 20, 2015 at 1:37 AM, Chris Douglas cdoug...@apache.org wrote: ...So make a list of the IPMC members you believe should judge the other 90%, and submit a proposal to the board to start a new project. Fork the incubator How is that different from pruning the current IPMC membership by removing inactive members? I don't think those inactive folks are a problem, but if people think they are it's easy to ask them if they want to stay, and remove those who reply no or don't reply. No one is saying that the problem is inactive IPMC members. No one. Isn’t it obvious what the above and IncubatorV2 proposal are about? Consolidating like minded individuals into a new IPMC and shutting out the other inconvenient members until they come to their senses”. Frankly, if there are IPMC members that are a real problem then it’s the job of the VP of the Incubator to have a “chat” with them. Are there really so many that it warrants a reboot of the IPMC itself? Regards, Alan
Re: Incubating with Apache Commons as champion?
Stian If a community made predominantly of existing Apache committers (or containing a strong core of) already exists and this would be a small self contained module as part of Apache Commons then why does the Incubator need be involved at all? Why can this not just be submitted directly to Apache Commons via the IP Clearance procedure (http://incubator.apache.org/ip-clearance/index.html)? Commons already allows any ASF committer to commit so the existing community can continue working on the code just fine. The only sticking point would be once Commons-RDF wants to release in which case you'd likely need to canvas the larger commons community for votes until such time as the Commons-RDF committers have earned sufficient merit to be offered PMC membership On the other hand does Commons-RDF necessarily need to come to the ASF at all? If it is a small self-contained interface module that will remain stable what does it gain (other than brand association) by coming to the ASF? Rob On 20/01/2015 14:28, Stian Soiland-Reyes st...@apache.org wrote: The discussion on dev@commons about coming-to-Apache Commons-RDF (https://github.com/commons-rdf/commons-rdf/) seems to be rejecting a temporary mailing list like rdf@commons as it is seen t be splitting Apache Commons as a project - the ideal committer on Apache Commons is caring about all its components (avoiding the Jakarta pitfalls). We had not considered becoming a TLP as once the API (mainly a set of interfaces) is settled, by then it will probably be pretty much a quiet project except the odd maintenance patch - and also by being a common component of several RDF projects within Apache, its best home then would be under Commons (presumably with most of the original committers still involved). However the large traffic of dev@commons (~400/month) about all the other components can be a problem for trying to engage the non-Apache community around commons-rdf while we flesh out the API. (This has currently been done solely through Github issues, pull requests, and watching the project). In a way we are limited by the technology of the Apache mailing lists. (I know, I know...). (I mentioned gitlab.com ) The suggestion is that Commons-RDF could be a incubator project, but with a projected path to become part of the Apache Commons instead of a TLP. (I believe this path has not happened before) So this would be using the old structure of having a champion of Apache Commons - could this be a workable incubator project? In a way it would be incubating just the code until API maturity rather than the community or Apache Way as both of those already exist. In such an (old skool) setup, would it be the Commons PMC / dev@commons who would vote over the incubating releases? Once graduating it would just become a component under Apache Commons and the community would just be dev@commons where the committers would already be members - the dev@rdf.incubator list would simply close. .. and where would mentors come from? Would existing committers from those other Apache projects (Jena, Marmotta, Clerezza) be enough - or should it be someone from IMPC or from dev@commons? See http://mail-archives.apache.org/mod_mbox/commons-dev/201501.mbox/%3CCAB917 RLJE%2BgFEpw%3Dyp-c-HpXEnvL12JZLLpc4wphGyjGH_6%3D9Q%40mail.gmail.com%3E for the whole threads :) -- Forwarded message -- From: Stian Soiland-Reyes st...@apache.org Date: 20 January 2015 at 14:06 Subject: Re: [DISCUSS][RDF] Separate mailing list for Commons RDF To: Commons Developers List d...@commons.apache.org Agree that maybe the the Incubator with a projected path to the Commons could be a workable middle ground while Commons-RDF is still incubating code-wise (but not community or Apache Way-wise). No earlier project has gone through this route (https://incubator.apache.org/projects/ ) - this would reuse the deprecated Champion project to be Apache Commons instead of Incubator PMC in this case. Such a proposal has some good features - I presume commons-rdf releases would still be voted over (and thus involve) the Commons PMC and dev@commons (as they would after graduating). As an API, then Commons-RDF should not be considered stable while being in 0.x.x-incubating anyway. On 20 January 2015 at 13:58, Torsten Curdt tcu...@vafer.org wrote: There are several ASF projects in the RDF space. They have been through the incubator. Please do talk to those projects if you have concerns. I am sorry - but how are those projects relevant in this case? And what's so bad about the incubator? You could (maybe) later on come to Commons. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Stian Soiland-Reyes Apache Taverna (incubating) http://orcid.org/-0001-9842-9718 -- Stian Soiland-Reyes Apache Taverna (incubating)
Incubating with Apache Commons as champion?
The discussion on dev@commons about coming-to-Apache Commons-RDF (https://github.com/commons-rdf/commons-rdf/) seems to be rejecting a temporary mailing list like rdf@commons as it is seen t be splitting Apache Commons as a project - the ideal committer on Apache Commons is caring about all its components (avoiding the Jakarta pitfalls). We had not considered becoming a TLP as once the API (mainly a set of interfaces) is settled, by then it will probably be pretty much a quiet project except the odd maintenance patch - and also by being a common component of several RDF projects within Apache, its best home then would be under Commons (presumably with most of the original committers still involved). However the large traffic of dev@commons (~400/month) about all the other components can be a problem for trying to engage the non-Apache community around commons-rdf while we flesh out the API. (This has currently been done solely through Github issues, pull requests, and watching the project). In a way we are limited by the technology of the Apache mailing lists. (I know, I know...). (I mentioned gitlab.com ) The suggestion is that Commons-RDF could be a incubator project, but with a projected path to become part of the Apache Commons instead of a TLP. (I believe this path has not happened before) So this would be using the old structure of having a champion of Apache Commons - could this be a workable incubator project? In a way it would be incubating just the code until API maturity rather than the community or Apache Way as both of those already exist. In such an (old skool) setup, would it be the Commons PMC / dev@commons who would vote over the incubating releases? Once graduating it would just become a component under Apache Commons and the community would just be dev@commons where the committers would already be members - the dev@rdf.incubator list would simply close. .. and where would mentors come from? Would existing committers from those other Apache projects (Jena, Marmotta, Clerezza) be enough - or should it be someone from IMPC or from dev@commons? See http://mail-archives.apache.org/mod_mbox/commons-dev/201501.mbox/%3CCAB917RLJE%2BgFEpw%3Dyp-c-HpXEnvL12JZLLpc4wphGyjGH_6%3D9Q%40mail.gmail.com%3E for the whole threads :) -- Forwarded message -- From: Stian Soiland-Reyes st...@apache.org Date: 20 January 2015 at 14:06 Subject: Re: [DISCUSS][RDF] Separate mailing list for Commons RDF To: Commons Developers List d...@commons.apache.org Agree that maybe the the Incubator with a projected path to the Commons could be a workable middle ground while Commons-RDF is still incubating code-wise (but not community or Apache Way-wise). No earlier project has gone through this route (https://incubator.apache.org/projects/ ) - this would reuse the deprecated Champion project to be Apache Commons instead of Incubator PMC in this case. Such a proposal has some good features - I presume commons-rdf releases would still be voted over (and thus involve) the Commons PMC and dev@commons (as they would after graduating). As an API, then Commons-RDF should not be considered stable while being in 0.x.x-incubating anyway. On 20 January 2015 at 13:58, Torsten Curdt tcu...@vafer.org wrote: There are several ASF projects in the RDF space. They have been through the incubator. Please do talk to those projects if you have concerns. I am sorry - but how are those projects relevant in this case? And what's so bad about the incubator? You could (maybe) later on come to Commons. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Stian Soiland-Reyes Apache Taverna (incubating) http://orcid.org/-0001-9842-9718 -- Stian Soiland-Reyes Apache Taverna (incubating) http://orcid.org/-0001-9842-9718 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Tue, Jan 20, 2015 at 3:35 PM, Alan D. Cabrera l...@toolazydogs.com wrote: ...Isn’t it obvious what the above and IncubatorV2 proposal are about? Consolidating like minded individuals into a new IPMC and shutting out the other inconvenient members until they come to their senses” I don't buy that conspiracy theory, for me it's just very difficult to build consensus in the Incubator as the goal is much fuzzier than producing software. But maybe I'm too candid ;-) -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache AsterixDB Incubator
Should be fine. Regards, Alan On Jan 19, 2015, at 8:27 PM, Till Westmann t...@westmann.org wrote: Thank you. So for we’ve added 3 slots for mentors on the proposal - I hope that’ll be sufficient even for the relatively large number of new committers. Till On Jan 19, 2015, at 8:17 PM, Henry Saputra henry.sapu...@gmail.com wrote: Thanks Till, Will try to solicit more mentors to help. Especially with initial committers mostly have not been exposed to contributing the Apache way. - Henry On Mon, Jan 19, 2015 at 5:28 PM, Till Westmann t...@westmann.org wrote: Hi Henry, thanks! It’s great that you’ve seen (and liked) AsterixDB before. Even if your time is very limited we would be very happy to have you on board as a mentor. I’ll add you to the proposal. Cheers, Till On Jan 19, 2015, at 10:26 AM, Henry Saputra henry.sapu...@gmail.com wrote: +1 This is GREAT News! Was watching and trying AsterixDB last year and looked in awesome shape. I have my plate full but would love to help mentor this project to get it going to ASF if needed! - Henry On Wed, Jan 14, 2015 at 6:21 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: Hi Folks, I am pleased to bring forth the Apache AsterixDB proposal to the Apache Incubator as Champion, working in collaboration with the team. Please find the wiki proposal here: https://wiki.apache.org/incubator/AsterixDBProposal Full text of the proposal is below. Please discuss and enjoy. I’ll leave the discussion open for a week, and then look to call a VOTE hopefully end of next week if all is well. Cheers! Chris Mattmann = Apache AsterixDB Proposal Abstract Apache AsterixDB is a scalable big data management system (BDMS) that provides storage, management, and query capabilities for large collections of semi-structured data. Proposal AsterixDB is a big data management system (BDMS) that makes it well-suited to needs such as web data warehousing and social data storage and analysis. Feature-wise, AsterixDB has: * A NoSQL style data model (ADM) based on extending JSON with object database concepts. * An expressive and declarative query language (AQL) for querying semi-structured data. * A runtime query execution engine, Hyracks, for partitioned-parallel execution of query plans. * Partitioned LSM-based data storage and indexing for efficient ingestion of newly arriving data. * Support for querying and indexing external data (e.g., in HDFS) as well as data stored within AsterixDB. * A rich set of primitive data types, including support for spatial, temporal, and textual data. * Indexing options that include B+ trees, R trees, and inverted keyword index support. * Basic transactional (concurrency and recovery) capabilities akin to those of a NoSQL store. Background and Rationale In the world of relational databases, the need to tackle data volumes that exceed the capabilities of a single server led to the development of “shared-nothing” parallel database systems several decades ago. These systems spread data over a cluster based on a partitioning strategy, such as hash partitioning, and queries are processed by employing partitioned-parallel divide-and-conquer techniques. Since these systems are fronted by a high-level, declarative language (SQL), their users are shielded from the complexities of parallel programming. Parallel database systems have been an extremely successful application of parallel computing, and quite a number of commercial products exist today. In the distributed systems world, the Web brought a need to index and query its huge content. SQL and relational databases were not the answer, though shared-nothing clusters again emerged as the hardware platform of choice. Google developed the Google File System (GFS) and MapReduce programming model to allow programmers to store and process Big Data by writing a few user-defined functions. The MapReduce framework applies these functions in parallel to data instances in distributed files (map) and to sorted groups of instances sharing a common key (reduce) -- not unlike the partitioned parallelism in parallel database systems. Apache's Hadoop MapReduce platform is the most prominent implementation of this paradigm for the rest of the Big Data community. On top of Hadoop and HDFS sit declarative languages like Pig and Hive that each compile down to Hadoop MapReduce jobs. The big Web companies were also challenged by extreme user bases (100s of millions of users) and needed fast simple lookups and updates to very large keyed data sets like user profiles. SQL databases were deemed either too expensive or not scalable, so the “NoSQL movement” was born. The ASF now has HBase and Cassandra, two popular key-value stores, in this space. MongoDB and Couchbase are other open source alternatives (document
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Can you add your concerns to the end each of the wiki pages? I intend to update my proposal to clear up the apprehensions that you seem to have. You can then remove/amend your concerns from the wiki proposal. I will quickly state that “naughty lists” are not part of the mentor-reboot proposal. Thanks! Regards, Alan On Jan 19, 2015, at 3:55 PM, Andrew Purtell apurt...@apache.org wrote: I think the cures are all problematic and might be worse than the disease. On Mon, Jan 19, 2015 at 1:47 PM, Roman Shaposhnik r...@apache.org mailto:r...@apache.org wrote: On Wed, Jan 14, 2015 at 8:48 AM, Roman Shaposhnik r...@apache.org wrote: Hi! at this point we have had a few lively threads discussing three somewhat different proposals: #1 mentor re-boot #2 pTLP #3 Ross's strawman http://s.apache.org/8eS it feels to me that all three need additional work to be done before we can have any reasonable consensus around them (let alone voting). Wearing my chair hat, I would like to suggest that the next step should be: for each proposal we identify points that are going to block consensus (AKA would result in -1 vote if it comes to a vote). I suggest we do it on the wiki pages themselves (I'll wikify Ross's proposal tonight). Not editing the wikis but simply collecting this feedback as the last section in each proposal. The idea would be to identify all such points in a week or so. Sounds good? To follow up. Each of the proposals: https://wiki.apache.org/incubator/MentorRebootProposal An active mentor is removed from a podling if that mentor does not review/sign off on a release. The above implies the foundation has a pool of mentors able to consistently meet every reporting requirement in a timely manner, without regard to personal or professional obstacles. I don't see it. For an organization almost entirely made up of volunteers this seems overly optimistic. There is only a small core membership who are capable and willing to do this as evidenced by a skim of history of general@incubator and members@. Perhaps this core group will end up shouldering the incubation load in its entirety. Although sadly this is more or less the current state of affairs, individual podlings do come with new mentors not part of the professional membership motivated to see at least that specific podling through. It's also risky to expect mentors kicked from a podling to be okay with it and want to try again, especially if listed on some naughty list to the board. https://wiki.apache.org/incubator/Strawman https://wiki.apache.org/incubator/Strawman Only ASF members on the PPMC will have binding votes for the releases. This proposal seems better than the others in my estimation, but doesn't allow podlings full investment in their own release management. The members on the PPMC who have binding votes will drive the release process out of necessity. Once the podling graduates and the members on the PPMC leave to resume other interests or duties, only then for the first time is the project running their own releases. I think it was better to let the podling own their release process but have the IPMC (or equivalent) have an up-or-down vote afterward as a check on their activities. https://wiki.apache.org/incubator/IncubatorV2 https://wiki.apache.org/incubator/IncubatorV2 This proposal revokes merit earned by existing IPMC members and reboots incubator supervision as a sub-board limited to 15 members. How members apply to this board is not specified. It is suggested the current board make recommendations to the board for their replacements, a very unmeritocratic suggestion that is quite surprising. It's not clear at all how the membership can address issues with this sub-board as they can with the Board. I think this proposal takes the likely outcome of the first proposal, that only a small core group of professional membership can manage sufficient activity as mentors to not be kicked from podlings, and codifies it with new structure and bylaws. Maybe in the end this is admitting reality. However, discussion of this proposal also floated the idea that the sub-board be later given authority to supervise the affairs of established TLPs, which is deeply problematic* and I suspect still hovers in the wings. I would hope not. All proposals for new ASF projects must include an initial PMC chair and an initial set of PMC members. These people must be acceptable to the board. It is the responsibility of the Incubator Committee to vett these people. All of them must have experience on existing PMCs This doubles down on the aspect of the Strawman proposal where PPMC members are powerless to vote on releases. Here they are powerless to make any and all project management decisions about their own software they brought to Apache. It's not mentoring if you make all of the decisions for them. * - Find
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Jan 20, 2015, at 6:46 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jan 20, 2015 at 3:35 PM, Alan D. Cabrera l...@toolazydogs.com wrote: ...Isn’t it obvious what the above and IncubatorV2 proposal are about? Consolidating like minded individuals into a new IPMC and shutting out the other inconvenient members until they come to their senses” I don't buy that conspiracy theory, for me it's just very difficult to build consensus in the Incubator as the goal is much fuzzier than producing software. But maybe I'm too candid ;-) I am not espousing a conspiracy theory; there is no secret cabal formed after an ApaceCon pub crawl. I too am being candid. I am merely providing an unvarnished distillation of what the proposals virtually are. Garnering consensus is difficult here, in part because of the fuzziness you mention, but also because members have such different opinions as to what the Incubator function is and what it means to be an Apache project. Under the above proposals, that necessarily messy, frustrating, exhausting, process of garnering consensus on the above thorny issues will not take place as philosophically compatible IPM v2 members turn out Apache projects that fit their view. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
My strawman, which included a board like IPMC, certainly wasn't about shutting out inconvenient IPMC members, that is simply a ridiculous a d insulting suggestion (if it wasn't intended in that way then fine, but it sure sounds like it). My strawman was partly about consensus, but mostly about having a group if people who take individual responsibility for doing the unpopular stuff when the process is failing (which is not the norm). Today it is rare for the IPMC to do that stuff, partly because it is hard to gain consensus, but mostly because it has no teeth (a phrase I used a great deal in explaining my strawman). The goal is for that group to prevent the ongoing centralization of the IPMC and put the authority back where it belongs, with active mentors engaged with the project community. I know some people feel that having a smaller group results in greater centralization, but that depends on who is a part of that group. The *only* goal of my strawman was to give the IPMC accountability and teeth. Sent from my Windows Phone From: Bertrand Delacretazmailto:bdelacre...@apache.org Sent: 1/20/2015 6:46 AM To: Incubator Generalmailto:general@incubator.apache.org Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.) On Tue, Jan 20, 2015 at 3:35 PM, Alan D. Cabrera l...@toolazydogs.com wrote: ...Isn’t it obvious what the above and IncubatorV2 proposal are about? Consolidating like minded individuals into a new IPMC and shutting out the other inconvenient members until they come to their senses” I don't buy that conspiracy theory, for me it's just very difficult to build consensus in the Incubator as the goal is much fuzzier than producing software. But maybe I'm too candid ;-) -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubating with Apache Commons as champion?
I agree that incoming codebase can go through the IP Clearance, and if the committers are already Commons folks (predominantly), and the only actual issue is the number of mails on the dev@, then I think that separate mailing list is fine, perhaps with the exception of not having a name related to the RDF component, perhaps design-in-progress@ or other indicator that a particular activity is happening there. Niclas On Tue, Jan 20, 2015 at 11:08 PM, Rob Vesse rve...@dotnetrdf.org wrote: Stian If a community made predominantly of existing Apache committers (or containing a strong core of) already exists and this would be a small self contained module as part of Apache Commons then why does the Incubator need be involved at all? Why can this not just be submitted directly to Apache Commons via the IP Clearance procedure (http://incubator.apache.org/ip-clearance/index.html)? Commons already allows any ASF committer to commit so the existing community can continue working on the code just fine. The only sticking point would be once Commons-RDF wants to release in which case you'd likely need to canvas the larger commons community for votes until such time as the Commons-RDF committers have earned sufficient merit to be offered PMC membership On the other hand does Commons-RDF necessarily need to come to the ASF at all? If it is a small self-contained interface module that will remain stable what does it gain (other than brand association) by coming to the ASF? Rob On 20/01/2015 14:28, Stian Soiland-Reyes st...@apache.org wrote: The discussion on dev@commons about coming-to-Apache Commons-RDF (https://github.com/commons-rdf/commons-rdf/) seems to be rejecting a temporary mailing list like rdf@commons as it is seen t be splitting Apache Commons as a project - the ideal committer on Apache Commons is caring about all its components (avoiding the Jakarta pitfalls). We had not considered becoming a TLP as once the API (mainly a set of interfaces) is settled, by then it will probably be pretty much a quiet project except the odd maintenance patch - and also by being a common component of several RDF projects within Apache, its best home then would be under Commons (presumably with most of the original committers still involved). However the large traffic of dev@commons (~400/month) about all the other components can be a problem for trying to engage the non-Apache community around commons-rdf while we flesh out the API. (This has currently been done solely through Github issues, pull requests, and watching the project). In a way we are limited by the technology of the Apache mailing lists. (I know, I know...). (I mentioned gitlab.com ) The suggestion is that Commons-RDF could be a incubator project, but with a projected path to become part of the Apache Commons instead of a TLP. (I believe this path has not happened before) So this would be using the old structure of having a champion of Apache Commons - could this be a workable incubator project? In a way it would be incubating just the code until API maturity rather than the community or Apache Way as both of those already exist. In such an (old skool) setup, would it be the Commons PMC / dev@commons who would vote over the incubating releases? Once graduating it would just become a component under Apache Commons and the community would just be dev@commons where the committers would already be members - the dev@rdf.incubator list would simply close. .. and where would mentors come from? Would existing committers from those other Apache projects (Jena, Marmotta, Clerezza) be enough - or should it be someone from IMPC or from dev@commons? See http://mail-archives.apache.org/mod_mbox/commons-dev/201501.mbox/%3CCAB917 RLJE%2BgFEpw%3Dyp-c-HpXEnvL12JZLLpc4wphGyjGH_6%3D9Q%40mail.gmail.com%3E for the whole threads :) -- Forwarded message -- From: Stian Soiland-Reyes st...@apache.org Date: 20 January 2015 at 14:06 Subject: Re: [DISCUSS][RDF] Separate mailing list for Commons RDF To: Commons Developers List d...@commons.apache.org Agree that maybe the the Incubator with a projected path to the Commons could be a workable middle ground while Commons-RDF is still incubating code-wise (but not community or Apache Way-wise). No earlier project has gone through this route (https://incubator.apache.org/projects/ ) - this would reuse the deprecated Champion project to be Apache Commons instead of Incubator PMC in this case. Such a proposal has some good features - I presume commons-rdf releases would still be voted over (and thus involve) the Commons PMC and dev@commons (as they would after graduating). As an API, then Commons-RDF should not be considered stable while being in 0.x.x-incubating anyway. On 20 January 2015 at 13:58, Torsten Curdt tcu...@vafer.org wrote: There are several ASF projects in the RDF space.
RE: When is an ICLA needed?
I agree with Bertrand. Note whoever commits the patch is doing so under their ICLA. In other words if someone feels it does not contain significant IP then they can commit. Paperwork is a barrier to entry which is simply not necessary for trivial contributions. Sent from my Windows Phone From: Bertrand Delacretazmailto:bdelacre...@apache.org Sent: 1/20/2015 3:39 AM To: Incubator Generalmailto:general@incubator.apache.org Subject: Re: When is an ICLA needed? Hi, On Tue, Jan 20, 2015 at 11:57 AM, Rob Vesse rve...@dotnetrdf.org wrote: ...My understanding was always that the ICLA is only required if you are a committer though may still be desirable for larger contributions,... That's my understanding, requiring an iCLA for minor contributions is not needed. What's important for all contributions IMO is to have documented evidence (dev list, jira, bugzilla) that the contribution is voluntary, and to indicate when committing where the contribution comes from. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache AsterixDB Incubator
Excellent; thanks, Jochen!! Cheers, Mike On 1/19/15 11:44 PM, Jochen Wiedmann wrote: Hi, Chris, I am interested in the proposal and (following up to my involvement with VXQuery in the past) would like to offer myself as a mentor. Jochen On Thu, Jan 15, 2015 at 3:21 AM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: Hi Folks, I am pleased to bring forth the Apache AsterixDB proposal to the Apache Incubator as Champion, working in collaboration with the team. Please find the wiki proposal here: https://wiki.apache.org/incubator/AsterixDBProposal Full text of the proposal is below. Please discuss and enjoy. I’ll leave the discussion open for a week, and then look to call a VOTE hopefully end of next week if all is well. Cheers! Chris Mattmann = Apache AsterixDB Proposal Abstract Apache AsterixDB is a scalable big data management system (BDMS) that provides storage, management, and query capabilities for large collections of semi-structured data. Proposal AsterixDB is a big data management system (BDMS) that makes it well-suited to needs such as web data warehousing and social data storage and analysis. Feature-wise, AsterixDB has: * A NoSQL style data model (ADM) based on extending JSON with object database concepts. * An expressive and declarative query language (AQL) for querying semi-structured data. * A runtime query execution engine, Hyracks, for partitioned-parallel execution of query plans. * Partitioned LSM-based data storage and indexing for efficient ingestion of newly arriving data. * Support for querying and indexing external data (e.g., in HDFS) as well as data stored within AsterixDB. * A rich set of primitive data types, including support for spatial, temporal, and textual data. * Indexing options that include B+ trees, R trees, and inverted keyword index support. * Basic transactional (concurrency and recovery) capabilities akin to those of a NoSQL store. Background and Rationale In the world of relational databases, the need to tackle data volumes that exceed the capabilities of a single server led to the development of “shared-nothing” parallel database systems several decades ago. These systems spread data over a cluster based on a partitioning strategy, such as hash partitioning, and queries are processed by employing partitioned-parallel divide-and-conquer techniques. Since these systems are fronted by a high-level, declarative language (SQL), their users are shielded from the complexities of parallel programming. Parallel database systems have been an extremely successful application of parallel computing, and quite a number of commercial products exist today. In the distributed systems world, the Web brought a need to index and query its huge content. SQL and relational databases were not the answer, though shared-nothing clusters again emerged as the hardware platform of choice. Google developed the Google File System (GFS) and MapReduce programming model to allow programmers to store and process Big Data by writing a few user-defined functions. The MapReduce framework applies these functions in parallel to data instances in distributed files (map) and to sorted groups of instances sharing a common key (reduce) -- not unlike the partitioned parallelism in parallel database systems. Apache's Hadoop MapReduce platform is the most prominent implementation of this paradigm for the rest of the Big Data community. On top of Hadoop and HDFS sit declarative languages like Pig and Hive that each compile down to Hadoop MapReduce jobs. The big Web companies were also challenged by extreme user bases (100s of millions of users) and needed fast simple lookups and updates to very large keyed data sets like user profiles. SQL databases were deemed either too expensive or not scalable, so the “NoSQL movement” was born. The ASF now has HBase and Cassandra, two popular key-value stores, in this space. MongoDB and Couchbase are other open source alternatives (document stores). It is evident from the rapidly growing popularity of NoSQL stores, as well as the strong demand for Big Data analytics engines today, that there is a strong (and growing!) need to store, process, *and* query large volumes of semi-structured data in many application areas. Until very recently, developers have had to ``choose'' between using big data analytics engines like Apache Hive or Apache Spark, which can do complex query processing and analysis over HDFS-resident files, and flexible but low-function data stores like MongoDB or Apache HBase. (The Apache Phoenix project, http://phoenix.apache.org/, is a recent SQL-over-HBase effort that aims to bridge between these choices.) AsterixDB is a highly scalable data management system that can store, index, and manage semi-structured data, e.g., much like MongoDB, but it also supports a full-power query language with the expressiveness of SQL (and more). Unlike
Re: Incubating with Apache Commons as champion?
Agreed The point that I was trying to make is that if those involved already understand the Apache Way going through Incubation for the sake of it seems a pointless exercise especially when the legal/IP aspects of things can be handled in other fashions. If you are in a position to simply contribute the code directly to the TLP you expect it to live under and the TLP in question is receptive to that then it is a viable option to consider. I'm not saying that Incubation shouldn't happen but that you should consider if it actually brings the project in question any tangible benefits. There seems to be an assumption that coming through the Incubator is the how you would grow the community but that activity is perfectly capable of happening in the context of a TLP. One of the key activities of the PMC should be to continually try and bring in new members of the community over time so that the project they are charged with managing does not stagnate. It's worth remembering that the Incubator itself does not provide much in the way of help in terms of growing communities since that is something that really only the incubating projects themselves can do. Rob On 20/01/2015 16:04, Stian Soiland-Reyes st...@apache.org wrote: Just because a lot of Apache committers are involved and could put things right into another project (or even propose a new TLP directly) doesn't mean it happens. https://wiki.apache.org/incubator/BeanShellProposal was voted -1 in the incubator because it had many Apache folks already and didn't need to learn anything. Yet the project didn't move into Apache - perhaps because it didn't have any pressure or framework to go through the Incubator process? (It now lives semi-dormantly as an Apache Extras thing at https://code.google.com/a/apache-extras.org/p/beanshell/ - I joined recently and it is slowly awakening :) ) I think the incubator should be open also for a group of experienced Apache folks - although their needs would be different, e.g. more of a focus on the project goals and growing their community, and not so much worry about IP issues, licenses and build/release procedures. On 20 January 2015 at 15:08, Rob Vesse rve...@dotnetrdf.org wrote: Stian If a community made predominantly of existing Apache committers (or containing a strong core of) already exists and this would be a small self contained module as part of Apache Commons then why does the Incubator need be involved at all? Why can this not just be submitted directly to Apache Commons via the IP Clearance procedure (http://incubator.apache.org/ip-clearance/index.html)? Commons already allows any ASF committer to commit so the existing community can continue working on the code just fine. The only sticking point would be once Commons-RDF wants to release in which case you'd likely need to canvas the larger commons community for votes until such time as the Commons-RDF committers have earned sufficient merit to be offered PMC membership On the other hand does Commons-RDF necessarily need to come to the ASF at all? If it is a small self-contained interface module that will remain stable what does it gain (other than brand association) by coming to the ASF? Rob On 20/01/2015 14:28, Stian Soiland-Reyes st...@apache.org wrote: The discussion on dev@commons about coming-to-Apache Commons-RDF (https://github.com/commons-rdf/commons-rdf/) seems to be rejecting a temporary mailing list like rdf@commons as it is seen t be splitting Apache Commons as a project - the ideal committer on Apache Commons is caring about all its components (avoiding the Jakarta pitfalls). We had not considered becoming a TLP as once the API (mainly a set of interfaces) is settled, by then it will probably be pretty much a quiet project except the odd maintenance patch - and also by being a common component of several RDF projects within Apache, its best home then would be under Commons (presumably with most of the original committers still involved). However the large traffic of dev@commons (~400/month) about all the other components can be a problem for trying to engage the non-Apache community around commons-rdf while we flesh out the API. (This has currently been done solely through Github issues, pull requests, and watching the project). In a way we are limited by the technology of the Apache mailing lists. (I know, I know...). (I mentioned gitlab.com ) The suggestion is that Commons-RDF could be a incubator project, but with a projected path to become part of the Apache Commons instead of a TLP. (I believe this path has not happened before) So this would be using the old structure of having a champion of Apache Commons - could this be a workable incubator project? In a way it would be incubating just the code until API maturity rather than the community or Apache Way as both of those already exist. In such an (old skool) setup, would it be the Commons PMC / dev@commons who would vote over the
RE: Incubating with Apache Commons as champion?
It's not for the IPMC to decide commons policy. If they feel another mailing list is not appropriate that is their call. Sent from my Windows Phone From: Niclas Hedhmanmailto:nic...@hedhman.org Sent: 1/20/2015 8:07 AM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Incubating with Apache Commons as champion? I agree that incoming codebase can go through the IP Clearance, and if the committers are already Commons folks (predominantly), and the only actual issue is the number of mails on the dev@, then I think that separate mailing list is fine, perhaps with the exception of not having a name related to the RDF component, perhaps design-in-progress@ or other indicator that a particular activity is happening there. Niclas On Tue, Jan 20, 2015 at 11:08 PM, Rob Vesse rve...@dotnetrdf.org wrote: Stian If a community made predominantly of existing Apache committers (or containing a strong core of) already exists and this would be a small self contained module as part of Apache Commons then why does the Incubator need be involved at all? Why can this not just be submitted directly to Apache Commons via the IP Clearance procedure (http://incubator.apache.org/ip-clearance/index.html)? Commons already allows any ASF committer to commit so the existing community can continue working on the code just fine. The only sticking point would be once Commons-RDF wants to release in which case you'd likely need to canvas the larger commons community for votes until such time as the Commons-RDF committers have earned sufficient merit to be offered PMC membership On the other hand does Commons-RDF necessarily need to come to the ASF at all? If it is a small self-contained interface module that will remain stable what does it gain (other than brand association) by coming to the ASF? Rob On 20/01/2015 14:28, Stian Soiland-Reyes st...@apache.org wrote: The discussion on dev@commons about coming-to-Apache Commons-RDF (https://github.com/commons-rdf/commons-rdf/) seems to be rejecting a temporary mailing list like rdf@commons as it is seen t be splitting Apache Commons as a project - the ideal committer on Apache Commons is caring about all its components (avoiding the Jakarta pitfalls). We had not considered becoming a TLP as once the API (mainly a set of interfaces) is settled, by then it will probably be pretty much a quiet project except the odd maintenance patch - and also by being a common component of several RDF projects within Apache, its best home then would be under Commons (presumably with most of the original committers still involved). However the large traffic of dev@commons (~400/month) about all the other components can be a problem for trying to engage the non-Apache community around commons-rdf while we flesh out the API. (This has currently been done solely through Github issues, pull requests, and watching the project). In a way we are limited by the technology of the Apache mailing lists. (I know, I know...). (I mentioned gitlab.com ) The suggestion is that Commons-RDF could be a incubator project, but with a projected path to become part of the Apache Commons instead of a TLP. (I believe this path has not happened before) So this would be using the old structure of having a champion of Apache Commons - could this be a workable incubator project? In a way it would be incubating just the code until API maturity rather than the community or Apache Way as both of those already exist. In such an (old skool) setup, would it be the Commons PMC / dev@commons who would vote over the incubating releases? Once graduating it would just become a component under Apache Commons and the community would just be dev@commons where the committers would already be members - the dev@rdf.incubator list would simply close. .. and where would mentors come from? Would existing committers from those other Apache projects (Jena, Marmotta, Clerezza) be enough - or should it be someone from IMPC or from dev@commons? See http://mail-archives.apache.org/mod_mbox/commons-dev/201501.mbox/%3CCAB917 RLJE%2BgFEpw%3Dyp-c-HpXEnvL12JZLLpc4wphGyjGH_6%3D9Q%40mail.gmail.com%3E for the whole threads :) -- Forwarded message -- From: Stian Soiland-Reyes st...@apache.org Date: 20 January 2015 at 14:06 Subject: Re: [DISCUSS][RDF] Separate mailing list for Commons RDF To: Commons Developers List d...@commons.apache.org Agree that maybe the the Incubator with a projected path to the Commons could be a workable middle ground while Commons-RDF is still incubating code-wise (but not community or Apache Way-wise). No earlier project has gone through this route (https://incubator.apache.org/projects/ ) - this would reuse the deprecated Champion project to be Apache Commons instead of Incubator PMC in this case. Such a proposal has some good
Re: Incubating with Apache Commons as champion?
On 20/01/15 16:08, Rob Vesse wrote: On the other hand does Commons-RDF necessarily need to come to the ASF at all? If it is a small self-contained interface module that will remain stable what does it gain (other than brand association) by coming to the ASF? Well, this question eventually came across because a collision with another project proposed to Apache Commons Sandbox, issue extensively discuss at GitHub: https://github.com/commons-rdf/commons-rdf/issues/43 and it's what created all these discussion. In case we propose Commons RDF for incubation, the background will be properly discussed in the proposal. -- Sergio Fernández Senior Researcher Knowledge and Media Technologies Salzburg Research Forschungsgesellschaft mbH Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria T: +43 662 2288 318 | M: +43 660 2747 925 sergio.fernan...@salzburgresearch.at http://www.salzburgresearch.at - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Tue, Jan 20, 2015 at 4:39 PM, Alan Cabrera l...@toolazydogs.com wrote: ...Under the above proposals, that necessarily messy, frustrating, exhausting, process of garnering consensus on the above thorny issues will not take place as philosophically compatible IPM v2 members turn out Apache projects that fit their view Ok, I see your point now. Another reason for fixing things that need to fix instead of blowing up the whole thing just to see if it lands in a better shape. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubating with Apache Commons as champion?
Just because a lot of Apache committers are involved and could put things right into another project (or even propose a new TLP directly) doesn't mean it happens. https://wiki.apache.org/incubator/BeanShellProposal was voted -1 in the incubator because it had many Apache folks already and didn't need to learn anything. Yet the project didn't move into Apache - perhaps because it didn't have any pressure or framework to go through the Incubator process? (It now lives semi-dormantly as an Apache Extras thing at https://code.google.com/a/apache-extras.org/p/beanshell/ - I joined recently and it is slowly awakening :) ) I think the incubator should be open also for a group of experienced Apache folks - although their needs would be different, e.g. more of a focus on the project goals and growing their community, and not so much worry about IP issues, licenses and build/release procedures. On 20 January 2015 at 15:08, Rob Vesse rve...@dotnetrdf.org wrote: Stian If a community made predominantly of existing Apache committers (or containing a strong core of) already exists and this would be a small self contained module as part of Apache Commons then why does the Incubator need be involved at all? Why can this not just be submitted directly to Apache Commons via the IP Clearance procedure (http://incubator.apache.org/ip-clearance/index.html)? Commons already allows any ASF committer to commit so the existing community can continue working on the code just fine. The only sticking point would be once Commons-RDF wants to release in which case you'd likely need to canvas the larger commons community for votes until such time as the Commons-RDF committers have earned sufficient merit to be offered PMC membership On the other hand does Commons-RDF necessarily need to come to the ASF at all? If it is a small self-contained interface module that will remain stable what does it gain (other than brand association) by coming to the ASF? Rob On 20/01/2015 14:28, Stian Soiland-Reyes st...@apache.org wrote: The discussion on dev@commons about coming-to-Apache Commons-RDF (https://github.com/commons-rdf/commons-rdf/) seems to be rejecting a temporary mailing list like rdf@commons as it is seen t be splitting Apache Commons as a project - the ideal committer on Apache Commons is caring about all its components (avoiding the Jakarta pitfalls). We had not considered becoming a TLP as once the API (mainly a set of interfaces) is settled, by then it will probably be pretty much a quiet project except the odd maintenance patch - and also by being a common component of several RDF projects within Apache, its best home then would be under Commons (presumably with most of the original committers still involved). However the large traffic of dev@commons (~400/month) about all the other components can be a problem for trying to engage the non-Apache community around commons-rdf while we flesh out the API. (This has currently been done solely through Github issues, pull requests, and watching the project). In a way we are limited by the technology of the Apache mailing lists. (I know, I know...). (I mentioned gitlab.com ) The suggestion is that Commons-RDF could be a incubator project, but with a projected path to become part of the Apache Commons instead of a TLP. (I believe this path has not happened before) So this would be using the old structure of having a champion of Apache Commons - could this be a workable incubator project? In a way it would be incubating just the code until API maturity rather than the community or Apache Way as both of those already exist. In such an (old skool) setup, would it be the Commons PMC / dev@commons who would vote over the incubating releases? Once graduating it would just become a component under Apache Commons and the community would just be dev@commons where the committers would already be members - the dev@rdf.incubator list would simply close. .. and where would mentors come from? Would existing committers from those other Apache projects (Jena, Marmotta, Clerezza) be enough - or should it be someone from IMPC or from dev@commons? See http://mail-archives.apache.org/mod_mbox/commons-dev/201501.mbox/%3CCAB917 RLJE%2BgFEpw%3Dyp-c-HpXEnvL12JZLLpc4wphGyjGH_6%3D9Q%40mail.gmail.com%3E for the whole threads :) -- Forwarded message -- From: Stian Soiland-Reyes st...@apache.org Date: 20 January 2015 at 14:06 Subject: Re: [DISCUSS][RDF] Separate mailing list for Commons RDF To: Commons Developers List d...@commons.apache.org Agree that maybe the the Incubator with a projected path to the Commons could be a workable middle ground while Commons-RDF is still incubating code-wise (but not community or Apache Way-wise). No earlier project has gone through this route (https://incubator.apache.org/projects/ ) - this would reuse the deprecated Champion project to be Apache Commons instead of Incubator PMC in this case. Such a proposal has
RE: Incubating with Apache Commons as champion?
I hear what Stian is saying about the noise in Commons. If the team feel its not going to work for them then the incubator might be the right route. IMHO there is no reason why you couldn't be sponsored by the commons PMC. You would still need the IPMC to clear releases but that means three IPMC +1 votes. I'm not sure when this became a requirement for an IPMC vote. It used to be that the IPMC was notified. I always ensured that the mentors all voted first (incidentally this is a good check point to see if mentors are still active). ASIDE: I strongly recommend a return to the original notification of a VOTE in progress. This is another example of unnecessary centralization of process in the IPMC. Control should be with the podlings and its mentors, oversight should be with the PMC. If anyone wants to respond to this make it a new thread please. Let's not distract from this conversation. I see no reason why your project can't come here, and can graduate to commons if that is what is desired. Ensure you have enough mentors (must be IPMC members, which means ASF members although I can think of a few people on RDF projects I would be happy to vote onto the IPMC if necessary) to get 3 +1 release votes and ensure they are strong enough to tell the IPMC to get out of the way (when appropriate). Ross Sent from my Windows Phone From: Rob Vessemailto:rve...@dotnetrdf.org Sent: 1/20/2015 7:10 AM To: general@incubator.apache.orgmailto:general@incubator.apache.org Subject: Re: Incubating with Apache Commons as champion? Stian If a community made predominantly of existing Apache committers (or containing a strong core of) already exists and this would be a small self contained module as part of Apache Commons then why does the Incubator need be involved at all? Why can this not just be submitted directly to Apache Commons via the IP Clearance procedure (http://incubator.apache.org/ip-clearance/index.html)? Commons already allows any ASF committer to commit so the existing community can continue working on the code just fine. The only sticking point would be once Commons-RDF wants to release in which case you'd likely need to canvas the larger commons community for votes until such time as the Commons-RDF committers have earned sufficient merit to be offered PMC membership On the other hand does Commons-RDF necessarily need to come to the ASF at all? If it is a small self-contained interface module that will remain stable what does it gain (other than brand association) by coming to the ASF? Rob On 20/01/2015 14:28, Stian Soiland-Reyes st...@apache.org wrote: The discussion on dev@commons about coming-to-Apache Commons-RDF (https://github.com/commons-rdf/commons-rdf/) seems to be rejecting a temporary mailing list like rdf@commons as it is seen t be splitting Apache Commons as a project - the ideal committer on Apache Commons is caring about all its components (avoiding the Jakarta pitfalls). We had not considered becoming a TLP as once the API (mainly a set of interfaces) is settled, by then it will probably be pretty much a quiet project except the odd maintenance patch - and also by being a common component of several RDF projects within Apache, its best home then would be under Commons (presumably with most of the original committers still involved). However the large traffic of dev@commons (~400/month) about all the other components can be a problem for trying to engage the non-Apache community around commons-rdf while we flesh out the API. (This has currently been done solely through Github issues, pull requests, and watching the project). In a way we are limited by the technology of the Apache mailing lists. (I know, I know...). (I mentioned gitlab.com ) The suggestion is that Commons-RDF could be a incubator project, but with a projected path to become part of the Apache Commons instead of a TLP. (I believe this path has not happened before) So this would be using the old structure of having a champion of Apache Commons - could this be a workable incubator project? In a way it would be incubating just the code until API maturity rather than the community or Apache Way as both of those already exist. In such an (old skool) setup, would it be the Commons PMC / dev@commons who would vote over the incubating releases? Once graduating it would just become a component under Apache Commons and the community would just be dev@commons where the committers would already be members - the dev@rdf.incubator list would simply close. .. and where would mentors come from? Would existing committers from those other Apache projects (Jena, Marmotta, Clerezza) be enough - or should it be someone from IMPC or from dev@commons? See http://mail-archives.apache.org/mod_mbox/commons-dev/201501.mbox/%3CCAB917 RLJE%2BgFEpw%3Dyp-c-HpXEnvL12JZLLpc4wphGyjGH_6%3D9Q%40mail.gmail.com%3E for the whole threads :) -- Forwarded message -- From:
Re: When is an ICLA needed?
On 20.01.2015 17:16, Ross Gardler (MS OPEN TECH) wrote: I agree with Bertrand. Note whoever commits the patch is doing so under their ICLA. Really? That can't be right: one can't become the author of a change (and therefore can't license it to the ASF) merely by having committed it. That's why we require an audit trail to the original author, right? In other words if someone feels it does not contain significant IP then they can commit. Paperwork is a barrier to entry which is simply not necessary for trivial contributions. That's a different matter, and I agree. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: When is an ICLA needed?
On Tue Jan 20 2015 at 1:54:32 PM Benson Margulies bimargul...@gmail.com wrote: On Tue, Jan 20, 2015 at 1:40 PM, Branko Čibej br...@apache.org wrote: On 20.01.2015 17:16, Ross Gardler (MS OPEN TECH) wrote: I agree with Bertrand. Note whoever commits the patch is doing so under their ICLA. Really? That can't be right: one can't become the author of a change (and therefore can't license it to the ASF) merely by having committed it. That's why we require an audit trail to the original author, right? It has to be 'right', but you're reading too much into Ross' remark. When you signed the ICLA, you agreed to abide by its terms. That doesn't make you the author of everything you commit. No, but it makes it odd when you start merging github pull requests. The original author is the one shown. John In other words if someone feels it does not contain significant IP then they can commit. Paperwork is a barrier to entry which is simply not necessary for trivial contributions. That's a different matter, and I agree. -- Brane - 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: When is an ICLA needed?
On Tue, Jan 20, 2015 at 1:40 PM, Branko Čibej br...@apache.org wrote: On 20.01.2015 17:16, Ross Gardler (MS OPEN TECH) wrote: I agree with Bertrand. Note whoever commits the patch is doing so under their ICLA. Really? That can't be right: one can't become the author of a change (and therefore can't license it to the ASF) merely by having committed it. That's why we require an audit trail to the original author, right? It has to be 'right', but you're reading too much into Ross' remark. When you signed the ICLA, you agreed to abide by its terms. That doesn't make you the author of everything you commit. In other words if someone feels it does not contain significant IP then they can commit. Paperwork is a barrier to entry which is simply not necessary for trivial contributions. That's a different matter, and I agree. -- Brane - 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
Is there a place I can programmatically pull in PPMC members?
Is there a place I can programmatically pull in PPMC members? Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubating with Apache Commons as champion?
On 20/01/15 15:28, Stian Soiland-Reyes wrote: The suggestion is that Commons-RDF could be a incubator project, but with a projected path to become part of the Apache Commons instead of a TLP. (I believe this path has not happened before) It did happened before: http://markmail.org/search/?q=list%3Aorg.apache.incubator.general+vote+graduate+subproject+commons -- Sergio Fernández Senior Researcher Knowledge and Media Technologies Salzburg Research Forschungsgesellschaft mbH Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria T: +43 662 2288 318 | M: +43 660 2747 925 sergio.fernan...@salzburgresearch.at http://www.salzburgresearch.at - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: When is an ICLA needed?
Benson is correct: Section 4 of the ICLA states You represent that you are legally entitled to grant the above license. It doesn't say you own copyright, only that you have the permission to grant the license on the copyrighted material (which the copyright owners indicates by making the patch available in JIRA, the pull request on GitHub or whatever process the project uses). As for the original author being shown that is culturally important (merit) and legally important (traceability). The committer is also recorded. Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: John D. Ament [mailto:johndam...@apache.org] Sent: Tuesday, January 20, 2015 10:56 AM To: general@incubator.apache.org Subject: Re: When is an ICLA needed? On Tue Jan 20 2015 at 1:54:32 PM Benson Margulies bimargul...@gmail.com wrote: On Tue, Jan 20, 2015 at 1:40 PM, Branko Čibej br...@apache.org wrote: On 20.01.2015 17:16, Ross Gardler (MS OPEN TECH) wrote: I agree with Bertrand. Note whoever commits the patch is doing so under their ICLA. Really? That can't be right: one can't become the author of a change (and therefore can't license it to the ASF) merely by having committed it. That's why we require an audit trail to the original author, right? It has to be 'right', but you're reading too much into Ross' remark. When you signed the ICLA, you agreed to abide by its terms. That doesn't make you the author of everything you commit. No, but it makes it odd when you start merging github pull requests. The original author is the one shown. John In other words if someone feels it does not contain significant IP then they can commit. Paperwork is a barrier to entry which is simply not necessary for trivial contributions. That's a different matter, and I agree. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache htrace-3.1.0-incubating
+1 binding On Sat, Jan 17, 2015 at 10:36 PM, Stack st...@duboce.net wrote: Apache HTrace (incubating), after ten release candidates, has voted to release the below referenced Apache HTrace 3.1.0-incubating release candidate. Dear IPMC, please vote on our first release candidate as an Apache Incubator project. Here is the vote thread we ran on our dev list (Six binding +1 votes and no dissent) with a subject: [VOTE] htrace-3.1.0, the this is it for sure!, tenth release candidate * http://mail-archives.apache.org/mod_mbox/incubator-htrace-dev/201501.mbox/%3CCADcMMgF_agDCzcwsxpdGsJOzCQ1ebA5z7hsM_-oFbneAVzh4dg%40mail.gmail.com%3E http://mail-archives.apache.org/mod_mbox/incubator-htrace-dev/201501.mbox/%3CCADcMMgF_agDCzcwsxpdGsJOzCQ1ebA5z7hsM_-oFbneAVzh4dg%40mail.gmail.com%3E * The source tarball, hashes, and signing are here: http://people.apache.org/~stack/htrace-3.1.0-incubatingRC9/ (Over in htrace our RC number was zero based so RC9 == tenth RC) Related maven artifacts are posted here: https://repository.apache.org/content/repositories/orgapachehtrace-1014 The tag for the RC is here: https://git-wip-us.apache.org/repos/asf?p=incubator-htrace.git;a=commit;h=0cabe569bc05a58c7a319a460eed5e50e136bae7 The KEYS file with the key used signing is available here: *https://dist.apache.org/repos/dist/release/incubator/htrace/KEYS https://dist.apache.org/repos/dist/release/incubator/htrace/KEYS* 44 issues were closed/resolved for this release: https://issues.apache.org/jira/issues/?jql=project%20%3D%20HTRACE%20AND%20status%20%3D%20resolved%20AND%20fixVersion%20%3D%203.1.0%20ORDER%20BY%20issuetype%20DESC The vote will be open for 72 hours. [ ] +1 Release this package as Apache HTrace 3.1.0-incubating [ ] +0 no opinion [ ] -1 Do not release this package because ... Thanks, St.Ack
Re: [VOTE] Release Apache htrace-3.1.0-incubating
WIth 3+1 (binding), a dodgy binding +1 vote (mine), and a non-binding +1, the vote passes. Thank you to all who voted. Let me push out our first release out of incubator. Thanks, St.Ack On Tue, Jan 20, 2015 at 12:14 PM, Billie Rinaldi bil...@apache.org wrote: +1 binding On Sat, Jan 17, 2015 at 10:36 PM, Stack st...@duboce.net wrote: Apache HTrace (incubating), after ten release candidates, has voted to release the below referenced Apache HTrace 3.1.0-incubating release candidate. Dear IPMC, please vote on our first release candidate as an Apache Incubator project. Here is the vote thread we ran on our dev list (Six binding +1 votes and no dissent) with a subject: [VOTE] htrace-3.1.0, the this is it for sure!, tenth release candidate * http://mail-archives.apache.org/mod_mbox/incubator-htrace-dev/201501.mbox/%3CCADcMMgF_agDCzcwsxpdGsJOzCQ1ebA5z7hsM_-oFbneAVzh4dg%40mail.gmail.com%3E http://mail-archives.apache.org/mod_mbox/incubator-htrace-dev/201501.mbox/%3CCADcMMgF_agDCzcwsxpdGsJOzCQ1ebA5z7hsM_-oFbneAVzh4dg%40mail.gmail.com%3E * The source tarball, hashes, and signing are here: http://people.apache.org/~stack/htrace-3.1.0-incubatingRC9/ (Over in htrace our RC number was zero based so RC9 == tenth RC) Related maven artifacts are posted here: https://repository.apache.org/content/repositories/orgapachehtrace-1014 The tag for the RC is here: https://git-wip-us.apache.org/repos/asf?p=incubator-htrace.git;a=commit;h=0cabe569bc05a58c7a319a460eed5e50e136bae7 The KEYS file with the key used signing is available here: *https://dist.apache.org/repos/dist/release/incubator/htrace/KEYS https://dist.apache.org/repos/dist/release/incubator/htrace/KEYS* 44 issues were closed/resolved for this release: https://issues.apache.org/jira/issues/?jql=project%20%3D%20HTRACE%20AND%20status%20%3D%20resolved%20AND%20fixVersion%20%3D%203.1.0%20ORDER%20BY%20issuetype%20DESC The vote will be open for 72 hours. [ ] +1 Release this package as Apache HTrace 3.1.0-incubating [ ] +0 no opinion [ ] -1 Do not release this package because ... Thanks, St.Ack
Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Mon, Jan 19, 2015 at 11:57 PM, Bertrand Delacretaz bdelacre...@apache.org javascript:; wrote: How is that different from pruning the current IPMC membership by removing inactive members? Doing *that* would be straightforward. Take the set of mentors on currently incubating projects, add the other half dozen who review releases, and set everyone else to voluntary emeritus status. Done. The only thing people are taking from this discussion is offense. Allusions to problematic people or patterns- presented with too few details to refute- are coy nonsense. Contact the person(s) directly, raise it on private@ and fix it, or swallow your indignation and live with it. If some group thinks they're held back by the current project and they want to try something radically new, they should JFDI already and stop twisting in the wind. -C
Re: [PROPOSAL] Apache AsterixDB Incubator
Added my name to the mentor list. On Tue, Jan 20, 2015 at 8:37 AM, Mike Carey dtab...@gmail.com wrote: Wonderful; thanks, Ted!! Cheers, Mike On 1/19/15 11:29 PM, Ted Dunning wrote: Chris just asked me under separate cover. I am happy to help out as mentor. On Mon, Jan 19, 2015 at 8:17 PM, Henry Saputra henry.sapu...@gmail.com wrote: Thanks Till, Will try to solicit more mentors to help. Especially with initial committers mostly have not been exposed to contributing the Apache way. - Henry On Mon, Jan 19, 2015 at 5:28 PM, Till Westmann t...@westmann.org wrote: Hi Henry, thanks! It’s great that you’ve seen (and liked) AsterixDB before. Even if your time is very limited we would be very happy to have you on board as a mentor. I’ll add you to the proposal. Cheers, Till On Jan 19, 2015, at 10:26 AM, Henry Saputra henry.sapu...@gmail.com wrote: +1 This is GREAT News! Was watching and trying AsterixDB last year and looked in awesome shape. I have my plate full but would love to help mentor this project to get it going to ASF if needed! - Henry On Wed, Jan 14, 2015 at 6:21 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: Hi Folks, I am pleased to bring forth the Apache AsterixDB proposal to the Apache Incubator as Champion, working in collaboration with the team. Please find the wiki proposal here: https://wiki.apache.org/incubator/AsterixDBProposal Full text of the proposal is below. Please discuss and enjoy. I’ll leave the discussion open for a week, and then look to call a VOTE hopefully end of next week if all is well. Cheers! Chris Mattmann = Apache AsterixDB Proposal Abstract Apache AsterixDB is a scalable big data management system (BDMS) that provides storage, management, and query capabilities for large collections of semi-structured data. Proposal AsterixDB is a big data management system (BDMS) that makes it well-suited to needs such as web data warehousing and social data storage and analysis. Feature-wise, AsterixDB has: * A NoSQL style data model (ADM) based on extending JSON with object database concepts. * An expressive and declarative query language (AQL) for querying semi-structured data. * A runtime query execution engine, Hyracks, for partitioned-parallel execution of query plans. * Partitioned LSM-based data storage and indexing for efficient ingestion of newly arriving data. * Support for querying and indexing external data (e.g., in HDFS) as well as data stored within AsterixDB. * A rich set of primitive data types, including support for spatial, temporal, and textual data. * Indexing options that include B+ trees, R trees, and inverted keyword index support. * Basic transactional (concurrency and recovery) capabilities akin to those of a NoSQL store. Background and Rationale In the world of relational databases, the need to tackle data volumes that exceed the capabilities of a single server led to the development of “shared-nothing” parallel database systems several decades ago. These systems spread data over a cluster based on a partitioning strategy, such as hash partitioning, and queries are processed by employing partitioned-parallel divide-and-conquer techniques. Since these systems are fronted by a high-level, declarative language (SQL), their users are shielded from the complexities of parallel programming. Parallel database systems have been an extremely successful application of parallel computing, and quite a number of commercial products exist today. In the distributed systems world, the Web brought a need to index and query its huge content. SQL and relational databases were not the answer, though shared-nothing clusters again emerged as the hardware platform of choice. Google developed the Google File System (GFS) and MapReduce programming model to allow programmers to store and process Big Data by writing a few user-defined functions. The MapReduce framework applies these functions in parallel to data instances in distributed files (map) and to sorted groups of instances sharing a common key (reduce) -- not unlike the partitioned parallelism in parallel database systems. Apache's Hadoop MapReduce platform is the most prominent implementation of this paradigm for the rest of the Big Data community. On top of Hadoop and HDFS sit declarative languages like Pig and Hive that each compile down to Hadoop MapReduce jobs. The big Web companies were also challenged by extreme user bases (100s of millions of users) and needed fast simple lookups and updates to very large keyed data sets like user profiles. SQL databases were deemed either too expensive or not scalable, so the “NoSQL movement” was born. The ASF now has HBase and Cassandra, two popular
RE: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator
+1 Hal -Original Message- From: Hal Lockhart Sent: Monday, January 05, 2015 1:16 PM To: general@incubator.apache.org Subject: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator I call a vote to accept OpenAz as a new Incubator project. The proposal can be found here: https://wiki.apache.org/incubator/OpenAZProposal and is included below in this email. Voting will remain open until at least January 20, 2015 23:00 ET. Hal Lockhart --- Abstract OpenAz is a project to create tools and libraries to enable the development of Attribute-based Access Control (ABAC) Systems in a variety of languages. In general the work is at least consistent with or actually conformant to the OASIS XACML Standard. Proposal Generally the work falls into two categories: ready to use tools which implement standardized or well understood components of an ABAC system and design proposals and proof of concept code relating to less well understood or experimental aspects of the problem. Much of the work to date has revolved around defining interfaces enabling a PEP to request an access control decision from a PDP. The XACML standard defines an abstract request format in xml and protocol wire formats in xaml and json, but it does not specify programmatic interfaces in any language. The standard says that the use of XML (or JSON) is not required only the semantic equivalent. The first Interface, AzAPI is modeled closely on the XACML defined interface, expressed in Java. One of the goals was to support calls to both a PDP local to the same process and a PDP in a remote server. AzAPI includes the interface, reference code to handle things like the many supported datatypes in XACML and glue code to mate it to the open source Sun XACML implementation. Because of the dependence on Sun XACML (which is XACML 2.0) the interface was missing some XACML 3.0 features. More recently this was corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was done by the JPMC team to support calling a remote PDP. WSo2 is also pursuing this capability. A second, higher level interface, PEPAPI was also defined. PEPAPI is more intended for application developers with little knowledge of XACML. It allows Java objects which contain attribute information to be passed in. Conversion methods, called mappers extract information from the objects and present it in the format expected by XACML. Some implementers have chosen to implement PEPAPI directly against their PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface which closely matches the Java one. Examples of more speculative work include: proposals for registration and dispatch of Obligation and Advice handlers, a scheme called AMF to tell PIPs how to retrieve attributes and PIP code to implement it, discussion of PoC code to demonstrate the use of XACML policies to drive OAuth interations and a proposal to use XACML policies to express OAuth scope. ATT has recently contributed their extensive XACML framework to the project. The ATT framework represents the entire XACML 3.0 object set as a collection of Java interfaces and standard implementations of those interfaces. The ATT PDP engine is built on top of this framework and represents a complete implementation of a XACML 3.0 PDP, including all of the multi-decision profiles. In addition, the framework also contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and XACML JSON Profile v1.0 WD 14. The PEP API includes annotation functionality, allowing application developers to simply annotate a Java class to provide attributes for a request. The annotation support removes the need for application developers to learn much of the API. The ATT framework also includes interfaces and implementations to standardize development of PIP engines that are used by the ATT PDP implementation, and can be used by other implementations built on top of the ATT framework. The framework also includes interfaces and implementations for a PAP distributed cloud infrastructure of PDP nodes that includes support for policy distribution and pip configurations. This PAP infrastructure includes a web application administrative console that contains a XACML 3.0 policy editor, attribute dictionary support, and management of PDP RESTful node instances. In addition, there are tools available for policy simulation. Background Access Control is in some ways the most basic IT Security service. It consists of making a decision about whether a particular request should be allowed and enforcing that decision. Aside from schemes like permission bits and Access Control Lists (ACLs) the most common way access control is implemented is as code in a server or application which typically intertwines access control logic with
Re: Is there a place I can programmatically pull in PPMC members?
This seems to get me the IPMC members, not the PPMC members of podlings. Am I misinterpreting the page? Regards, Alan On Jan 20, 2015, at 11:04 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: See the code behind Whimsy (https://whimsy.apache.org/technology.html) The part you looking for produces https://whimsy.apache.org/roster/committee/incubator Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Alan D. Cabrera [mailto:l...@toolazydogs.com] Sent: Tuesday, January 20, 2015 10:58 AM To: infrastructure-...@apache.org; general@incubator.apache.org Subject: Is there a place I can programmatically pull in PPMC members? Is there a place I can programmatically pull in PPMC members? Regards, Alan - 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: Incubating with Apache Commons as champion?
Stian Soiland-Reyes wrote: https://wiki.apache.org/incubator/BeanShellProposal was voted -1 in the incubator because it had many Apache folks already and didn't need to learn anything. Yet the project didn't move into Apache - perhaps because it didn't have any pressure or framework to go through the Incubator process? BeanShell got stuck because nobody had enough time and energy to invest on it after questions had been asked. A new release of BeanShell (for a generic use of the term, not an Apache Release) was uploaded in the tarball repository of OpenOffice dependencies and that's it. The reason is simply that people involved preferred to spend their time and energy in other ways. Regards, Andrea. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
As an IPMC member I have objected to this part of the report. As a Director I have already commented on the report that this practice is inappropriate. I will ask for that section to be struck from the minutes, we'll see if other directors agree. My comment on the report is: rg: I've already made the point on the incubator list but I do not see benefit in highlighting mentors who have not signed-off. It means very little in isolation (a busy volunteer who didn't have the time to tick a box on a wiki is not necessarily an absent mentor from the project community). Given these records are public I would prefer not to see this data in the minutes. Ross -Original Message- From: Andrew Purtell [mailto:apurt...@apache.org] Sent: Tuesday, January 20, 2015 11:18 AM To: general@incubator.apache.org Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.) I just experienced being placed on a naughty list in the last incubator report because I was travelling for business and missed checking the box for HTrace. It may not be on any specific proposal. It seems to already be in practice. On Tue, Jan 20, 2015 at 6:36 AM, Alan D. Cabrera l...@toolazydogs.com wrote: Can you add your concerns to the end each of the wiki pages? I intend to update my proposal to clear up the apprehensions that you seem to have. You can then remove/amend your concerns from the wiki proposal. I will quickly state that “naughty lists” are not part of the mentor-reboot proposal. Thanks! Regards, Alan On Jan 19, 2015, at 3:55 PM, Andrew Purtell apurt...@apache.org wrote: I think the cures are all problematic and might be worse than the disease. On Mon, Jan 19, 2015 at 1:47 PM, Roman Shaposhnik r...@apache.org mailto:r...@apache.org wrote: On Wed, Jan 14, 2015 at 8:48 AM, Roman Shaposhnik r...@apache.org wrote: Hi! at this point we have had a few lively threads discussing three somewhat different proposals: #1 mentor re-boot #2 pTLP #3 Ross's strawman http://s.apache.org/8eS it feels to me that all three need additional work to be done before we can have any reasonable consensus around them (let alone voting). Wearing my chair hat, I would like to suggest that the next step should be: for each proposal we identify points that are going to block consensus (AKA would result in -1 vote if it comes to a vote). I suggest we do it on the wiki pages themselves (I'll wikify Ross's proposal tonight). Not editing the wikis but simply collecting this feedback as the last section in each proposal. The idea would be to identify all such points in a week or so. Sounds good? To follow up. Each of the proposals: https://wiki.apache.org/incubator/MentorRebootProposal An active mentor is removed from a podling if that mentor does not review/sign off on a release. The above implies the foundation has a pool of mentors able to consistently meet every reporting requirement in a timely manner, without regard to personal or professional obstacles. I don't see it. For an organization almost entirely made up of volunteers this seems overly optimistic. There is only a small core membership who are capable and willing to do this as evidenced by a skim of history of general@incubator and members@. Perhaps this core group will end up shouldering the incubation load in its entirety. Although sadly this is more or less the current state of affairs, individual podlings do come with new mentors not part of the professional membership motivated to see at least that specific podling through. It's also risky to expect mentors kicked from a podling to be okay with it and want to try again, especially if listed on some naughty list to the board. https://wiki.apache.org/incubator/Strawman https://wiki.apache.org/incubator/Strawman Only ASF members on the PPMC will have binding votes for the releases. This proposal seems better than the others in my estimation, but doesn't allow podlings full investment in their own release management. The members on the PPMC who have binding votes will drive the release process out of necessity. Once the podling graduates and the members on the PPMC leave to resume other interests or duties, only then for the first time is the project running their own releases. I think it was better to let the podling own their release process but have the IPMC (or equivalent) have an up-or-down vote afterward as a check on their activities. https://wiki.apache.org/incubator/IncubatorV2 https://wiki.apache.org/incubator/IncubatorV2 This proposal revokes merit earned by existing IPMC members and reboots incubator supervision as a sub-board limited to 15 members. How members apply to this board is not specified. It is suggested the current board make recommendations to
RE: Is there a place I can programmatically pull in PPMC members?
Sorry misread your request as IPMC Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Alan D. Cabrera [mailto:a...@toolazydogs.com] Sent: Tuesday, January 20, 2015 11:17 AM To: infrastructure-...@apache.org Cc: general@incubator.apache.org Subject: Re: Is there a place I can programmatically pull in PPMC members? This seems to get me the IPMC members, not the PPMC members of podlings. Am I misinterpreting the page? Regards, Alan On Jan 20, 2015, at 11:04 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: See the code behind Whimsy (https://whimsy.apache.org/technology.html) The part you looking for produces https://whimsy.apache.org/roster/committee/incubator Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Alan D. Cabrera [mailto:l...@toolazydogs.com] Sent: Tuesday, January 20, 2015 10:58 AM To: infrastructure-...@apache.org; general@incubator.apache.org Subject: Is there a place I can programmatically pull in PPMC members? Is there a place I can programmatically pull in PPMC members? Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache htrace-3.1.0-incubating
+1 (binding -- though it may not be allowed that I vote on an RC I posted). From the htrace mailing list [1]: +1 Verified md5 and signature. Ran rat and all unit tests. Was able to assemble a src tarball from downloaded tarball. St.Ack 1. http://mail-archives.apache.org/mod_mbox/incubator-htrace-dev/201501.mbox/%3ccadcmmgfl6orjlvcqr2taf7hr+s44bpw9pcavslee+m2g518...@mail.gmail.com%3E On Sat, Jan 17, 2015 at 7:36 PM, Stack st...@duboce.net wrote: Apache HTrace (incubating), after ten release candidates, has voted to release the below referenced Apache HTrace 3.1.0-incubating release candidate. Dear IPMC, please vote on our first release candidate as an Apache Incubator project. Here is the vote thread we ran on our dev list (Six binding +1 votes and no dissent) with a subject: [VOTE] htrace-3.1.0, the this is it for sure!, tenth release candidate *http://mail-archives.apache.org/mod_mbox/incubator-htrace-dev/201501.mbox/%3CCADcMMgF_agDCzcwsxpdGsJOzCQ1ebA5z7hsM_-oFbneAVzh4dg%40mail.gmail.com%3E http://mail-archives.apache.org/mod_mbox/incubator-htrace-dev/201501.mbox/%3CCADcMMgF_agDCzcwsxpdGsJOzCQ1ebA5z7hsM_-oFbneAVzh4dg%40mail.gmail.com%3E* The source tarball, hashes, and signing are here: http://people.apache.org/~stack/htrace-3.1.0-incubatingRC9/ (Over in htrace our RC number was zero based so RC9 == tenth RC) Related maven artifacts are posted here: https://repository.apache.org/content/repositories/orgapachehtrace-1014 The tag for the RC is here: https://git-wip-us.apache.org/repos/asf?p=incubator-htrace.git;a=commit;h=0cabe569bc05a58c7a319a460eed5e50e136bae7 The KEYS file with the key used signing is available here: *https://dist.apache.org/repos/dist/release/incubator/htrace/KEYS https://dist.apache.org/repos/dist/release/incubator/htrace/KEYS* 44 issues were closed/resolved for this release: https://issues.apache.org/jira/issues/?jql=project%20%3D%20HTRACE%20AND%20status%20%3D%20resolved%20AND%20fixVersion%20%3D%203.1.0%20ORDER%20BY%20issuetype%20DESC The vote will be open for 72 hours. [ ] +1 Release this package as Apache HTrace 3.1.0-incubating [ ] +0 no opinion [ ] -1 Do not release this package because ... Thanks, St.Ack
[RESULT] [VOTE] Accept OpenAz (Access Control Tools) into the Apache Incubator
Vote passes with: [6] +1 (binding): hadrian, coheigea, elecharny, pzf, adc, jani [6] +1 (non-binding): chris rath, rich levinson, pam dragosh, dilli arumungam, david laurance, hal lockhart [0] -1: Congratulations and good luck to the OpenAZ community. Hal -Original Message- From: Hal Lockhart Sent: Monday, January 05, 2015 1:16 PM To: general@incubator.apache.org Subject: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator I call a vote to accept OpenAz as a new Incubator project. The proposal can be found here: https://wiki.apache.org/incubator/OpenAZProposal and is included below in this email. Voting will remain open until at least January 20, 2015 23:00 ET. Hal Lockhart --- Abstract OpenAz is a project to create tools and libraries to enable the development of Attribute-based Access Control (ABAC) Systems in a variety of languages. In general the work is at least consistent with or actually conformant to the OASIS XACML Standard. Proposal Generally the work falls into two categories: ready to use tools which implement standardized or well understood components of an ABAC system and design proposals and proof of concept code relating to less well understood or experimental aspects of the problem. Much of the work to date has revolved around defining interfaces enabling a PEP to request an access control decision from a PDP. The XACML standard defines an abstract request format in xml and protocol wire formats in xaml and json, but it does not specify programmatic interfaces in any language. The standard says that the use of XML (or JSON) is not required only the semantic equivalent. The first Interface, AzAPI is modeled closely on the XACML defined interface, expressed in Java. One of the goals was to support calls to both a PDP local to the same process and a PDP in a remote server. AzAPI includes the interface, reference code to handle things like the many supported datatypes in XACML and glue code to mate it to the open source Sun XACML implementation. Because of the dependence on Sun XACML (which is XACML 2.0) the interface was missing some XACML 3.0 features. More recently this was corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was done by the JPMC team to support calling a remote PDP. WSo2 is also pursuing this capability. A second, higher level interface, PEPAPI was also defined. PEPAPI is more intended for application developers with little knowledge of XACML. It allows Java objects which contain attribute information to be passed in. Conversion methods, called mappers extract information from the objects and present it in the format expected by XACML. Some implementers have chosen to implement PEPAPI directly against their PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface which closely matches the Java one. Examples of more speculative work include: proposals for registration and dispatch of Obligation and Advice handlers, a scheme called AMF to tell PIPs how to retrieve attributes and PIP code to implement it, discussion of PoC code to demonstrate the use of XACML policies to drive OAuth interations and a proposal to use XACML policies to express OAuth scope. ATT has recently contributed their extensive XACML framework to the project. The ATT framework represents the entire XACML 3.0 object set as a collection of Java interfaces and standard implementations of those interfaces. The ATT PDP engine is built on top of this framework and represents a complete implementation of a XACML 3.0 PDP, including all of the multi-decision profiles. In addition, the framework also contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and XACML JSON Profile v1.0 WD 14. The PEP API includes annotation functionality, allowing application developers to simply annotate a Java class to provide attributes for a request. The annotation support removes the need for application developers to learn much of the API. The ATT framework also includes interfaces and implementations to standardize development of PIP engines that are used by the ATT PDP implementation, and can be used by other implementations built on top of the ATT framework. The framework also includes interfaces and implementations for a PAP distributed cloud infrastructure of PDP nodes that includes support for policy distribution and pip configurations. This PAP infrastructure includes a web application administrative console that contains a XACML 3.0 policy editor, attribute dictionary support, and management of PDP RESTful node instances. In addition, there are tools available for policy simulation. Background Access Control is in some ways the most basic IT Security service. It consists of making a decision about whether a particular request should be
Re: Is there a place I can programmatically pull in PPMC members?
On 20 January 2015 at 20:29, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: Sorry misread your request as IPMC Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Alan D. Cabrera [mailto:a...@toolazydogs.com] Sent: Tuesday, January 20, 2015 11:17 AM To: infrastructure-...@apache.org Cc: general@incubator.apache.org Subject: Re: Is there a place I can programmatically pull in PPMC members? This seems to get me the IPMC members, not the PPMC members of podlings. Am I misinterpreting the page? The only place that information is kept is in the project status xml files (of course also in the maillist setups but I guess that is harder to look at). https://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/ good luck jan i. Regards, Alan On Jan 20, 2015, at 11:04 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: See the code behind Whimsy (https://whimsy.apache.org/technology.html) The part you looking for produces https://whimsy.apache.org/roster/committee/incubator Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Alan D. Cabrera [mailto:l...@toolazydogs.com] Sent: Tuesday, January 20, 2015 10:58 AM To: infrastructure-...@apache.org; general@incubator.apache.org Subject: Is there a place I can programmatically pull in PPMC members? Is there a place I can programmatically pull in PPMC members? Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Is there a place I can programmatically pull in PPMC members?
On Jan 20, 2015, at 11:36 AM, jan i j...@apache.org wrote: On 20 January 2015 at 20:29, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com mailto:ross.gard...@microsoft.com wrote: Sorry misread your request as IPMC Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Alan D. Cabrera [mailto:a...@toolazydogs.com] Sent: Tuesday, January 20, 2015 11:17 AM To: infrastructure-...@apache.org Cc: general@incubator.apache.org Subject: Re: Is there a place I can programmatically pull in PPMC members? This seems to get me the IPMC members, not the PPMC members of podlings. Am I misinterpreting the page? The only place that information is kept is in the project status xml files (of course also in the maillist setups but I guess that is harder to look at). https://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/ https://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/ Ok, those sources of information do not provide an entirely accurate picture. I’ll start updating podlings.xml though, ideally, the podlings would be treated the same way that PMCs are. Does that make better sense, i.e. start creating LDAP groups? good luck jan i. Regards, Alan On Jan 20, 2015, at 11:04 AM, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: See the code behind Whimsy (https://whimsy.apache.org/technology.html) The part you looking for produces https://whimsy.apache.org/roster/committee/incubator Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Alan D. Cabrera [mailto:l...@toolazydogs.com] Sent: Tuesday, January 20, 2015 10:58 AM To: infrastructure-...@apache.org; general@incubator.apache.org Subject: Is there a place I can programmatically pull in PPMC members? Is there a place I can programmatically pull in PPMC members? Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org mailto:general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org mailto:general-h...@incubator.apache.org
