Re: LICENSE and NOTICE Role Models
On Wed, Dec 11, 2013 at 12:15 AM, P. Taylor Goetz ptgo...@gmail.com wrote: ... In the process of preparing the LICENSE and NOTICE files for Storm, I started looking at what other Apache projects (both incubator and TLPs) have done http://svn.apache.org/repos/asf/httpd/httpd/trunk/ is a good reference for that. -Bertrand - 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 Wed, Dec 11, 2013 at 7:08 AM, Marvin Humphrey mar...@rectangular.com wrote: ...I've taken a stab at a second draft: http://incubator.apache.org/guides/release.html Short and sweet, I like it! I've just added as a plain text file in the release manifest creation section. I suggest using simpler, more active phrases for a few things at https://paste.apache.org/fBoJ - feel free to apply or not, it's mostly a question of style. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Release Verification Checklist
Hi, On Wed, Dec 11, 2013 at 7:08 AM, Marvin Humphrey mar...@rectangular.com wrote: ...here's a first take for a patch to the policy page which will be submitted as part of the PROPOSAL... https://paste.apache.org/4A1I Looks good to me but I'd ask for a [VOTE] here before committing this. Suggestions: Call that 2013 alternate release voting process to avoid confusion. Use At least three +1 votes from PPMC members are required for the podling vote. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: LICENSE and NOTICE Role Models
All, It would be great if we could get a resolution on some of the JIRA's in legal, e.g. https://issues.apache.org/jira/browse/LEGAL-26 https://issues.apache.org/jira/browse/LEGAL-27 https://issues.apache.org/jira/browse/LEGAL-31 https://issues.apache.org/jira/browse/LEGAL-136 Legal-discuss, As PMC Chair of a TLP I find the situation with regards to these very confusing. We have had some people state the opinion that our current practice with regards to LICENSE NOTICE files is not correct yet these issues are still unresolved in the LEGAL JIRA and thus, I presume, no legal decision has been formed. Absence a clear decision from the legal PMC we have no choice but to presume that our current interpretation is just as valid as any other interpretation and therefore are continuing with our current practice, e.g. The most critical one to the Maven PMC is LEGAL-26: we have a number of SCM primary roots, for example all our plugins are within http://svn.apache.org/repos/asf/maven/plugins/trunk/ individual plugins are sub-folders within the whole, e.g. http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-deploy-plugin/ We currently view the primary roots as expected checkout points and the individual plugins as not being so. Most developers familiar with Subversion will know that /trunk/ is a root identifier and should expect to find the LICENSE and NOTICE information at that point. Maven tooling generates a project site for every component, so you will have a page such as http://maven.apache.org/plugins/maven-deploy-plugin/source-repository.htmlwhich tells you how to checkout the code of the specific module. In some cases we have multiple modules released together as one operation, e.g. http://maven.apache.org/surefire/index.html, so you have http://maven.apache.org/surefire/source-repository.html as the real root (though in this case this is a GIT based project and at least with GIT the situation is more clear, namely put a LICENSE NOTICE file in the root of the GIT repository... since you cannot checkout a partial GIT repository) So the net result is that http://svn.apache.org/repos/asf/maven/plugins/tags/maven-deploy-plugin-2.8.1/does not have a LICENSE NOTICE file *because* it is a tag of http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-deploy-plugin/which is only a partial of the root http://svn.apache.org/repos/asf/maven/plugins/trunk/. FTR, best effort can result in nothing happening at all... after all we can be an incompetent PMC, as long as we are doing our best effort there is no guarantee that our best is good enough... LEGAL-26 needs a very clear and exact ruling. Expected checkout points is too vague... I may only be interested in the java code of Maven's deploy plugin... is now http://svn.apache.org/repos/asf/maven/plugins/tags/maven-deploy-plugin-2.8.1/src/main/java/an expected checkout point? what about http://svn.apache.org/repos/asf/maven/plugins/tags/maven-deploy-plugin-2.8.1/src/main/java/org/apache/maven/plugin/deploy/or even http://svn.apache.org/repos/asf/maven/plugins/tags/maven-deploy-plugin-2.8.1/src/main/java/org/apache/maven/plugin/deploy/DeployRequest.java IMHO we should just put a standard LICENSE and NOTICE file at the root of the ASF SVN tree and projects that need to be exceptions to that general LICENSE and NOTICE should have to put the file at the point where it makes sense that is closest in scope to the content requiring the altered LICENSE and NOTICE... so, as examples are better at divining meaning, *if* we had copypasted some BSD code into the Maven Deploy Plugin *then* it would require a custom LICENSE and NOTICE file as the one inherited from the root would no longer be valid within that subtree... but in this case we do not have any such code, so we are fine to retain the inherited code. On 11 December 2013 05:24, Marvin Humphrey mar...@rectangular.com wrote: On Tue, Dec 10, 2013 at 8:10 PM, P. Taylor Goetz ptgo...@gmail.com wrote: It's kind of interesting to see how this has changed over time and varies from project to project. Here's Roy Fielding in June 2008, saying exactly the same thing you'll hear from us now: http://s.apache.org/Y4v If the notices aren't required by the bits in the package, then they don't belong in NOTICE. That means there will be a different NOTICE file required for each differently packaged set of bits. We must do this by hand. Because the file is named NOTICE, people tend to think it's for anything notice-ish. This is a pernicious misconception which keeps coming back over and over like a weed, and it used to be that not a lot of people besides Roy were effective at combatting it. Here's Roy in 2008 again: http://s.apache.org/ZIU Furthermore, I assume it is not problematic to have more stuff in the NOTICE file(s) than is really required. Yes, it is problematic. Consider it a tax on all downstream recipients. Roy can't be everywhere,
Re: LICENSE and NOTICE Role Models
Hi, welcome to such a nice process ;-) First, following what current TLP projects are doing could be a bad idea; I realized many of them wouldn't pass a IPMC checking now. In case it helps, from that process in Marmotta, I got a summary that, at least for me, helped a lot to simply the task. Basically consist on: * Don't put anything in NOTICE for the sake of an MIT-licensed dependency. * Don't put anything in NOTICE for the sake of a three-clause BSD dependency. * For an ALv2 dependency, follow the instructions in the licensing howto. * For all other licenses, either guess or ask. Further details at MARMOTTA-213. Of course these are informal rules, so do not follow to a tee. My 2 cents. Good luck! Cheers, On 11/12/13 00:15, P. Taylor Goetz wrote: In the process of preparing the LICENSE and NOTICE files for Storm, I started looking at what other Apache projects (both incubator and TLPs) have done. It seems like approaches are all over the map. I've even seen projects that don't have a NOTICE. My question to any mentors and PMC members is are there any projects that stand out as having done a really good job at this? (I understand that every circumstance is different.) One project that stood out to me was Cassandra. Storm actually shares some of the same dependencies, so I found their approach helpful. - Taylor - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- 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: [VOTE] Phoenix for incubator project
Let me vote +1 (binding) and now close the VOTE. Here are the results (* means IPMC): +1s: Roman Shaposhnik(*) James Taylor Lars Hofhansl(*) Henry Saputra(*) Leif Hedstrom(*) Anil Gupta Ted Dunning(*) Patrick Reilly Andrew Purtell(*) Ashish Anoop John Bruno Mahé Ramkrishna S. Vasudevan Jonathan Hsieh Devaraj Das(*) Sergio Fernández(*) Alan D. Cabrera(*) Misha Nasledov Joris V.R. Mujtaba Chohan Johann Schleier-Smith Nick Dimiduk Eli Levine Steven Noels(*) Doug Meil Enis Söztutar(*) Olivier Lamy(*) Supun Kamburugamuva Imesh Gunaratne Michael Stack(*) +0s: None -1s: None With 30 +1s (13 binding) and no 0s or -1s, the vote passes. Thanks all who voted. St.Ack On Thu, Dec 5, 2013 at 1:43 PM, Stack st...@duboce.net 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
[RESULT][VOTE] Phoenix for incubator project
(Resend with fixed subject) On Wed, Dec 11, 2013 at 9:00 AM, Stack st...@duboce.net wrote: Let me vote +1 (binding) and now close the VOTE. Here are the results (* means IPMC): +1s: Roman Shaposhnik(*) James Taylor Lars Hofhansl(*) Henry Saputra(*) Leif Hedstrom(*) Anil Gupta Ted Dunning(*) Patrick Reilly Andrew Purtell(*) Ashish Anoop John Bruno Mahé Ramkrishna S. Vasudevan Jonathan Hsieh Devaraj Das(*) Sergio Fernández(*) Alan D. Cabrera(*) Misha Nasledov Joris V.R. Mujtaba Chohan Johann Schleier-Smith Nick Dimiduk Eli Levine Steven Noels(*) Doug Meil Enis Söztutar(*) Olivier Lamy(*) Supun Kamburugamuva Imesh Gunaratne Michael Stack(*) +0s: None -1s: None With 30 +1s (13 binding) and no 0s or -1s, the vote passes. Thanks all who voted. St.Ack On Thu, Dec 5, 2013 at 1:43 PM, Stack st...@duboce.net 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
JIRA Edit Permission for Storm
Would someone be able to give me permissions to edit JIRA issues for storm? Or is this something I should ask INFRA for? Username: ptgoetz Thanks in advance, Taylor signature.asc Description: Message signed with OpenPGP using GPGMail
Re: JIRA Edit Permission for Storm
Hey Taylor you are all set -Jake On Wed, Dec 11, 2013 at 4:52 PM, P. Taylor Goetz ptgo...@gmail.com wrote: Would someone be able to give me permissions to edit JIRA issues for storm? Or is this something I should ask INFRA for? Username: ptgoetz Thanks in advance, Taylor
Re: Release Verification Checklist
On Wed, Dec 11, 2013 at 1:16 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: I've just added as a plain text file in the release manifest creation section. I suggest using simpler, more active phrases for a few things at https://paste.apache.org/fBoJ - feel free to apply or not, it's mostly a question of style. I like your changes and have committed most of the patch. The one thing I left out was substantive: I did not commit the additional requirement that manifest template changes be discussed on general@incubator. Instead, I clarified that the template may be augmented rather than customized: http://s.apache.org/DWA. 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 * Add `Usage: http://incubator.apache.org/guides/release.html` link. * Change `Release:` to `Release Candidate:`. * Remove `Creation date:` because that will be tracked in SVN. * Add `Approved by Mentor:` and remove `Status: (vote in progress/canceled/released)`. Whether a vote is in progress is determined by whether the manifest has been archived. Whether it was released or not is less important than whether a Mentor has approved the manifest, making PPMC votes binding (for releases after the first). * Reverse the stacking order of `Contents` and `Reviewers and release votes` just for the sake of making the usage examples easier to write. * Move most instructions from the manifest template to the guide. * Add back the sample usage from your original wiki proposal, now inlined into the `Release Procedure` section of the guide. Thoughts? Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Release Verification Checklist
On Wed, Dec 11, 2013 at 1:20 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Looks good to me but I'd ask for a [VOTE] here before committing this. Yes. I'm supplying this patch now for comment from the people who are following these threads closely. Next, I will start a PROPOSAL thread, to re-engage with the rest of the list. Finally there will be a 7-day majority rule VOTE. I think this particular proposal is nearing maturity and do not anticipate making any more major adjustments (such as when we moved to the checklist) before calling the vote. It's not perfect but IMO it's plenty good enough to run as an experiment, and it's important that we make some incremental progress rather than hold out for a panacea. Suggestions: Call that 2013 alternate release voting process to avoid confusion. Use At least three +1 votes from PPMC members are required for the podling vote. +1, here's the updated patch... https://paste.apache.org/2J3w and here's the interdiff... https://paste.apache.org/kDAL Marvin Humphrey - 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 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
