Re: [VOTE] Apache CarbonData 0.1.0-incubating release
+1 (binding) Three things will be improved for new release (I will create the corresponding Jira): - binary file used in test (it should be generated with the test) - change headers in some files - check with the team about the origin of some code (and eventually update the NOTICE) Regards JB On 08/22/2016 05:19 PM, Jean-Baptiste Onofré wrote: Hi all, the PPMC vote to release Apache CarbonData 0.1.0-incubating has passed. Now, we kindly submit this release to the IPMC. Here's the PPMC vote thread: https://lists.apache.org/thread.html/48df7351949b2c75b9c509478d4f2e37e31330afea2478c38199fd81@%3Cdev.carbondata.apache.org%3E The source distribution, with signatures is there: https://dist.apache.org/repos/dist/dev/incubator/carbondata/0.1.0-incubating/ The git tag is: https://git-wip-us.apache.org/repos/asf?p=incubator-carbondata.git;a=commit;h=0c6f02024c657981ec8dc21536a7bfd478d2ec4a The artifacts have been signed with this key: https://dist.apache.org/repos/dist/dev/incubator/carbondata/KEYS Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Don't approve the release (please provide specific comments) This vote will be open for at least 72 hours. Thanks ! Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Hivemall Incubation Proposal
Hi Roman, Thank for the comments. 2016-08-23 2:20 GMT+09:00 Roman Shaposhnik : > Two of the areas that I'd like to explicitly solicit IPMC's opinion > on are: > 1. whether the process of re-licensing from LGPL to ALv2 > was enough given the ASF's strict IP policies The initial release was LGPL v2.1 but I changed the project license to APL v2 on Mar 16, 2015. The current codebase does not have dependencies to LGPL. I guess there are some other projects migrated from LGPL to ALv2 before becoming to Apache projects. For example, Apache OpenOffice was LGPL in the past release before joining to Apache. https://www.openoffice.org/license.html > 2. whether the 5 initial committers make sense given that > there's a total of 15 contributors as per GitHub stats. The current 5 initial committers are who made significant feature improvements (e.g., pig/spark support) or continuously contributing patches to Hivemall. Some of intern students of my company are contributed significantly to the project but they are not contributing continuously after the intern period. So, I'm not selecting them as initial committers. Our intent of this incubator proposal is building a diverse developer community following the Apache meritocracy model. We welcome external contributions (including past intern students) and plan to elect committers from those who contributed significantly to the project during and/or after the incubation process. Thanks, Makoto -- Makoto YUI Research Engineer, Treasure Data, Inc. http://myui.github.io/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Hivemall Incubation Proposal
On Tue, Aug 23, 2016 at 1:22 AM, Makoto Yui wrote: > 2016-08-23 2:20 GMT+09:00 Roman Shaposhnik : >> Two of the areas that I'd like to explicitly solicit IPMC's opinion >> on are: >> >> 1. whether the process of re-licensing from LGPL to ALv2 >> was enough given the ASF's strict IP policies > > The initial release was LGPL v2.1 but I changed the project license > to APL v2 on Mar 16, 2015. > The current codebase does not have dependencies to LGPL. > > I guess there are some other projects migrated from LGPL to ALv2 > before becoming to Apache projects. > > For example, Apache OpenOffice was LGPL in the past release > before joining to Apache. > https://www.openoffice.org/license.html To make a codebase available under an additional license, you need the permission of all copyright holders. While it was overseen by Sun and Oracle, OpenOffice.org required copyright assignment -- so at the time it came to the ASF, Oracle was the sole copyright holder. That gave Oracle the ability to issue the new license unilaterally. If a codebase has multiple copyright holders, you have to track them all down individually and secure permission. If there are any people whose permission cannot be obtained, then their contributions must be excised and replaced, if possible. This has been done for several projects at the ASF, but it's not easy. Two questions present themselves regarding the relicensing of Hivemall. Who were the copyright holders at the time of relicensing? How was their permission secured? Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache CarbonData 0.1.0-incubating release
Hi, > - check with the team about the origin of some code (and eventually update > the NOTICE) There’s probably no need to add anything to NOTICE as openCSV doesn’t have a NOTICE file. [1][2] Thanks, Justin 1. http://www.apache.org/dev/licensing-howto.html#alv2-dep 2. https://sourceforge.net/p/opencsv/source/ci/master/tree/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache CarbonData 0.1.0-incubating release
Agreed for OpenCSV, but I would like to check if there's no other code coming from other projects. Regards JB On 08/23/2016 02:32 PM, Justin Mclean wrote: Hi, - check with the team about the origin of some code (and eventually update the NOTICE) There’s probably no need to add anything to NOTICE as openCSV doesn’t have a NOTICE file. [1][2] Thanks, Justin 1. http://www.apache.org/dev/licensing-howto.html#alv2-dep 2. https://sourceforge.net/p/opencsv/source/ci/master/tree/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Hivemall Incubation Proposal
Hi Marvin, I'm going to answer your two questions. > 1) Who were the copyright holders at the time of relicensing? At the time of re-licensing, the copyright holder was AIST, my employer at that time. > 2) How was their permission secured? Hivemall was at that time my solo research project at AIST. I took a permission to change the license to ALv2 from AIST then. I did some paper works and I'm still holding it. Unfortunately, it's written in Japanese. They also agreed to move Hivemall to Apache Incubator. I'm considering to take Software Grant Agreement sign from them in the incubation process. Does it wipe out your concerns? Thanks, Makoto 2016-08-23 21:18 GMT+09:00 Marvin Humphrey : > On Tue, Aug 23, 2016 at 1:22 AM, Makoto Yui wrote: > >> 2016-08-23 2:20 GMT+09:00 Roman Shaposhnik : >>> Two of the areas that I'd like to explicitly solicit IPMC's opinion >>> on are: >>> >>> 1. whether the process of re-licensing from LGPL to ALv2 >>> was enough given the ASF's strict IP policies >> >> The initial release was LGPL v2.1 but I changed the project license >> to APL v2 on Mar 16, 2015. >> The current codebase does not have dependencies to LGPL. >> >> I guess there are some other projects migrated from LGPL to ALv2 >> before becoming to Apache projects. >> >> For example, Apache OpenOffice was LGPL in the past release >> before joining to Apache. >> https://www.openoffice.org/license.html > > To make a codebase available under an additional license, you need the > permission of all copyright holders. While it was overseen by Sun and > Oracle, OpenOffice.org required copyright assignment -- so at the time > it came to the ASF, Oracle was the sole copyright holder. That gave > Oracle the ability to issue the new license unilaterally. > > If a codebase has multiple copyright holders, you have to track them > all down individually and secure permission. If there are any people > whose permission cannot be obtained, then their contributions must be > excised and replaced, if possible. This has been done for several > projects at the ASF, but it's not easy. > > Two questions present themselves regarding the relicensing of > Hivemall. Who were the copyright holders at the time of relicensing? > How was their permission secured? > > Marvin Humphrey > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Makoto YUI Research Engineer, Treasure Data, Inc. http://myui.github.io/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT][VOTE] Accept ARIA-TOSCA into the Apache Incubator
With 3 +1 binding votes, and NO -1 and/or +-0 votes I believe this VOTE passes. Thanks to everyone who voted. Here's the tally: +1 binding: Jakob Homan Suneel Marthi John D. Ament Thanks, Arthur On Tue, Aug 16, 2016 at 9:19 PM John D. Ament wrote: > +1 look forward to seeing something like this in Apache. Great addition. > > John > > On Mon, Aug 15, 2016 at 12:51 PM Arthur Berezin > wrote: > > > Hi all, > > > > Looks like the discussion thread on ARIA TOSCA has ended. > > > > > https://lists.apache.org/thread.html/565967fcfae288eb642bcca2ee2e6b76b49ca80843cb4b16dbee77c5@%3Cgeneral.incubator.apache.org%3E > > > > > > I would like to call a vote on accepting ARIA TOSCA into the Apache > > Incubator. > > > > This vote will run for the usual 72 hours. Please VOTE as follows > > [ ] +1 Accept ARIA TOSCA into the Apache Incubator > > [ ] +/-0 Not overly bothered either way > > [ ] -1 DO NOT accept ARIA TOSCA into the Apache Incubator (please state > > why) > > > > Thanks everyone who is able to participate in this VOTE. > > Arthur Berezin > > > > > > ### PROPOSAL ### > > > > = ARIA TOSCA = > > > > === Abstract === > > ARIA's mission statement is to drive the adoption of TOSCA by offering an > > easily consumable Software Development Kit(SDK) and a Command Line > > Interface(CLI) to implement TOSCA based solutions which will help in > market > > consolidation around TOSCA based Orchestration. > > One of the key attributes of the TOSCA specification by OASIS is that it > is > > a vendor neutral and technology agnostic specification, allowing to > > describe applications and then to orchestrate them using various > > technologies of choice, such as Amazon AWS, Google GCP, OpenStack, > VMware, > > Puppet, Ansible Chef, etc’. > > The reality is such that TOSCA is a complex specification,making software > > vendors trying to implement the specification take implementation > > decisions, ending up with different and incompatible implementations, > > creating even more market segmentation instead of consolidating around a > > single standard for orchestration. > > ARIA is an open source python library that helps orchestrators and > > management tools developed TOSCA enabled orchestration solutions. ARIA > aims > > to become the main reference implementation of the OASIS TOSCA(Topology > and > > Orchestration Specification for Cloud Applications) specification for > > orchestrating cloud applications, and descriptor for VNFs in Telecom NFV. > > ARIA can be executed via CLI to orchestrate application templates, > > additionally it allows embedding its python library code for creating > TOSCA > > compatible services, and includes rich set of plugins for Iaas > > orchestration, such as Amazon AWS, Google GCP, OpenStack and VMWare; It > > Includes plugins for Container orchestration, with Docker and Kubernetes > > plugins, configuration management tools(Puppet,Chef, Ansible) and a rich > > API that allows to create plugins for any new technology. > > ARIA serves as a code base that allows to test the TOSCA specification > and > > experiment with new approaches to modeling and orchestration of > > applications, providing feedback and real world use cases OASIS to > further > > refine and advance the standard specification. > > > > === Proposal === > > ARIA offers a command line tool and a set of embeddable python libraries > > implementing an engine for orchestration using TOSCA declarative language > > blueprints. > > TOSCA allows describing application’s topology with its interconnections > > and interactions among multiple components using declarative language. > This > > involves combining tasks into workflows, provisioning and management of > > various components and their associated resources in an automated manner, > > and in multi-cloud environments it involves interconnecting processes > > running across heterogeneous systems in multiple locations. > > > > ARIA aims to implement several main use cases, and can be used as a > command > > line tool to orchestrate TOSCA based application templates serving as a > > lightweight tool to onboard and orchestrate applications in a repeatable > > and robust manner. ARIA can be used by software vendors and VNF providers > > as a development environment for creating TOSCA templates for onboarding > > and managing the lifecycle of software products and Virtual Network > > Functions(VNFs). > > Additionally ARIA can be used for building orchestration platforms and > > enabling TOSCA based orchestration using the ARIA TOSCA orchestration > > engine as the kernel of the orchestrator. > > > > ''' ARIA TOSCA Parser ''' > > ARIA includes a TOSCA DSL parser, the parser’s role is to interpret the > > TOSCA template, create an in-memory graph of the application and validate > > templates’ correctness. TOSCA provides a type system of normative node > > types to describe the possible building blocks for constructing a service > > template, as well as relationship types to describe
Is the incubator full?
All, I'm wondering if the Apache Incubator is full right now? I've noticed a few things: - There was a note a few months ago that the incubator does have a max capacity. At that point, things start to slow down. - The discussions involved when a new project comes in have dwindled. - The number of eyes looking at releases have reduced. So I wonder, is the incubator full? Has capacity plateaued and we should discourage projects from joining? Are there projects that we should strongly encourage to graduate? John
Re: Is the incubator full?
Hi John, Fair question. I think we accepted lot of projects in the incubator recently. IMHO, the first action to do is to check with the current podlings the ones ready to graduate. I think we have at least 2 or 3 podlings ready. On the other hand, we can also double check the global podling activity. WDYT ? Regards JB On 08/23/2016 04:26 PM, John D. Ament wrote: All, I'm wondering if the Apache Incubator is full right now? I've noticed a few things: - There was a note a few months ago that the incubator does have a max capacity. At that point, things start to slow down. - The discussions involved when a new project comes in have dwindled. - The number of eyes looking at releases have reduced. So I wonder, is the incubator full? Has capacity plateaued and we should discourage projects from joining? Are there projects that we should strongly encourage to graduate? John -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[ANNOUNCE] Apache Geode 1.0.0-incubating.M3 released
The Apache Geode team is proud to announce Apache Geode release 1.0.0-incubating.M3. Apache Geode (incubating) is a data management platform that provides a database-like consistency model, reliable transaction processing and a shared-nothing architecture to maintain very low latency performance with high concurrency processing. Download the new release here: http://geode.incubator.apache.org/releases/ Changes since the last release include improvements to role-based access control, enhanced Apache Lucene integration, support for Apache Tomcat 8 session caching, and many bug fixes and minor improvements. See the release notes for more details: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420&version=12335358 To get started with Apache Geode check out the Geode in 5 minutes tutorial: https://cwiki.apache.org/confluence/display/GEODE/Index#Index-Geodein5minutesGeodein5minutes To learn more and get involved, please visit our website in join our mailing lists: http://geode.incubator.apache.org/ Regards, The Apache Geode (incubating) team = *Disclaimer* Apache Geode is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the name of Apache Incubator PMC. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Hivemall Incubation Proposal
On Tue, Aug 23, 2016 at 6:08 AM, Makoto Yui wrote: > Hi Marvin, > > I'm going to answer your two questions. > >> 1) Who were the copyright holders at the time of relicensing? > > At the time of re-licensing, the copyright holder was AIST, > my employer at that time. Looking at the Github history, though, it seems that there were pull requests and issues file by others prior to the Mar 16, 2015 relicensing. Were there any contributions made before then by people not employed by AIST? If everyone worked for AIST, then there is no problem. However, if there were substantial (copyrightable) contributions from people not employed by AIST pre-dating the relicensing, then it will be necessary to contact the copyright holders and secure their permission to license under the ALv2. So long as it is possible to figure out the true origin of all code from the project history, problems of permission can usually be resolved. What's more difficult to resolve is stuff like copy/pasting without attribution, so that code from somewhere else appears to be the work of a different author. (I have no reason to think any such issues exist other than the mild confusion of this thread, which could arise due to many factors including the language barrier or my own misunderstandings.) If you know of anything like that in the project history I'd suggest communicating privately. If not, then no problem. >> 2) How was their permission secured? > > Hivemall was at that time my solo research project at AIST. > I took a permission to change the license to ALv2 from AIST then. > > I did some paper works and I'm still holding it. > Unfortunately, it's written in Japanese. > > They also agreed to move Hivemall to Apache Incubator. Excellent -- it's great that AIST supports open source software! > I'm considering to take Software Grant Agreement sign from them > in the incubation process. That would be appropriate. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Hivemall Incubation Proposal
Hi Marvin, 2016-08-24 1:23 GMT+09:00 Marvin Humphrey : > Looking at the Github history, though, it seems that there were pull requests > and issues file by others prior to the Mar 16, 2015 relicensing. Were there > any contributions made before then by people not employed by AIST? > > If everyone worked for AIST, then there is no problem. However, if there were > substantial (copyrightable) contributions from people not employed by AIST > pre-dating the relicensing, then it will be necessary to contact the copyright > holders and secure their permission to license under the ALv2. There are 5 individuals, excluding project committers, sent pull requests to the project before moving to ALv2: smly, y-tag, ryukobayashi, spiritloose, and takahi-i. All of contributions are recorded in github and there are no other contributions that are not listed in github. So, I can try to get I-CLA from them, in addition to committer's I-CLA sign, in the incubation process. I think I can get permissions from them. Is I-CLA adequate or e-mail based confirmation is enough? https://www.apache.org/licenses/icla.txt > So long as it is possible to figure out the true origin of all code from the > project history, problems of permission can usually be resolved. What's more > difficult to resolve is stuff like copy/pasting without attribution, so that > code from somewhere else appears to be the work of a different author. (I > have no reason to think any such issues exist other than the mild confusion of > this thread, which could arise due to many factors including the language > barrier or my own misunderstandings.) If you know of anything like that in > the > project history I'd suggest communicating privately. If not, then no problem. I think what we have to do is listing Copyrights and Licenses in NOTICE file as seen in https://github.com/apache/spark/blob/master/NOTICE#L86 Is my understanding right? All copyrights are left in the code and borrowed codes are licensed MIT/BSD/Apache licenses only. We can list them to NOTICE file. I never borrowed or used GPL/LGPL/MPL licensed codes, always taking care of it. To summarize your concern, we have three things to do during the incubation process: 1) getting SGA from AIST, 2) getting I-CLA from contributors/committers, and 3) listing dependencies in the NOTICE file. We can remove or rewrite if there are some codes that should not be used in the Apache project, e.g., GPL licensed one. I think there are not such code in Hivemall though. Thanks, Makoto -- Makoto YUI Research Engineer, Treasure Data, Inc. http://myui.github.io/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Ease of release process and exit criteria
+1 Especially for point 2, adding to the maturity model. Finding a release manager can be a problem, but is also an opportunity: a committer who wants to become more involved with project governance can volunteer to be RM. A well-functioning project makes this process as smooth as possible. Julian > On Aug 20, 2016, at 12:59 PM, Mark Thomas wrote: > > All, > > It seems there is general consensus that this is a good idea. I'm > therefore going to do the following. > > 1. Draft some text to add to > http://incubator.apache.org/guides/graduation.html#releases > and bring that back to this list for discussion > > 2. Start a thread on dev@community about adding an item to the project > maturity model. > > 3. Identify somewhere to put all the good suggestions for, and links to > examples of, smooth release processes and then pull all the links > and suggestions from this thread to that place. I have a vague > recollection of seeing such a thing previously. I'll need to do some > digging to see it I can find it. Any hints? > > Mark > > > On 19/08/2016 21:41, Dave Fisher wrote: >> I know of a podling like that where the release manager gave me push back >> until I told him I could not vote +1 without build instructions I could at >> least follow on my own local. >> >> That was some years ago. The podling graduated. The instructions were not >> updated. The RM left. Now there is a bind. >> >> A requirement is a good idea, but it is no guarantee that the instructions >> remain up to date. >> >> Suggestions: >> >> Is this info for the maturity model? >> Should there be special and higher standards to make binary releases >> "official"? >> >> Regards, >> Dave >> >> Sent from my iPhone >> >>> On Aug 19, 2016, at 8:41 AM, Dennis E. Hamilton >>> wrote: >>> >>> +1 to this, including the posts from Mark and Bertrand. >>> >>> I know of a project where this would have made a serious difference for >>> graduation and subsequent sustainability. >>> >>> - Dennis >>> -Original Message- From: Shane Curcuru [mailto:a...@shanecurcuru.org] Sent: Friday, August 19, 2016 07:08 To: general@incubator.apache.org Subject: Re: Ease of release process and exit criteria Bertrand Delacretaz wrote on 8/19/16 5:57 AM: > Hi Mark, > > On Fri, Aug 19, 2016 at 11:23 AM, Mark Thomas wrote: >> ...I'm thinking of a graduation criteria long the lines of: >> "Is the release process clearly documented to the point that someone new >> to the project could produce a release build?"... +1, this is a critical point to include. We continue to see projects struggling with releases when early volunteers leave and no-one else really understands releases. ...snip... > How about also adding an RE50 item to > https://community.apache.org/apache-way/apache-project-maturity- model.html > about a repeatable release process? That's a discussion for > community.a.o but what's your opinion? +1, this is both important to include philosophically as well as practically. I.e. it's an important reminder that project technical procedures need to be understandable by the *whole* community, not just the first few developers who created the project. - Shane - 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 >> > > > - > 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: [DISCUSS] Hivemall Incubation Proposal
On Tue, Aug 23, 2016 at 11:09 AM, Makoto Yui wrote: > Hi Marvin, > > 2016-08-24 1:23 GMT+09:00 Marvin Humphrey : >> Looking at the Github history, though, it seems that there were pull requests >> and issues file by others prior to the Mar 16, 2015 relicensing. Were there >> any contributions made before then by people not employed by AIST? >> >> If everyone worked for AIST, then there is no problem. However, if there >> were >> substantial (copyrightable) contributions from people not employed by AIST >> pre-dating the relicensing, then it will be necessary to contact the >> copyright >> holders and secure their permission to license under the ALv2. > > There are 5 individuals, excluding project committers, sent pull requests > to the project before moving to ALv2: smly, y-tag, ryukobayashi, > spiritloose, and takahi-i. > > All of contributions are recorded in github and there are no other > contributions > that are not listed in github. > > So, I can try to get I-CLA from them, in addition to committer's I-CLA sign, > in the incubation process. I think I can get permissions from them. > > Is I-CLA adequate or e-mail based confirmation is enough? > https://www.apache.org/licenses/icla.txt At this point what we really need from them is the agreement to license their work out to ASF. This is what SGA is typically for. I see no problem with multiple SGAs being sent to the ASF secretary. One from your company and one from each individual contributor. >> So long as it is possible to figure out the true origin of all code from the >> project history, problems of permission can usually be resolved. What's more >> difficult to resolve is stuff like copy/pasting without attribution, so that >> code from somewhere else appears to be the work of a different author. (I >> have no reason to think any such issues exist other than the mild confusion >> of >> this thread, which could arise due to many factors including the language >> barrier or my own misunderstandings.) If you know of anything like that in >> the >> project history I'd suggest communicating privately. If not, then no >> problem. > > I think what we have to do is listing Copyrights and Licenses in NOTICE file > as seen in > https://github.com/apache/spark/blob/master/NOTICE#L86 > > Is my understanding right? > > All copyrights are left in the code and borrowed codes are licensed > MIT/BSD/Apache licenses only. We can list them to NOTICE file. > > I never borrowed or used GPL/LGPL/MPL licensed codes, always taking care of > it. > > To summarize your concern, we have three things to do during the > incubation process: > 1) getting SGA from AIST, > 2) getting I-CLA from contributors/committers, and > 3) listing dependencies in the NOTICE file. > > We can remove or rewrite if there are some codes that should not be used > in the Apache project, e.g., GPL licensed one. > I think there are not such code in Hivemall though. You're on the right track. Also, if the IP is clean, the mechanical portion of making sure the project's LICENSE and NOTICE files are correct can be done as part of your first steps in the Incubator. This will hold your first release out of ASF, but will not block you from entering the Incubation. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Ease of release process and exit criteria
I wonder if the requirement might be better phrased along the lines of "must have releases completed by a total of > 2 release managers". Asking people if their documentation is correct and complete almost always results in a yes answer and a moral onus on the questioner to either accept that answer or go to the trouble of verifying if it is true. The reliability of this as a cross check is not worth having a requirement. Asking for names of people who have built the release, or better yet, run the process is much harder to sandbag. The word "sandbag" here should be pronounced to rhyme with "optimism" and isn't usually an intentional sort of deception. On Tue, Aug 23, 2016 at 12:56 PM, Julian Hyde wrote: > +1 Especially for point 2, adding to the maturity model. > > Finding a release manager can be a problem, but is also an opportunity: a > committer who wants to become more involved with project governance can > volunteer to be RM. A well-functioning project makes this process as smooth > as possible. > > Julian > > > On Aug 20, 2016, at 12:59 PM, Mark Thomas wrote: > > > > All, > > > > It seems there is general consensus that this is a good idea. I'm > > therefore going to do the following. > > > > 1. Draft some text to add to > > http://incubator.apache.org/guides/graduation.html#releases > > and bring that back to this list for discussion > > > > 2. Start a thread on dev@community about adding an item to the project > > maturity model. > > > > 3. Identify somewhere to put all the good suggestions for, and links to > > examples of, smooth release processes and then pull all the links > > and suggestions from this thread to that place. I have a vague > > recollection of seeing such a thing previously. I'll need to do some > > digging to see it I can find it. Any hints? > > > > Mark > > > > > > On 19/08/2016 21:41, Dave Fisher wrote: > >> I know of a podling like that where the release manager gave me push > back until I told him I could not vote +1 without build instructions I > could at least follow on my own local. > >> > >> That was some years ago. The podling graduated. The instructions were > not updated. The RM left. Now there is a bind. > >> > >> A requirement is a good idea, but it is no guarantee that the > instructions remain up to date. > >> > >> Suggestions: > >> > >> Is this info for the maturity model? > >> Should there be special and higher standards to make binary releases > "official"? > >> > >> Regards, > >> Dave > >> > >> Sent from my iPhone > >> > >>> On Aug 19, 2016, at 8:41 AM, Dennis E. Hamilton < > dennis.hamil...@acm.org> wrote: > >>> > >>> +1 to this, including the posts from Mark and Bertrand. > >>> > >>> I know of a project where this would have made a serious difference > for graduation and subsequent sustainability. > >>> > >>> - Dennis > >>> > -Original Message- > From: Shane Curcuru [mailto:a...@shanecurcuru.org] > Sent: Friday, August 19, 2016 07:08 > To: general@incubator.apache.org > Subject: Re: Ease of release process and exit criteria > > Bertrand Delacretaz wrote on 8/19/16 5:57 AM: > > Hi Mark, > > > > On Fri, Aug 19, 2016 at 11:23 AM, Mark Thomas > wrote: > >> ...I'm thinking of a graduation criteria long the lines of: > >> "Is the release process clearly documented to the point that someone > new > >> to the project could produce a release build?"... > > +1, this is a critical point to include. We continue to see projects > struggling with releases when early volunteers leave and no-one else > really understands releases. > > ...snip... > > How about also adding an RE50 item to > > https://community.apache.org/apache-way/apache-project-maturity- > model.html > > about a repeatable release process? That's a discussion for > > community.a.o but what's your opinion? > > +1, this is both important to include philosophically as well as > practically. I.e. it's an important reminder that project technical > procedures need to be understandable by the *whole* community, not > just > the first few developers who created the project. > > - Shane > > - > 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: [DISCUSS] Hivemall Incubation Proposal
Hi, > I think what we have to do is listing Copyrights and Licenses in NOTICE file > as seen in > https://github.com/apache/spark/blob/master/NOTICE#L86 > > Is my understanding right? No, that notice file is IMO a poor example to copy from. MIT and BSD licenses need to be mentioned in LICENSE not NOTICE [1], Apache licensed software generally only needs to be mentioned in NOTICE if it has it’s own NOTICE file. [2] This can be sorted out during incubation. > 3) listing dependencies in the NOTICE file. Only bundled files (i.e. things in the actual release) should be listed, dependancies do not need to be listed. [3] Thanks, Justin 1. http://www.apache.org/dev/licensing-howto.html#permissive-deps 2. http://www.apache.org/dev/licensing-howto.html#alv2-dep 3. http://www.apache.org/dev/licensing-howto.html#guiding-principle - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Hivemall Incubation Proposal
On Tue, Aug 23, 2016 at 11:09 AM, Makoto Yui wrote: > There are 5 individuals, excluding project committers, sent pull requests > to the project before moving to ALv2: smly, y-tag, ryukobayashi, > spiritloose, and takahi-i. I assume that all the "project committers" (if that group is more than just you) were employed by AIST and that the copyright for any code they authored is owned by AIST. > All of contributions are recorded in github and there are no other > contributions > that are not listed in github. > > So, I can try to get I-CLA from them, in addition to committer's I-CLA sign, > in the incubation process. I think I can get permissions from them. > > Is I-CLA adequate or e-mail based confirmation is enough? > https://www.apache.org/licenses/icla.txt This doesn't have to be dealt with before entry into the Incubator. All that's required is a *plan* -- and it seems to me that there's enough of a plan to get started. Another detail is that very small contributions may not be copyrightable and thus may not require relicensing. Again, that can be dealt with later. Good luck! Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Hivemall Incubation Proposal
On Tue, Aug 23, 2016 at 5:49 PM, Marvin Humphrey wrote: > On Tue, Aug 23, 2016 at 11:09 AM, Makoto Yui wrote: > >> There are 5 individuals, excluding project committers, sent pull requests >> to the project before moving to ALv2: smly, y-tag, ryukobayashi, >> spiritloose, and takahi-i. > > I assume that all the "project committers" This is NOT my understanding. Makoto, could you please clarify one way or the other? Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Ease of release process and exit criteria
On Tue, Aug 23, 2016 at 2:02 PM, Ted Dunning wrote: > I wonder if the requirement might be better phrased along the lines of > "must have releases completed by a total of > 2 release managers". I really like this criteria and use it extensively with my podlings. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
