Re: IP Clearance before releasing
On Thu, Dec 12, 2013 at 5:51 AM, Marvin Humphrey mar...@rectangular.comwrote: For a release tagged with the incubating label and disclaimer, filing bugs rather than blocking seems reasonable. I may have edited away more than you like but yes - filing bugs rather than blocking is the approach we should try using more, much more. All that stuff about putting the foundation at risk seems vastly over stated - are there any examples at all ever where the foundation has come to any harm from a duff release? The release voting is to make the release a collective action of the foundation to protect individuals not to protect the foundation. I'm curious what others think. There's room for us to disagree, since release votes do not require consensus... Podling release voting is one of the most problematic areas of the Incubator and has been for years. Its the disagreement over whats required that tosses podlings about with one person saying they must do one thing and others something else, and it puts off mentors from voting in case they're made to look like they don't know what they're doing. So I think we should try to find some consensus on approach rather than agreeing to disagree, ...ant
Re: IP Clearance before releasing
This has a good feel about it. Clearer, with flexibility. We should probably be clear about *who* can relax the rules, because again this could become a fighting ground amongst 180 of us. As to putting the foundation at risk - breaching someone else's copyright does that. Breaching the foundation's policies doesn't. Upayavira On Thu, Dec 12, 2013, at 05:51 AM, Marvin Humphrey wrote: On Tue, Dec 10, 2013 at 3:50 AM, ant elder ant.el...@gmail.com wrote: And the Incubator _is_ different and does have different policy and rules, hence on occasion podlings being permitted to do releases which include GPL dependencies while Incubating and just fixing those up as a graduation requirement. Over in another thread[1], Bertrand came up with a thoughtful formulation: I have no problem with clear and documented decisions to relax some of the release checklist criteria for an incubating release, as long as that doesn't put the foundation at risk. That's more lenient than either my inconsequential test or Benson's materiality, but it provides something else: a framework inside which the Incubator may bend the rules. It had been hard for me to understand how we could justify exercising discretion about policy, given the Incubator's obligations as an ordinary Apache TLP, but perhaps document how this problem doesn't put the Foundation at risk is something I can get behind. I expect that an incubating release with a GPL dependency would have necessitated the approval of VP Legal Affairs, right? That would fit inside Bertrand's framework. Similarly, licensing documentation bugs such as extra garbage in NOTICE or the occasional missing ALv2 header do not put the foundation at risk -- or put our downstream users at risk. For a release tagged with the incubating label and disclaimer, filing bugs rather than blocking seems reasonable. I'm curious what others think. There's room for us to disagree, since release votes do not require consensus... Marvin Humphrey [1] http://s.apache.org/r1F - 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: Release Verification Checklist
Hi Marvin, On Thu, Dec 12, 2013 at 6:21 AM, Marvin Humphrey mar...@rectangular.com wrote: I also went another round on the Manifest template and the Release Procedure section of the guide (not yet committed): https://paste.apache.org/a1ya ... Looks good to me but why it must be approved by a Mentor (who must also be an Apache Member ? We do have mentors who are not members, and that's fine IMO. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Release Verification Checklist
On Thu, Dec 12, 2013 at 6:22 AM, Marvin Humphrey mar...@rectangular.com wrote: ...Next, I will start a PROPOSAL thread, to re-engage with the rest of the list... There's been ample space for people to comment on this in the last few weeks, I'd be clear that we don't expect any core changes we agree on the final proposal in this thread. Tweaks and typos, fine, the rest has been extensively discussed so far, let's avoid restarting from the top ;-) -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance before releasing
On 12/11/13 9:51 PM, Marvin Humphrey mar...@rectangular.com wrote: I'm curious what others think. There's room for us to disagree, since release votes do not require consensus... That's the part I've found curious. There's no whistleblower provision for someone who thinks they see something that puts the foundation at risk from stopping those to don't see it. Certainly, quality is subjective and thus consensus is too strict, but the process we use to get a consensus veto to change seems appropriate if a -1 vote is based on a foundation/law issue. Some of our policies do have wiggle room, but I don't think all of them do. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance before releasing
On Thu, Dec 12, 2013 at 7:38 AM, Alex Harui aha...@adobe.com wrote: There's no whistleblower provision for someone who thinks they see something that puts the foundation at risk from stopping those to don't see it. If there's a clear legal problem with a release candidate I'd expect others to acknowledge it and cancel the vote. If they don't then that could be escalated to the Incubator PMC. Doug
Re: [VOTE] Phoenix for incubator project
Hi St.Ack, I haven't seen that this vote has closed. Craig On Dec 5, 2013, at 1:43 PM, Stack wrote: Discussion of the Phoenix proposal has settled since its original posting on November 7th. Feedback has been incorporated. Let us now move to a vote. Should Phoenix become an Apache incubator project? [] +1 Accept Phoenix into the Incubator [] +0 Don't care whether or which [] -1 Do not accept Phoenix into the Incubator because... The latest version of the proposal can be found here [1]. It is also posted below for your convenience. Let the vote run 72 hours. Thank you, St.Ack 1. https://wiki.apache.org/incubator/PhoenixProposal Abstract Phoenix is an open source SQL query engine for Apache HBase, a NoSQL data store. It is accessed as a JDBC driver and enables querying and managing HBase tables using SQL. Proposal Phoenix is an open source SQL skin over HBase delivered as a client-embedded JDBC driver targeting low latency queries over HBase data. Phoenix takes your SQL query, compiles it into a series of HBase scans, and orchestrates the running of those scans to produce regular JDBC result sets. The table metadata is stored in an HBase table and versioned, such that snapshot queries over prior versions will automatically use the correct schema. Direct use of the HBase API, along with coprocessors and custom filters, results in performance on the order of milliseconds for small queries, or seconds for tens of millions of rows. Phoenix interfaces with both Pig and Map-reduce for the input and output of data. Background Phoenix initially started as an internal project at Salesforce.com to efficiently analyze big data stored in HBase. It was open sourced on Github about a year ago in Jan 2013. Over time Phoenix, together with HBase as the storage tier, has begun to evolve into a general SQL database with support for metadata management, secondary indexes, joins, query optimization, and multi-tenancy. This is expected to continue as Phoenix implements a cost-based query optimizer and potentially transaction support, and surfaces new HBase security features such as encryption and cell-level security. Phoenix's developer community has also grown to include additional companies such as Intel, who have contributed join support to Phoenix, as well as Hortonworks, who are in the process of porting Phoenix to the 0.96 release of HBase. Rationale As usage and the number of contributors to Phoenix has grown, we have sought for a long-term home for the project, and we believe the Apache foundation would be a great fit. Joining Apache would ensure that tried and true processes and procedures are in place for the growing number of organizations interested in contributing to Phoenix. Phoenix is also a good fit for the Apache foundation: Phoenix already interoperates with several existing Apache projects (HBase, Hadoop, Pig, BigTop). The Phoenix team is familiar with the Apache process and and believes in the Apache mission - the team already includes multiple Apache committers. Initial Goals The initial goals will be to move the existing codebase to Apache and integrate with the Apache development process. Once this is accomplished, we plan for incremental development and releases that follow the Apache guidelines. Current Status Phoenix has undergone two major and three minor releases (1.0, 1.1, 1.2, 2.0, and 2.1) as well as many patch releases. Phoenix is being used in production by Salesforce.com as well as at other organizations. The Phoenix codebase is currently hosted at github.com, which will form the basis of the Apache git repository. Meritocracy The Phoenix project already operates on meritocratic principles. Phoenix has several developers from various organizations outside of Salesforce.com who have contributed major new features. While this process has remained mostly informal, as we do not have an official committer list, an implicit organization exists in which individuals who contribute major components act as maintainers for those modules. If accepted, the Phoenix project would include several of these participants as initial committers. We will work to identify all committers and PPMC members for the project and to operate under the ASF meritocratic principles. Community Acceptance into the Apache foundation would bolster the already strong user and developer community around Phoenix. That community includes many contributors from various other companies, and an active mailing list composed of hundreds of users. Core Developers The core developers of our project are listed in our contributors and initial PPMC below. Though many are employed at Salesforce.com, there is a representative cross sampling of other organizations including Intel, Hortonworks, and Cloudera. Alignment Our proposed Phoenix effort aligns closely with Apache HBase. The HBase project
Re: [VOTE] Phoenix for incubator project
Hi Craig, Does this constitute closing the vote: *http://mail-archives.apache.org/mod_mbox/incubator-general/201312.mbox/%3CCADcMMgHzeJJ7Vi-bSWGqb16j44cSEz9Svov%3D5L4LKctzBQ3_xw%40mail.gmail.com%3E http://mail-archives.apache.org/mod_mbox/incubator-general/201312.mbox/%3CCADcMMgHzeJJ7Vi-bSWGqb16j44cSEz9Svov%3D5L4LKctzBQ3_xw%40mail.gmail.com%3E* ? Thanks, James On Thu, Dec 12, 2013 at 11:09 AM, Craig L Russell craig.russ...@oracle.comwrote: Hi St.Ack, I haven't seen that this vote has closed. Craig On Dec 5, 2013, at 1:43 PM, Stack wrote: Discussion of the Phoenix proposal has settled since its original posting on November 7th. Feedback has been incorporated. Let us now move to a vote. Should Phoenix become an Apache incubator project? [] +1 Accept Phoenix into the Incubator [] +0 Don't care whether or which [] -1 Do not accept Phoenix into the Incubator because... The latest version of the proposal can be found here [1]. It is also posted below for your convenience. Let the vote run 72 hours. Thank you, St.Ack 1. https://wiki.apache.org/incubator/PhoenixProposal Abstract Phoenix is an open source SQL query engine for Apache HBase, a NoSQL data store. It is accessed as a JDBC driver and enables querying and managing HBase tables using SQL. Proposal Phoenix is an open source SQL skin over HBase delivered as a client-embedded JDBC driver targeting low latency queries over HBase data. Phoenix takes your SQL query, compiles it into a series of HBase scans, and orchestrates the running of those scans to produce regular JDBC result sets. The table metadata is stored in an HBase table and versioned, such that snapshot queries over prior versions will automatically use the correct schema. Direct use of the HBase API, along with coprocessors and custom filters, results in performance on the order of milliseconds for small queries, or seconds for tens of millions of rows. Phoenix interfaces with both Pig and Map-reduce for the input and output of data. Background Phoenix initially started as an internal project at Salesforce.com to efficiently analyze big data stored in HBase. It was open sourced on Github about a year ago in Jan 2013. Over time Phoenix, together with HBase as the storage tier, has begun to evolve into a general SQL database with support for metadata management, secondary indexes, joins, query optimization, and multi-tenancy. This is expected to continue as Phoenix implements a cost-based query optimizer and potentially transaction support, and surfaces new HBase security features such as encryption and cell-level security. Phoenix's developer community has also grown to include additional companies such as Intel, who have contributed join support to Phoenix, as well as Hortonworks, who are in the process of porting Phoenix to the 0.96 release of HBase. Rationale As usage and the number of contributors to Phoenix has grown, we have sought for a long-term home for the project, and we believe the Apache foundation would be a great fit. Joining Apache would ensure that tried and true processes and procedures are in place for the growing number of organizations interested in contributing to Phoenix. Phoenix is also a good fit for the Apache foundation: Phoenix already interoperates with several existing Apache projects (HBase, Hadoop, Pig, BigTop). The Phoenix team is familiar with the Apache process and and believes in the Apache mission - the team already includes multiple Apache committers. Initial Goals The initial goals will be to move the existing codebase to Apache and integrate with the Apache development process. Once this is accomplished, we plan for incremental development and releases that follow the Apache guidelines. Current Status Phoenix has undergone two major and three minor releases (1.0, 1.1, 1.2, 2.0, and 2.1) as well as many patch releases. Phoenix is being used in production by Salesforce.com as well as at other organizations. The Phoenix codebase is currently hosted at github.com, which will form the basis of the Apache git repository. Meritocracy The Phoenix project already operates on meritocratic principles. Phoenix has several developers from various organizations outside of Salesforce.com who have contributed major new features. While this process has remained mostly informal, as we do not have an official committer list, an implicit organization exists in which individuals who contribute major components act as maintainers for those modules. If accepted, the Phoenix project would include several of these participants as initial committers. We will work to identify all committers and PPMC members for the project and to operate under the ASF meritocratic principles. Community Acceptance into the Apache foundation would bolster the already strong
Re: [VOTE] Phoenix for incubator project
Pardon me Craig. I messed up the closing of the vote. I resent the vote tally later w/ appropriate title: http://mail-archives.apache.org/mod_mbox/incubator-general/201312.mbox/%3CCADcMMgHzeJJ7Vi-bSWGqb16j44cSEz9Svov%3D5L4LKctzBQ3_xw%40mail.gmail.com%3E St.Ack On Thu, Dec 12, 2013 at 11:09 AM, Craig L Russell craig.russ...@oracle.comwrote: Hi St.Ack, I haven't seen that this vote has closed. Craig On Dec 5, 2013, at 1:43 PM, Stack wrote: Discussion of the Phoenix proposal has settled since its original posting on November 7th. Feedback has been incorporated. Let us now move to a vote. Should Phoenix become an Apache incubator project? [] +1 Accept Phoenix into the Incubator [] +0 Don't care whether or which [] -1 Do not accept Phoenix into the Incubator because... The latest version of the proposal can be found here [1]. It is also posted below for your convenience. Let the vote run 72 hours. Thank you, St.Ack 1. https://wiki.apache.org/incubator/PhoenixProposal Abstract Phoenix is an open source SQL query engine for Apache HBase, a NoSQL data store. It is accessed as a JDBC driver and enables querying and managing HBase tables using SQL. Proposal Phoenix is an open source SQL skin over HBase delivered as a client-embedded JDBC driver targeting low latency queries over HBase data. Phoenix takes your SQL query, compiles it into a series of HBase scans, and orchestrates the running of those scans to produce regular JDBC result sets. The table metadata is stored in an HBase table and versioned, such that snapshot queries over prior versions will automatically use the correct schema. Direct use of the HBase API, along with coprocessors and custom filters, results in performance on the order of milliseconds for small queries, or seconds for tens of millions of rows. Phoenix interfaces with both Pig and Map-reduce for the input and output of data. Background Phoenix initially started as an internal project at Salesforce.com to efficiently analyze big data stored in HBase. It was open sourced on Github about a year ago in Jan 2013. Over time Phoenix, together with HBase as the storage tier, has begun to evolve into a general SQL database with support for metadata management, secondary indexes, joins, query optimization, and multi-tenancy. This is expected to continue as Phoenix implements a cost-based query optimizer and potentially transaction support, and surfaces new HBase security features such as encryption and cell-level security. Phoenix's developer community has also grown to include additional companies such as Intel, who have contributed join support to Phoenix, as well as Hortonworks, who are in the process of porting Phoenix to the 0.96 release of HBase. Rationale As usage and the number of contributors to Phoenix has grown, we have sought for a long-term home for the project, and we believe the Apache foundation would be a great fit. Joining Apache would ensure that tried and true processes and procedures are in place for the growing number of organizations interested in contributing to Phoenix. Phoenix is also a good fit for the Apache foundation: Phoenix already interoperates with several existing Apache projects (HBase, Hadoop, Pig, BigTop). The Phoenix team is familiar with the Apache process and and believes in the Apache mission - the team already includes multiple Apache committers. Initial Goals The initial goals will be to move the existing codebase to Apache and integrate with the Apache development process. Once this is accomplished, we plan for incremental development and releases that follow the Apache guidelines. Current Status Phoenix has undergone two major and three minor releases (1.0, 1.1, 1.2, 2.0, and 2.1) as well as many patch releases. Phoenix is being used in production by Salesforce.com as well as at other organizations. The Phoenix codebase is currently hosted at github.com, which will form the basis of the Apache git repository. Meritocracy The Phoenix project already operates on meritocratic principles. Phoenix has several developers from various organizations outside of Salesforce.com who have contributed major new features. While this process has remained mostly informal, as we do not have an official committer list, an implicit organization exists in which individuals who contribute major components act as maintainers for those modules. If accepted, the Phoenix project would include several of these participants as initial committers. We will work to identify all committers and PPMC members for the project and to operate under the ASF meritocratic principles. Community Acceptance into the Apache foundation would bolster the already strong user and developer community around Phoenix. That community includes many contributors from various
Re: [VOTE] Phoenix for incubator project
All ok. Regards, Craig On Dec 12, 2013, at 11:20 AM, Stack wrote: Pardon me Craig. I messed up the closing of the vote. I resent the vote tally later w/ appropriate title: http://mail-archives.apache.org/mod_mbox/incubator-general/201312.mbox/%3CCADcMMgHzeJJ7Vi-bSWGqb16j44cSEz9Svov%3D5L4LKctzBQ3_xw%40mail.gmail.com%3E St.Ack On Thu, Dec 12, 2013 at 11:09 AM, Craig L Russell craig.russ...@oracle.comwrote: Hi St.Ack, I haven't seen that this vote has closed. Craig On Dec 5, 2013, at 1:43 PM, Stack wrote: Discussion of the Phoenix proposal has settled since its original posting on November 7th. Feedback has been incorporated. Let us now move to a vote. Should Phoenix become an Apache incubator project? [] +1 Accept Phoenix into the Incubator [] +0 Don't care whether or which [] -1 Do not accept Phoenix into the Incubator because... The latest version of the proposal can be found here [1]. It is also posted below for your convenience. Let the vote run 72 hours. Thank you, St.Ack 1. https://wiki.apache.org/incubator/PhoenixProposal Abstract Phoenix is an open source SQL query engine for Apache HBase, a NoSQL data store. It is accessed as a JDBC driver and enables querying and managing HBase tables using SQL. Proposal Phoenix is an open source SQL skin over HBase delivered as a client-embedded JDBC driver targeting low latency queries over HBase data. Phoenix takes your SQL query, compiles it into a series of HBase scans, and orchestrates the running of those scans to produce regular JDBC result sets. The table metadata is stored in an HBase table and versioned, such that snapshot queries over prior versions will automatically use the correct schema. Direct use of the HBase API, along with coprocessors and custom filters, results in performance on the order of milliseconds for small queries, or seconds for tens of millions of rows. Phoenix interfaces with both Pig and Map-reduce for the input and output of data. Background Phoenix initially started as an internal project at Salesforce.com to efficiently analyze big data stored in HBase. It was open sourced on Github about a year ago in Jan 2013. Over time Phoenix, together with HBase as the storage tier, has begun to evolve into a general SQL database with support for metadata management, secondary indexes, joins, query optimization, and multi-tenancy. This is expected to continue as Phoenix implements a cost-based query optimizer and potentially transaction support, and surfaces new HBase security features such as encryption and cell-level security. Phoenix's developer community has also grown to include additional companies such as Intel, who have contributed join support to Phoenix, as well as Hortonworks, who are in the process of porting Phoenix to the 0.96 release of HBase. Rationale As usage and the number of contributors to Phoenix has grown, we have sought for a long-term home for the project, and we believe the Apache foundation would be a great fit. Joining Apache would ensure that tried and true processes and procedures are in place for the growing number of organizations interested in contributing to Phoenix. Phoenix is also a good fit for the Apache foundation: Phoenix already interoperates with several existing Apache projects (HBase, Hadoop, Pig, BigTop). The Phoenix team is familiar with the Apache process and and believes in the Apache mission - the team already includes multiple Apache committers. Initial Goals The initial goals will be to move the existing codebase to Apache and integrate with the Apache development process. Once this is accomplished, we plan for incremental development and releases that follow the Apache guidelines. Current Status Phoenix has undergone two major and three minor releases (1.0, 1.1, 1.2, 2.0, and 2.1) as well as many patch releases. Phoenix is being used in production by Salesforce.com as well as at other organizations. The Phoenix codebase is currently hosted at github.com, which will form the basis of the Apache git repository. Meritocracy The Phoenix project already operates on meritocratic principles. Phoenix has several developers from various organizations outside of Salesforce.com who have contributed major new features. While this process has remained mostly informal, as we do not have an official committer list, an implicit organization exists in which individuals who contribute major components act as maintainers for those modules. If accepted, the Phoenix project would include several of these participants as initial committers. We will work to identify all committers and PPMC members for the project and to operate under the ASF meritocratic principles. Community Acceptance into the Apache foundation would bolster the already strong user and developer community around Phoenix. That community includes many contributors from
Changing moderation settings
How can I change the moderation settings for the Storm user and dev lists? I'm getting enormous amounts of moderation emails (including lots triggered by JIRA). Is there a way to whitelist accounts, turn off moderation, and/or approve in bulk (like via a web interface)?
[ANNOUNCE] Billie Rinaldi joins the IPMC
Apache Member Billie Rinaldi, the PMC Chair for Accumulo and a member of the Ambari PMC, has elected to join the Incubator PMC. May you have as much success as an IPMC member as you had as a PPMC member of the Accumulo podling! Marvin Humphrey, on behalf of the Incubator PMC - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Changing moderation settings
I believe a moderator can add jira to the subscription... Something like: Send request email and confirm sent to storm-dev-subscribe-jira=apache@incubator.apache.org -Original Message- From: nathan.m...@gmail.com [mailto:nathan.m...@gmail.com] On Behalf Of Nathan Marz Sent: Thursday, December 12, 2013 3:29 PM To: general@incubator.apache.org Subject: Changing moderation settings How can I change the moderation settings for the Storm user and dev lists? I'm getting enormous amounts of moderation emails (including lots triggered by JIRA). Is there a way to whitelist accounts, turn off moderation, and/or approve in bulk (like via a web interface)? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Changing moderation settings
dev-subscribe-jira=apache@storm.incubator.apache.org -Original Message- From: Chen, Pei [mailto:pei.c...@childrens.harvard.edu] Sent: Thursday, December 12, 2013 3:37 PM To: general@incubator.apache.org Subject: RE: Changing moderation settings I believe a moderator can add jira to the subscription... Something like: Send request email and confirm sent to storm-dev-subscribe- jira=apache@incubator.apache.org -Original Message- From: nathan.m...@gmail.com [mailto:nathan.m...@gmail.com] On Behalf Of Nathan Marz Sent: Thursday, December 12, 2013 3:29 PM To: general@incubator.apache.org Subject: Changing moderation settings How can I change the moderation settings for the Storm user and dev lists? I'm getting enormous amounts of moderation emails (including lots triggered by JIRA). Is there a way to whitelist accounts, turn off moderation, and/or approve in bulk (like via a web interface)? - 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: Changing moderation settings
You shouldn't need to subscribe jira to your list. Rather just 'allow' a message by using reply-all to a moderation request so that all future posts from that sender are accepted. Doug On Thu, Dec 12, 2013 at 12:38 PM, Chen, Pei pei.c...@childrens.harvard.eduwrote: dev-subscribe-jira=apache@storm.incubator.apache.org -Original Message- From: Chen, Pei [mailto:pei.c...@childrens.harvard.edu] Sent: Thursday, December 12, 2013 3:37 PM To: general@incubator.apache.org Subject: RE: Changing moderation settings I believe a moderator can add jira to the subscription... Something like: Send request email and confirm sent to storm-dev-subscribe- jira=apache@incubator.apache.org -Original Message- From: nathan.m...@gmail.com [mailto:nathan.m...@gmail.com] On Behalf Of Nathan Marz Sent: Thursday, December 12, 2013 3:29 PM To: general@incubator.apache.org Subject: Changing moderation settings How can I change the moderation settings for the Storm user and dev lists? I'm getting enormous amounts of moderation emails (including lots triggered by JIRA). Is there a way to whitelist accounts, turn off moderation, and/or approve in bulk (like via a web interface)? - 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: [ANNOUNCE] Billie Rinaldi joins the IPMC
Welcome Billie! Sent from my iPhone On Dec 12, 2013, at 12:35 PM, Marvin Humphrey mar...@rectangular.com wrote: Apache Member Billie Rinaldi, the PMC Chair for Accumulo and a member of the Ambari PMC, has elected to join the Incubator PMC. May you have as much success as an IPMC member as you had as a PPMC member of the Accumulo podling! Marvin Humphrey, on behalf of the Incubator PMC - 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: Changing moderation settings
You can also allow with dev-allow-subscribe-jira=apache@storm.incubator.apache.org -Jake On Thu, Dec 12, 2013 at 3:47 PM, Doug Cutting cutt...@apache.org wrote: You shouldn't need to subscribe jira to your list. Rather just 'allow' a message by using reply-all to a moderation request so that all future posts from that sender are accepted. Doug On Thu, Dec 12, 2013 at 12:38 PM, Chen, Pei pei.c...@childrens.harvard.eduwrote: dev-subscribe-jira=apache@storm.incubator.apache.org -Original Message- From: Chen, Pei [mailto:pei.c...@childrens.harvard.edu] Sent: Thursday, December 12, 2013 3:37 PM To: general@incubator.apache.org Subject: RE: Changing moderation settings I believe a moderator can add jira to the subscription... Something like: Send request email and confirm sent to storm-dev-subscribe- jira=apache@incubator.apache.org -Original Message- From: nathan.m...@gmail.com [mailto:nathan.m...@gmail.com] On Behalf Of Nathan Marz Sent: Thursday, December 12, 2013 3:29 PM To: general@incubator.apache.org Subject: Changing moderation settings How can I change the moderation settings for the Storm user and dev lists? I'm getting enormous amounts of moderation emails (including lots triggered by JIRA). Is there a way to whitelist accounts, turn off moderation, and/or approve in bulk (like via a web interface)? - 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
[ANNOUNCE] Apache VXQuery 0.2-incubating released
The Apache VXQuery (incubating) Team is happy to announce the first release of Apache VXQuery, 0.2-incubating. Apache VXQuery will be a standards compliant XML Query processor implemented in Java. The focus is on the evaluation of queries on large amounts of XML data. Specifically the goal is to evaluate queries on large collections of relatively small XML documents. To achieve this queries are evaluated on a cluster of shared nothing machines. More information about the project can be found at http://incubator.apache.org/vxquery/ The release is available at http://www.apache.org/dyn/closer.cgi/incubator/vxquery/ and the sha1 checksum for apache-vxquery-0.2-incubating-source-release.zip is f07fe151ddea24457c6497a1abd48528f9c02462 The Apache VXQuery Team would like to hear from you and welcomes your comments and contributions. Thanks The Apache VXQuery Team
Re: Changing moderation settings
Nathan Marz wrote: How can I change the moderation settings for the Storm user and dev lists? I'm getting enormous amounts of moderation emails (including lots triggered by JIRA). Is there a way to whitelist accounts, turn off moderation, and/or approve in bulk (like via a web interface)? Some tips are at: http://apache.org/dev/#mail http://apache.org/dev/committers.html#mail-moderate -David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Release Verification Checklist
On Dec 12, 2013, at 2:15 AM, Bertrand Delacretaz wrote: Hi Marvin, On Thu, Dec 12, 2013 at 6:21 AM, Marvin Humphrey mar...@rectangular.com wrote: I also went another round on the Manifest template and the Release Procedure section of the guide (not yet committed): https://paste.apache.org/a1ya ... Looks good to me but why it must be approved by a Mentor (who must also be an Apache Member ? Another rule is better than my straw man. Marvin really missed my point - which was 3 IPMC is the way it is done and I don't see a need to change. (Yes I know podlings can't get release votes ... with this rule I will lay odds we will start to see active -1 VOTEs from IPMC members on releases when there is any flaw. With the rule of VOTE at 3 +1 and the rest at 1 +1.) I think we have to have a way for IPMC members to VOTE -1 on releases after the first... We do have mentors who are not members, and that's fine IMO. Yes it is. It is very fine. I LIKE this process in all aspects except this change in the 3 +1 from the IPMC rule. Can the VOTE separate the two experiments? (1) Vote +1/-1 for the Release Verification Checklist experiment (2) Vote +1/-1 for the 1 +1 Mentor/IPMC for releases after the first release by a podling. Regards, Dave -Bertrand - 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: IP Clearance before releasing
A point which is often missed by new comers is that votes aren't final until they vote closes and is tallied. That allows a vote that uncovers a serious defect to trigger a bunch of defecting votes (if the vote isn't just canceled) On Thu, Dec 12, 2013 at 11:02 AM, Doug Cutting cutt...@apache.org wrote: On Thu, Dec 12, 2013 at 7:38 AM, Alex Harui aha...@adobe.com wrote: There's no whistleblower provision for someone who thinks they see something that puts the foundation at risk from stopping those to don't see it. If there's a clear legal problem with a release candidate I'd expect others to acknowledge it and cancel the vote. If they don't then that could be escalated to the Incubator PMC. Doug
Re: Release Verification Checklist
On Thu, Dec 12, 2013 at 8:56 PM, Dave Fisher dave2w...@comcast.net wrote: Another rule is better than my straw man. Marvin really missed my point - which was 3 IPMC is the way it is done and I don't see a need to change. I was fooled, yes. Since there's no compromise that would secure your vote, I'll go with my best judgment and require that the manifest be approved by a Mentor (without the ASF Member requirement). We could further relax it to approval-by-an-IPMC-Member, but such an approval would be inferior in the same way that a non-Mentor's freelance +1 is inferior under the current system. I LIKE this process in all aspects except this change in the 3 +1 from the IPMC rule. Can the VOTE separate the two experiments? So... * Ant likes the voting rule change, but is opposed to the checklist. * Dave likes the checklist but is opposed to the voting rule change. Sigh. There's no reason to have a VOTE on the checklist alone unless we want to make it mandatory: podlings have to fill it out in order to release, but IPMC members remain free to ignore it when they vote. Such an initiative seems unlikely to pass. Dave, if we can't arrive at a consensus compromise, even for authorizing an experiment, that's unfortunate -- but as with Ant, I'm grateful for our give-and-take and I believe that the proposal is much improved for it. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
