Re: Tool to generate disclaimer, NOTICE, etc. files
-- Forwarded message -- From: Marvin Humphrey mar...@rectangular.com Date: Feb 10, 2014 3:49 PM Subject: Re: Tool to generate disclaimer, NOTICE, etc. files To: general@incubator.apache.org general@incubator.apache.org Cc: On Sat, Feb 8, 2014 at 8:49 AM, Alan Cabrera l...@toolazydogs.com wrote: Do you think it would be helpful if we had a tool that generated these files? It could work like a command line wizard that prompts the person for licensing information and then generates a valid disclaimer, notice, etc. files. If this is a good idea, what files should we generate? Currently, all I can think of is disclaimer and notice. chiming in here (without much context so it may not be what you are looking for), but in cloudstack we have a CHANGES file with list of bugs fixed. While we can argue if this is needed or not, I created a quick script to pull jira information from a filter: https://git-wip-us.apache.org/repos/asf?p=cloudstack-docs-rn.git;a=blob_plain;f=utils/jira.py;hb=refs/heads/master it then automatically populates our doc: http://apache-cloudstack-release-notes.readthedocs.org/en/latest/about.html#issues-fixed-in-4-3-0 Maybe it could add the info into the project's DOAP file. If we worked out the kinks then we could create sbt/gradle/mvn plugins to read the DOAP file and insert these files into the correct places in the distributions. Apache RAT could also use this info as well. WDYT? I concur with sebb on the extreme challenges of auto-generating NOTICE -- which is a shame because I'd really love it if the Incubator could benefit when you're inspired to write tooling. One thing I think we could use is a tool which parses mbox archives in people.apache.org:/home/apmail/ and generates statistics: * Total emails sent per list (a measure of activity) * Unique addresses participating (a measure of diversity) * Emails sent by Mentors (a measure of Mentor engagement) I have been doing this for CloudStack, I download all mbox files at the end of the month, parse and stick in mongodb. I than run couple queries. You can see examples at: http://sebgoa.blogspot.ch/2013/05/update-on-apache-cloudstack-community.html The code is a bit of a mess so I did not put it on github. however I did put asf-mail-spider: https://github.com/runseb/asf-mail-spider It crawls the apache mail archive site and collects the names of all the asf making lists, then goes into each one of them and extracts the number of messages each month. Then plots a very messy graph. You could easily focus on the incubator projects and plot that same graph that would give you Total emails sent per list. We expend a lot of volunteer energy on shepherding each month, and I think such an automated tool could help to free up some of that energy for other tasks. There are two main functions for shepherding: 1. Alert the IPMC to podlings which have gone adrift. 2. Provide an outsider view. (I'd add a #3: being exposed to new communities benefits the shepherd, but that varies by individual.) I think that purpose #1 could largely be accomplished using email stats. I don't know if this is something you'd feel motivated to work on, but I thought it was worth mentioning because your original proposal would save time and energy and so would this. Marvin Humphrey - 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
How to handle module contributions
My apologies if this has been asked before or is well documented somewhere. If it is I couldn't find it. What is the process for handling contrib module code donations from an IP clearance perspective? Example #1 (https://github.com/ptgoetz/storm-jms) An individual (me in this case) wishes to donate code that is licensed under the EPL, and has had a few contributions (no CLAs). Is switching to Apache v2 license and adding license headers all that would be necessary? Example #2 (https://github.com/hmsonline/storm-cassandra) Same story as the previous example, except this time it is a corporate entity. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: How to handle module contributions
My apologies if this has been asked before or is well documented somewhere. If it is I couldn't find it. What is the process for handling contrib module code donations from an IP clearance perspective? Example #1 (https://github.com/ptgoetz/storm-jms) An individual (me in this case) wishes to donate code that is licensed under the EPL, and has had a few contributions (no CLAs). Is switching to Apache v2 license and adding license headers all that would be necessary? Example #2 (https://github.com/hmsonline/storm-cassandra) Same story as the previous example, except this time it is a corporate entity. The project has transitioned to the Apache license. In each case, what is necessary to incorporate the code into an incubator project? (Sorry for the double post, I hit send accidentally.) -Taylor
Re: How to handle module contributions
The basic idea is that you have to have the right to incorporate the code and be able to demonstrate that right. For example #1, you can switch your contributions to ASL2 and be good, but you may have problems with the contributions of the others unless the contributions are trivial. For example #2, it is typically necessary to get a specific grant licensing the code to Apache. If the corporate entity were to relicense the code being donated under ASL2, that would suffice, but a letter indicating intent to donate would be nice. Others may have additional opinions so don't assume my answer is definitive. On Mon, Feb 17, 2014 at 3:04 PM, P. Taylor Goetz ptgo...@gmail.com wrote: My apologies if this has been asked before or is well documented somewhere. If it is I couldn't find it. What is the process for handling contrib module code donations from an IP clearance perspective? Example #1 (https://github.com/ptgoetz/storm-jms) An individual (me in this case) wishes to donate code that is licensed under the EPL, and has had a few contributions (no CLAs). Is switching to Apache v2 license and adding license headers all that would be necessary? Example #2 (https://github.com/hmsonline/storm-cassandra) Same story as the previous example, except this time it is a corporate entity. The project has transitioned to the Apache license. In each case, what is necessary to incorporate the code into an incubator project? (Sorry for the double post, I hit send accidentally.) -Taylor
Re: [VOTE] Release of Apache Allura 1.1.0 incubating
On 2/16/14 6:28 AM, Daniel Gruno wrote: -1. files check out, but Allura doesn't work :( checksums match, installation works, though not very well on ubuntu minimal 13.10, dependencies cannot be met, I had to rewrite requiements-common.txt to use Ming 0.4.3 instead of 0.4.2 which doesn't exist, and libtidy was changed to 0.1.2 as 0.2.1 wasn't available. Not sure why Ming 0.4.2 wasn't available for you. Can you provide more details of how you tried to install it and what the error was? I see it at https://pypi.python.org/pypi/Ming/0.4.2 and this works fine for me as a simple test: $ virtualenv /tmp/venv $ source /tmp/venv/bin/activate $ pip install Ming==0.4.2 And https://pypi.python.org/pypi/pytidylib/ is there, for 0.2.1 Created account, created project, went to admin it...and FAILURE! Line 913 in allura/lib/plugin has else: , when it should have elif app in g.entry_points['tool']: - it breaks the entire site when viewing the admin tab. I have checked on multiple machines, and I get this error all the time. That does look like a good change. I presume when you were installing and the INSTALL said And now to setup the Allura applications for development. If you want to setup all of them, run `./rebuild-all.bash` that you chose the 2nd option to just install individual tools and didn't install all of them (e.g. ForgeTracker)? If all were installed, I don't think you'd get an error there. -Dave With regards, Daniel. On 02/13/2014 02:06 AM, Dave Brondsema wrote: Hi everyone, This is a call for a vote on Apache Allura 1.1.0 incubating. This will be our second release in the incubator. Allura is forge software for the development of software projects, including source control systems, issue tracking, discussion, wiki, and other software project management tools. A vote was held on developer mailing list and it passed with 7 +1's, and no -1's or +0's. 1 vote was from an IPMC member (me). Vote thread: http://mail-archives.apache.org/mod_mbox/incubator-allura-dev/201402.mbox/%3C52F15D4C.7060906%40brondsema.net%3E Result thread: http://mail-archives.apache.org/mod_mbox/incubator-allura-dev/201402.mbox/%3C52FBA8A9.502%40brondsema.net%3E Source tarball, signature and checksums are available at: https://dist.apache.org/repos/dist/dev/incubator/allura/ Checksums: MD5:ea72b33323dc8c85ad26d08de4bbc534 SHA1: 170729db7c7b26fc3244293bc0a37989121d3973 SHA512: 24b65e731d2ec5df33ab4959b0edd72ec5fee58ae5ce704b10ef45ecc07259357a645d4989935423a6be7d4f1add8b2512578b9b2133ac5059f6d3c6d7235934 The KEYS file can be found at: http://www.apache.org/dist/incubator/allura/KEYS The release has been signed with key (9BB3CE70): http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x56F0526F9BB3CE70 Source corresponding to this release can be found at: Commit: a2bc6726d63298638bacf4d02e697e92aaee0bf4 Tag:asf_release_1.1.0 Browse: https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=shortlog;h=refs/tags/asf_release_1.1.0 The RAT report is available at: https://sourceforge.net/p/allura/pastebin/52f15c143e5e833783530b74 Vote will be open for at least 72 hours: [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Dave Brondsema : d...@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: How to handle module contributions
Thanks Ted. Regarding contributions, if someone contributes (e.g. A pull request) to a project with an established license, couldn't that be considered an implicit grant of rights unless otherwise specified (e.g. License headers)? -Taylor On Feb 17, 2014, at 6:19 PM, Ted Dunning ted.dunn...@gmail.com wrote: The basic idea is that you have to have the right to incorporate the code and be able to demonstrate that right. For example #1, you can switch your contributions to ASL2 and be good, but you may have problems with the contributions of the others unless the contributions are trivial. For example #2, it is typically necessary to get a specific grant licensing the code to Apache. If the corporate entity were to relicense the code being donated under ASL2, that would suffice, but a letter indicating intent to donate would be nice. Others may have additional opinions so don't assume my answer is definitive. On Mon, Feb 17, 2014 at 3:04 PM, P. Taylor Goetz ptgo...@gmail.com wrote: My apologies if this has been asked before or is well documented somewhere. If it is I couldn't find it. What is the process for handling contrib module code donations from an IP clearance perspective? Example #1 (https://github.com/ptgoetz/storm-jms) An individual (me in this case) wishes to donate code that is licensed under the EPL, and has had a few contributions (no CLAs). Is switching to Apache v2 license and adding license headers all that would be necessary? Example #2 (https://github.com/hmsonline/storm-cassandra) Same story as the previous example, except this time it is a corporate entity. The project has transitioned to the Apache license. In each case, what is necessary to incorporate the code into an incubator project? (Sorry for the double post, I hit send accidentally.) -Taylor - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: How to handle module contributions
Judgement call depending on what you might consider a reasonable size for a minor fix versus an independent work (e.g. new module). The larger the patch the more likely you should consider having the author file some paperwork with Apache to cover the contribution. HTH On Feb 17, 2014, at 7:20 PM, P. Taylor Goetz ptgo...@gmail.com wrote: Thanks Ted. Regarding contributions, if someone contributes (e.g. A pull request) to a project with an established license, couldn't that be considered an implicit grant of rights unless otherwise specified (e.g. License headers)? -Taylor On Feb 17, 2014, at 6:19 PM, Ted Dunning ted.dunn...@gmail.com wrote: The basic idea is that you have to have the right to incorporate the code and be able to demonstrate that right. For example #1, you can switch your contributions to ASL2 and be good, but you may have problems with the contributions of the others unless the contributions are trivial. For example #2, it is typically necessary to get a specific grant licensing the code to Apache. If the corporate entity were to relicense the code being donated under ASL2, that would suffice, but a letter indicating intent to donate would be nice. Others may have additional opinions so don't assume my answer is definitive. On Mon, Feb 17, 2014 at 3:04 PM, P. Taylor Goetz ptgo...@gmail.com wrote: My apologies if this has been asked before or is well documented somewhere. If it is I couldn't find it. What is the process for handling contrib module code donations from an IP clearance perspective? Example #1 (https://github.com/ptgoetz/storm-jms) An individual (me in this case) wishes to donate code that is licensed under the EPL, and has had a few contributions (no CLAs). Is switching to Apache v2 license and adding license headers all that would be necessary? Example #2 (https://github.com/hmsonline/storm-cassandra) Same story as the previous example, except this time it is a corporate entity. The project has transitioned to the Apache license. In each case, what is necessary to incorporate the code into an incubator project? (Sorry for the double post, I hit send accidentally.) -Taylor - 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: How to handle module contributions
yeah. What Joe said. On Mon, Feb 17, 2014 at 4:27 PM, Joseph Schaefer joe_schae...@yahoo.comwrote: Judgement call depending on what you might consider a reasonable size for a minor fix versus an independent work (e.g. new module). The larger the patch the more likely you should consider having the author file some paperwork with Apache to cover the contribution. HTH On Feb 17, 2014, at 7:20 PM, P. Taylor Goetz ptgo...@gmail.com wrote: Thanks Ted. Regarding contributions, if someone contributes (e.g. A pull request) to a project with an established license, couldn't that be considered an implicit grant of rights unless otherwise specified (e.g. License headers)?
[RESULT] [VOTE] Graduation of Apache Knox from the Incubator
Hi Everyone, This VOTE has passed with the following tallies: +1 Chris Mattmann* Alan Gates* Larry McCay Dilli Arumugam Kevin Minder Henry Saputra* * - indicates IPMC Thanks for VOTE'ing. I'll paste the resolution into the agenda. Cheers, Chris -Original Message- From: Chris Mattmann mattm...@apache.org Reply-To: d...@knox.incubator.apache.org d...@knox.incubator.apache.org Date: Thursday, February 6, 2014 8:49 PM To: general@incubator.apache.org general@incubator.apache.org Cc: d...@knox.incubator.apache.org d...@knox.incubator.apache.org Subject: [VOTE] Graduation of Apache Knox from the Incubator Hi Everyone, The Apache Knox Incubating podling has VOTEd to graduate from the Incubator. The community VOTE has passed below with the provided tallies. The graduation resolution draft is pasted below. We welcome your VOTE'ing on Knox's graduation from the Incubator. I will leave this VOTE open for at least 72 hours. [ ] +1 Recommend graduation of Apache Knox from the Incubator. [ ] +0 Don't care. [ ] -1 Don't recommend graduation of Apache Knox from the Incubator because.. Thanks for your VOTE! Cheers, Chris -Original Message- From: Chris Mattmann mattm...@apache.org Reply-To: d...@knox.incubator.apache.org d...@knox.incubator.apache.org Date: Thursday, February 6, 2014 8:38 PM To: d...@knox.incubator.apache.org d...@knox.incubator.apache.org Subject: [RESULT] [VOTE] Graduation of Apache Knox from the Incubator Hi Guys, Sorry it took forever for me to close this VOTE! :) Here are the tallies: +1 Chris Mattmann* Alan Gates* Larry McCay Dilli Arumugam Kevin Minder * - indicates IPMC This VOTE has passed. I'll now take it to general@incubator.apache.org. Thanks for VOTE'ing! Cheers, Chris -Original Message- From: Chris Mattmann mattm...@apache.org Reply-To: d...@knox.incubator.apache.org d...@knox.incubator.apache.org Date: Thursday, December 19, 2013 2:41 PM To: d...@knox.incubator.apache.org d...@knox.incubator.apache.org Subject: [VOTE] Graduation of Apache Knox from the Incubator Hi Folks, Time to VOTE on the following resolution to graduate Apache Knox from the Apache Incubator. Here's a draft resolution to VOTE on (with Kevin listed as PMC chair). I'll leave the VOTE open for the next week. If all goes well here, I'll take it to general@incubator.a.o and if all goes well there, we'll take it to the Apache board for consideration in their January 2014 board meeting. Thanks! [ ] +1 Graduate Apache Knox from the Incubator [ ] +0 Don't care. [ ] -1 Don't graduate Apache Knox from the Incubator because.. Thanks and here's my enthusiastic +1! Cheers, Chris --draft resolution WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software, for distribution at no charge to the public, related to secure access for Apache Hadoop clusters. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Knox Project be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Knox Project be and hereby is responsible for the creation and maintenance of software related to secure access for Apache Hadoop clusters; and be it further RESOLVED, that the office of Vice President, Apache Knox, be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Knox Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Knox Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Knox Project: * Christopher Douglas cdoug...@apache.org * Chris Mattmann mattm...@apache.org * Devaraj Das d...@apache.org * Dilli Dorai dillido...@apache.org * Alan Gates ga...@apache.org * John Speidelkminder jspei...@apache.org * Kevin Minder kmin...@apache.org * Larry McCay lmc...@apache.org * Mahadev Konar maha...@apache.org * Owen O'Malley omal...@apache.org * Sumit Mohanty smoha...@apache.org * Tom Beerbower tbeerbo...@apache.org * Thomas White tomwh...@apache.org * Venkatesh Seetharam venkat...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Kevin Minder be appointed to the office of Vice President, Apache Knox, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache Knox Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Knox podling; and be it further RESOLVED, that all
Re: How to handle module contributions
Thanks Ted and Joe for the clarification. It helps a lot. -Taylor On Feb 18, 2014, at 12:18 AM, Ted Dunning ted.dunn...@gmail.com wrote: yeah. What Joe said. On Mon, Feb 17, 2014 at 4:27 PM, Joseph Schaefer joe_schae...@yahoo.comwrote: Judgement call depending on what you might consider a reasonable size for a minor fix versus an independent work (e.g. new module). The larger the patch the more likely you should consider having the author file some paperwork with Apache to cover the contribution. HTH On Feb 17, 2014, at 7:20 PM, P. Taylor Goetz ptgo...@gmail.com wrote: Thanks Ted. Regarding contributions, if someone contributes (e.g. A pull request) to a project with an established license, couldn't that be considered an implicit grant of rights unless otherwise specified (e.g. License headers)? signature.asc Description: Message signed with OpenPGP using GPGMail
