Re: [VOTE] $podling.apache.org is the same as $podling.incubator.apache.org

[Stian Soiland-Reyes]

+1 (non-binding)

On 28 Jun 2016 3:29 p.m., "John D. Ament"  wrote:

> All,
>
> Its been discussed a few times, and I'd like to provide clear feedback to
> the infra team on how to implement going forward.
>
> Typically, the addresses $podling.apache.org and $
> podling.incubator.apache.org work, and have worked for a while.
>
> This is a call to vote on whether the IPMC agrees to this or not.  If they
> do, I will ask infra to further clean this up, as DNS seems to be an issue
> at times for podlings.  The benefit is that for SEO, the website URL does
> not change.
>
> I'm going to leave this open for 72 hours, at least and hope for some
> binding votes on this subject.
>
> [+1] I want the two URLs to both work the same.
> [+/- 0] Don't care
> [-1] I want the $podling.incubator.apache.org URL to be the one that
> works,
> including emails.
>
> John
>

*.incubator.apache.org and lists.apache.org?

[Stian Soiland-Reyes]

Hi,

I'm helping the new Juneau podling, and some confusion came because

https://lists.apache.org/list.html?d...@juneau.apache.org

claims the address is d...@juneau.apache.org

and lists dev-subscr...@juneau.apache.org as it's "Subscribe" address.


Reply-To on the list is however d...@juneau.incubator.apache.org, as
you would expect.


Generally for podling both address styles work - and we just keep the
non-incubator address "secret". However in this case the DNS has not
been updated and sending to d...@juneao.apache.org fails.

The new lists.apache.org interface makes it a bit confusing for
committers and specially newcomers.


Are we moving to using the style dev@$project.apache.org straight away
for new podlings, or is this simply a bug in Ponymail?   (We have
earlier discussed this as a possibility for website URLs)

I've raised the bug
https://github.com/apache/incubator-ponymail/issues/100 but wanted to
check here as well.

-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Worked LICENSE and NOTICE example

[Stian Soiland-Reyes]

Perhaps showing a negative example of a resource you then realize you
can't add, e.g. you find a picture on flickr.com that you want to
bundle, but it's classified as CC Non-Commercial; so you find one that
you CAN include instead, but need to provide attribution for it.


Also propagation of NOTICE, e.g. you want to add

https://github.com/apache/incubator-taverna-common-activities/blob/master/taverna-interaction-activity/src/main/resources/interaction.css

but then you will need to propagate (parts of)

https://github.com/apache/incubator-taverna-common-activities/blob/master/NOTICE



Your tutorial would be great to show at ApacheCon at the Incubator session, btw.

On 23 June 2016 at 07:49, Justin Mclean <jus...@classsoftware.com> wrote:
> Hi,
>
>> Great idea, Justin!
>
> Thanks! I’m considering making several examples, perhaps a few other people 
> can help me out?
>
>> What about including an example in the NOTICE about the inclusion of a
>> non-permissive 3rd party license (e.g., LGPL)?
>
> You can’t have a dependancy (other than optional) on or include non 
> permissive licenses like LGPL. Even if it’s an optional dependancy nothing 
> would go in NOTICE as it’s not bundled.
>
> I could make an example with Category B licenses (weak copy left) as I’ve not 
> covered that yet.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Worked LICENSE and NOTICE example

[Stian Soiland-Reyes]

This is a great tutorial, thanks, Justin! Also good video editing.


I wondered why you did not mention file headers further (beyond for
inspecting licenses), as that is part of ASF policy (while not a legal
requirement for using the Apache license)

The example is very simple, but actually there is no actual content
that would be (c) ASF :-) --  except the README file and index.html, I
think both (or at least index.html) should have ASF headers.




On 23 June 2016 at 01:16, Justin Mclean <jus...@classsoftware.com> wrote:
> Hi,
>
> At the last ApacheCon I was discussing with Marvin about some of the issues 
> around assembling license and notice files. One of the ideas we come up with 
> was to have some worked examples.
>
> So here is a small example I put together of a fictional Apache project using 
> Bootstrap. Code is on github [1] and the checkins show each step needed to 
> bring LICENSE and NOTICE into complicance. I’ve also made a short (4 minutes) 
> screen cast of the process here [2].
>
> Feedback, spelling errors, legal corrections/queries etc etc all welcome. Do 
> people think this is useful and would they like to see more examples?
>
> Thanks,
> Justin
>
> 1. https://github.com/justinmclean/ApacheWombat
> 2. https://vimeo.com/171210141
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Taverna Command-line Tool 3.1.0-incubating RC3

[Stian Soiland-Reyes]

Hi, we have +2 already for the below Taverna release candidate (Thanks
Justin and Sergio!) - do we have any other IPMC volunteers..?

Thanks!

On 17 June 2016 at 14:26, Stian Soiland-Reyes <st...@apache.org> wrote:
> The Taverna PPMC has successfully voted for the source release of
>
>   Apache Taverna Engine 3.1.0-incubating
>   Apache Taverna Common Activities 2.1.0-incubating
>   Apache Taverna Command-line Tool 3.1.0-incubating
>
>
> This is the first major release of Apache Taverna, following two
> library releases which this relies on.
>
> Note that Taverna still suffers from not having enough active mentors;
> so we therefore ask kindly for the wider incubator community to help
> review this release candidate.
>
> We would also welcome any new mentors to guide us as we feel we move
> further towards graduation.
>
>
> Related podling threads:
>
> [VOTE]: 
> https://lists.apache.org/thread.html/03184f452898d3f8280301b93b40fce5902d45997ce03e341afaf3d1@%3Cdev.taverna.apache.org%3E
>
> [RESULT]: 
> https://lists.apache.org/thread.html/d0820b3a3166d5cab89203859baa5c35707904fa2efa7b2870ccf291@%3Cdev.taverna.apache.org%3E
>
> [DISCUSS]: 
> https://lists.apache.org/thread.html/869109d8c0e33bb537ac02e8286dbba2383454e13fc6986750749e6e@%3Cdev.taverna.apache.org%3E
>
>
> Apache Taverna Engine executes Taverna workflows, defined using
> Apache Taverna Language or Taverna 2's .t2flow format, and
> provides OSGi services for monitoring and controlling the
> detailed execution of workflow.
>
> Apache Taverna Common Activities provide bindings for the
> Taverna Engine to invoke activities such as
> command line tools (local/ssh), Beanshell scripts,
> REST and WSDL services, spreadsheet import and
> user interactions.
>
> Apache Taverna Command-line Tool provides a shell command
> for executing Taverna workflows, with output of results to either
> a folder or a Research Object bundle including detailed provenance.
> In addition to the Taverna Common Activities, the Command-line
> supports plugins using Taverna OSGi services.
>
>
> The release candidates to be voted over are available at:
>
> https://dist.apache.org/repos/dist/dev/incubator/taverna/source/rc3/taverna-engine-3.1.0-incubating/
>
> https://dist.apache.org/repos/dist/dev/incubator/taverna/source/rc3/taverna-common-activities-2.1.0-incubating/
>
> https://dist.apache.org/repos/dist/dev/incubator/taverna/source/rc3/taverna-commandline-3.1.0-incubating/
>
>
> Build the release candidate *in the above order*, using:
>
> mvn clean install
>
>
> On a multi-core Linux/OSX machine with a fast disk you may achieve a
> speed-up with:
>
> mvn clean install -T1.5C
>
>
> SHA-1 checksums:
>
> cccbdaf2cac2a05df55c62d03d6308ac75f72a58
> apache-taverna-engine-3.1.0-incubating-source-release.zip
> 94d15c4c1dbd1021b8726e584810a6030e90a16c
> apache-taverna-common-activities-2.1.0-incubating-source-release.zip
> 71ba1a84cf1cb7293de3fef5bbeb81b353634698
> apache-taverna-commandline-3.1.0-incubating-source-release.zip
>
>
> MD5 checksums:
>
> 276c36375b28c2a7a01fbb48c8cf66ea
> apache-taverna-engine-3.1.0-incubating-source-release.zip
> fccf07b3d6fe7245c67466e75fcd840b
> apache-taverna-common-activities-2.1.0-incubating-source-release.zip
> 948b7f0fae080ac4be802571d182a5cb
> apache-taverna-commandline-3.1.0-incubating-source-release.zip
>
>
> The release candidates correspond to the following git commits:
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-engine.git;a=commit;h=403dbc4a5984798b2ea98dfb37314128b50b2bcf
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-common-activities.git;a=commit;h=a192c858c65441f33043aeeaa0889e0159a5a4e8
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-commandline.git;a=commit;h=2db7d9f823e895d33ef2107ebfe5d70ed20e1fc7
>
>
> Release candidates are signed with a GPG key available at:
>   https://dist.apache.org/repos/dist/release/incubator/taverna/KEYS
>
>
> A staged Maven repository is available for review at:
>   https://repository.apache.org/content/repositories/orgapachetaverna-1015/
>
>
> The changelog for this release is available from JIRA:
>
>   
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318322=12332249
>   
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318322=12332250
>   
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318322=12332251
>
>
>
> Please vote on releasing these packages as:
>
>   Apache Taverna Engine 3.1.0-incubating
>   Apache Taverna Common Activities 2.1.0-incubating
>   Apache Taverna Command-line Tool 3.1.0-incubating
>
>
> The

Re: Request to review updated License (Re: [VOTE] Release Apache Ranger 0.5.3 (incubating))

[Stian Soiland-Reyes]

nerator/UmAlQuraCalendar.js
> 7. 
> ./apache-ranger-incubating-0.5.3/security-admin/src/main/webapp/libs/other/visualsearch/css/reset.css
> 8. http://meyerweb.com/eric/tools/css/reset/reset.css
> 9.  
> apache-ranger-incubating-0.5.3/security-admin/src/main/webapp/fonts/fontawesome/FontAwesome.otf
> 10. ./security-admin/src/main/webapp/libs/bower/jquery/js/jquery.js
> 11. ./security-admin/src/main/webapp/libs/bower/globalize/test/qunit/qunit.js
> 12. 
> /security-admin/src/main/webapp/libs/bower/require-handlebars-plugin/js/hbs.js
> 13. 
> ./security-admin/src/main/webapp/libs/bower/require-handlebars-plugin/js/json2.js
> 14. 
> ./security-admin/src/main/webapp/libs/other/jquery-ui/js/jquery-ui-1.10.3.custom.js
> 15 http://robertpenner.com/easing/
>>>
>
> Thank you,
> Vel
>
> On May 20, 2016, at 11:25 AM, Velmurugan Periasamy <v...@apache.org> wrote:
>
>> Thank you so much Justin. I’ll do the below.
>>
>> 1] Initiate another RC for 0.5.3.
>> 2] Track these issues in https://issues.apache.org/jira/browse/RANGER-964 
>> and target to address in 0.6.0
>>
>> Regarding your question on [5] and [6] below, I believe these files are 
>> covered under jquery globalize license. I will double check and resolve it 
>> as needed in next release.
>>
>>> This is a more serious concern (and has been asked before):
>>> - How is this file licensed? [5] or this one? [6]
>>
>>
>> Thank you for your help,
>> Vel
>>
>> On May 19, 2016, at 8:11 PM, Justin Mclean <jus...@classsoftware.com> wrote:
>>
>>> Hi,
>>>
>>> Still needs some work IMO but if a JIRA was raised to fix these issues in a 
>>> later release I’d vote +1 on a new RC without these fixes. Just as long as 
>>> it’s all sorted before graduation.
>>>
>>> Minor issues:
>>> - LICENSE is missing MIT licensed Search Icon CSS copyright Nicolas 
>>> Gallagher bundled in  [1]
>>> - Is the copyright on this files correct? [2][3] if so what projects did 
>>> they come from? (may effect content of NOTICE file)
>>> - LICENSE is missing MIT licensed es5-shim copyright Kristopher Michael 
>>> Kowal bundled in [4]
>>> - LICENSE is missing SIL licensed FontAwesome [9]
>>> - LICENSE is missing reset.css. [7] Note this version bundled may not be 
>>> public domain unlike this one [8] so you may need to sort that out.
>>> - LICENSE is missing MIT licensed sizzle.js bundled in several files [10]
>>> - LICENSE is missing MIT license javascript diff engine in [11]
>>> - I think handle bars require plugin is not WTFPL but MIT or BSD? [12] May 
>>> require further investigation.
>>> - LICENSE is missing public domain json2.js [13]
>>> - LICENSE is missing BSD licensed easing equations from Robert Penner [15] 
>>> in this file [14]
>>>
>>> This is a more serious concern (and has been asked before):
>>> - How is this file licensed? [5] or this one? [6]
>>>
>>> As there this is very complex there may of been a couple of things I missed.
>>>
>>> Thanks,
>>> Justin
>>>
>>> 1. 
>>> ./apache-ranger-incubating-0.5.3/security-admin/src/main/webapp/libs/bower/backgrid-filter/css/backgrid-filter.css
>>> 2. 
>>> ./apache-ranger-incubating-0.5.3/jisql/src/main/java/org/apache/util/sql/Jisql.java
>>> 3. 
>>> ./apache-ranger-incubating-0.5.3/security-admin/src/test/java/org/apache/ranger/service/PasswordComparisonAuthenticator.java
>>> 4. 
>>> ./apache-ranger-incubating-0.5.3/security-admin/src/main/webapp/libs/other/backgrid/backgrid.js
>>> 5. 
>>> ./apache-ranger-incubating-0.5.3/security-admin/src/main/webapp/libs/bower/globalize/generator/HijriCalendar.js
>>> 6. 
>>> ./apache-ranger-incubating-0.5.3/security-admin/src/main/webapp/libs/bower/globalize/generator/UmAlQuraCalendar.js
>>> 7. 
>>> ./apache-ranger-incubating-0.5.3/security-admin/src/main/webapp/libs/other/visualsearch/css/reset.css
>>> 8. http://meyerweb.com/eric/tools/css/reset/reset.css
>>> 9.  
>>> apache-ranger-incubating-0.5.3/security-admin/src/main/webapp/fonts/fontawesome/FontAwesome.otf
>>> 10. ./security-admin/src/main/webapp/libs/bower/jquery/js/jquery.js
>>> 11. 
>>> ./security-admin/src/main/webapp/libs/bower/globalize/test/qunit/qunit.js
>>> 12. 
>>> /security-admin/src/main/webapp/libs/bower/require-handlebars-plugin/js/hbs.js
>>> 13. 
>>> ./security-admin/src/main/webapp/libs/bower/require-handlebars-plugin/js/json2.js
>>> 14. 
>>> ./security-admin/src/main/webapp/libs/other/jquery-ui/js/jquery-ui-1.10.3.custom.js
>>> 15 http://robertpenner.com/easing/
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>>
>>
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Juneau into the Apache Incubator

[Stian Soiland-Reyes]

d on an
> Apache open source project.
>
> === Homogenous Developers ===
>
> The two initial developers span two different companies:  Salesforce and
> IBM.
>
> We highly anticipate that the list of developers will quickly grow to
> include existing community members located in places such as China and
> India.
>
> === Reliance on Salaried Developers ===
>
> It's expected that development will occur primarily on volunteer time as it
> has in the past.
>
> === Relationships with Other Apache Products ===
>
> Juneau contains dependencies on the following projects:
>  * Apache Jena
>  * Apache !HttpClient
>
> === A Excessive Fascination with the Apache Brand ===
>
> Our interest in submitting this as an Apache-branded product is mostly due
> to its existing co-dependence on other Apache-branded products.
>
> We plan on making this an open-source project regardless of whether it
> makes it out of incubator stage.
>
> == Documentation ==
>
> Links to all documentation:
> https://sites.google.com/site/apachejuneau/links
>
> Javadocs:  https://juno-cloud-api-javadocs.mybluemix.net/index.html
>
> Overview:
> https://juno-cloud-api-javadocs.mybluemix.net/overview-summary.html#TOP
>
> Release Notes:
> https://juno-cloud-api-javadocs.mybluemix.net/overview-summary.html#ReleaseNotes
>
> == Initial Source ==
>
> The source code is currently located in a Rational Team Concert source code
> repository internally in IBM.
>
> == Source and Intellectual Property Submission Plan ==
>
> IBM legal has given approval for making this project available as an
> Apache-branded product.  Peter Haumer will handle requests for more
> information.
>
> All source code will be made available under the Apache V2 license.
>
> == External Dependencies ==
>
> The dependences all have Apache compatible licenses.
>
> == Cryptography ==
>
> Juneau contains no cryptographic resources.
>
> == Required Resources ==
>
> === Mailing lists ===
>
> priv...@juneau.incubator.apache.org
> d...@juneau.incubator.apache.org
>
> === Subversion Directory ===
>
> Not used.
>
> === Git Repository ===
>
> Source code:
> https://git-wip-us.apache.org/repos/asf/incubator-juneau.git
>
> Site code:
> https://git-wip-us.apache.org/repos/asf/incubator-juneau-site.git
>
> === Issue Tracking ===
>
> JIRA Juneau
>
> === Other Resources ===
>
> None.
>
> == Initial Committers ==
>
>  * James Bognar
>  * Peter Haumer
>  * Craig Chaney
>  * Min Idzelis
>  * David M Goddard
>  * Brian Laskey
>
> == Affiliations ==
>
>  * Salesforce: James Bognar, Craig Chaney, Min Idzelis
>  * IBM: Peter Haumer, David M Goddard, Brian Laskey
>
> == Sponsors ==
>
> === Champion ===
>
> John D Ament - (johndament at apache dot org)
>
> === Nominated Mentors ===
>
> John D Ament - (johndament at apache dot org)
>
> Jochen Wiedmann - (jochen at apache dot org)
>
> Craig L Russell - (craig dot russell at oracle dot com)
>
> === Unofficial Mentors ===
>
> Stian Soiland-Reyes - (stain at apache dot org)
>
> === Sponsoring Entity ===
>
> We request that the Incubator PMC sponsors this project



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Taverna Command-line Tool 3.1.0-incubating RC3

[Stian Soiland-Reyes]

On 20 June 2016 at 16:31, Donal Fellows
<donal.k.fell...@manchester.ac.uk> wrote:
>> But is "Public Domain" valid outside US?  Should we append ASF headers
> on it? (That should be allowed if it's PD.. at least if that is done
> by an USAnian)
> It certainly isn't on some jurisdictions (Germany is the most notable one) 
> but I would expect any German court to at least try to comply with the spirit 
> of the intended licence (e.g., no economic claims) as the jurisdictions that 
> are issuing the licence (arguably the USA and the UK) have the concept. The 
> real main difference with German law is over the author's rights, but it is 
> only the authors who really have the standing to complain about them in the 
> first place, and they've publicly said they won't...
> International law in relation to software licences is complex. Of you are 
> really worried, you should seek professional advice. I knows I am not the 
> person to offer such advice!

I'll rely on 
https://www.apache.org/legal/resolved#can-works-placed-in-the-public-domain-be-included-in-apache-products
saying Public Domain OK with attribution, and hope the fact that ASF
(and the author of json2.js) is based in US keeps the lawyers away :-)


-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Taverna Command-line Tool 3.1.0-incubating RC3

[Stian Soiland-Reyes]

On 20 June 2016 at 12:24, Sergio Fernández <wik...@apache.org> wrote:
> +1 (binding)

Thanks! Much appreciated!


> Non-blocking details I noticed (should be fixed in the next releases):
> * The three artifacts are related with each other, so I'd include some
> extra build information about the order when each one needs to be built.

Agreed.

Added:

https://github.com/apache/incubator-taverna-engine#prerequisites
https://github.com/apache/incubator-taverna-common-activities#prerequisites
https://github.com/apache/incubator-taverna-commandline#prerequisites



> * Some licensing details in NOTICE files (e.g., BSD 3-Clause at
> apache-taverna-engine-3.1.0-incubating/NOTICE and W3C
> apache-taverna-common-activities-2.1.0-incubating/NOTICE) need to be fixed:

Fixed:

https://issues.apache.org/jira/browse/TAVERNA-985
https://issues.apache.org/jira/browse/TAVERNA-986
https://issues.apache.org/jira/browse/TAVERNA-987

> * All NOTICE files should be aligned in wording and format (e.g.,
> apache-taverna-commandline-3.1.0-incubating/NOTICE contains wrong year).

Fixed - although we should probably improve the "based on" wording.

> Besides that, the release looks fine for me. Congratulations for such
> milestone, guys!

Thanks for reviewing!


-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Taverna Command-line Tool 3.1.0-incubating RC3

[Stian Soiland-Reyes]

On 18 June 2016 at 01:50, Justin Mclean <jus...@classsoftware.com> wrote:
> Hi,
>
> +1 (binding). Can you fix the LICENSE and NOTICE issues in the next release 
> please.

Thank you - already fixed in master. Getting smarter every day..


> I can help by reviewing the release but I’m at my limit mentor wise sorry.

Always appreciated - thanks!


> - able to compile all from source but it seems the order matters (i.e. you 
> need to compile the engine first) you may want to mention that in README if 
> it’s not already

Of course once these are in Maven Central it won't be a big blocker in the end.

However I agree the build order should be more explicit, so I have
added for the future:

https://github.com/apache/incubator-taverna-engine#prerequisites
https://github.com/apache/incubator-taverna-common-activities#prerequisites
https://github.com/apache/incubator-taverna-commandline#prerequisites

(Note that the linked download pages for engine/common-activities are
only on http:// taverna.staging.apache.org/ for now)



> In apache-taverna-commandline-3.1.0-incubating
> - wording in NOTICE is is a little odd but probably fine.

I guess you mean this section?

> Portions of this software were originally based on the following:
> - Copyright 2010-2014 University of Manchester, UK
> These have been licensed to the Apache Software Foundation under a software 
> grant.

This is how it was suggested to us by our mentors; but we're open for
improvements - this text is the same across our NOTICEs (however the
start-year might vary depending on the code base).

Semantically I guess the software is not based on a copyright.. :)

How about:

> Portions of this software is:
> - Copyright 2010-2014 University of Manchester, UK
> These have been licensed to the Apache Software Foundation under a software 
> grant.

?


> - year in NOTICE needs updating

Bah - thanks. Updated. :)



> In apache-taverna-common-activities-2.1.0-incubating
> - W3C license info should be moved to LICENSE or preferably to it own file 
> and a pointer to that file added [1]

Done - https://issues.apache.org/jira/browse/TAVERNA-986




> - LICENSE is missing license for this file [3]

Oops! Well spotted. It is Public Domain, so there is obviously no
requirement to propagate any license,

But is "Public Domain" valid outside US?  Should we append ASF headers
on it? (That should be allowed if it's PD.. at least if that is done
by an USAnian)


Anyway, for information purposes I've added to top-level LICENSE
-
./taverna-interaction-activity/src/main/resources/json2.js
is Public Domain, see https://github.com/douglascrockford/JSON-js/
and http://www.json.org/js.html
---




> In apache-taverna-engine-3.1.0-incubating
> - The licence of this file [2] needs to be mentioned in LICENSE not NOTICE 
> [1]. A pointer to the license file is preferred.

Done. https://issues.apache.org/jira/browse/TAVERNA-985

(Also as you suggested I put it in META-INF/LICENSE rather than META-INF/NOTICE)


-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Taverna Command-line Tool 3.1.0-incubating RC3

[Stian Soiland-Reyes]

On 20 June 2016 at 12:49, Justin Mclean <jus...@classsoftware.com> wrote:
>> license text should go in the LICENSE files, while NOTICE should just
>> contain a brief enumeration with some details (file/s, copyright holder,
>> license name and original source) about the third-party source components
>> included.
>
> Agree but just to make clear NOTICE should usually not include copyright info 
> about permissive 3rd party licenses. NOTICE should include copyright notices 
> that have been removed [1] and required notices [2] but nothing more. [3]


Thank you both and for the useful links - I was a bit confused by this
for the BSD license, because of the 2nd clause:

>  Redistributions in binary form must reproduce the above copyright
>  notice, this list of conditions and the following disclaimer in the
>  documentation and/or other materials provided with the distribution.

I would think this means that the taverna-execution-hadoop.jar file
(which is distributed in Maven Central) must include the full notice
"somewhere", so I hope it's OK that it still remains in
its META-INF/NOTICE [3] - as otherwise I think it would be too easy to
miss for downstream users (including ourselves if we later distribute
the Taverna Command Line as a binary distro).

However I agree this does not need to be in the top-level
taverna-engine/NOTICE, so I've shrunk that back to normal [2], and
added to the end of LICENSE [1]:

> -
> taverna-execution-hadoop/src/main/java/org/pingel/util/CrossProduct.java
> is licensed under a BSD-3 license, see its file headers for details.
> -

Do you think this should be sufficient?


[1] https://github.com/apache/incubator-taverna-engine/blob/master/LICENSE#L203
[2] https://github.com/apache/incubator-taverna-engine/blob/master/NOTICE
[3] 
https://github.com/apache/incubator-taverna-engine/blob/master/taverna-execution-hadoop/src/main/resources/META-INF/NOTICE
[4] https://issues.apache.org/jira/browse/TAVERNA-985


-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Juneau Incubation Proposal

[Stian Soiland-Reyes]

This sounds very interesting; would you add me as an informal mentor? (I'm
afraid I am not eligible to be a capital-M Mentor :-)

I see you are interested in minimising dependencies and use Apache Jena,
perhaps there could also be potential for overlap with Apache Commons RDF,
which we are evolving to be a simple intermediate API plugging into Jena,
RDF4j and others? :-)

It would be good if https://github.com/jamesbognar/juneau didn't call
itself "Apache Juneau" before it has been accepted and imported into the
Apache Foundation, and similarly
https://sites.google.com/site/apachejuneau/ - both of these could be (kind
of future) trademark violations, particularly using "Apache" In the URL..

Could you change these titles and descriptions to a more neutral "proposed
Apache Incubator project"? You don't need to change the package names
before code import, but I would say having a Google site with "apache" in
its URL and title is misleading. (Accepted projects will get their own
website on ASF infrastructure, e.g. http://juneau.incubator.apache.org )


On 16 Jun 2016 5:52 p.m., "James Bognar" 
wrote:

> Hi all,
>
> I'd like to propose Juneau to be an Apache Incubator project.
>
> Juneau is a toolkit for marshalling POJOs to a wide variety of content
> types using a common framework, and for creating sophisticated
> self-documenting REST interfaces and microservices using VERY little code.
>
> Juneau has been in use for years on over 50 projects throughout IBM.
> Recently it was hosted as a component of Jazz Foundation where it was used
> by several projects that make up Rational Collaborative Lifecycle
> Management.  Many projects use only the marshalling framework, while others
> use the entire API to create sophisticated REST server/client interfaces.
>
> The link to the proposal can be found here:
>
> https://wiki.apache.org/incubator/JuneauProposal
>
> Thanks.
>
> --
> James Bognar
>

Fwd: [VOTE] Release Apache Taverna Command-line Tool 3.1.0-incubating RC3

[Stian Soiland-Reyes]

The Taverna PPMC has successfully voted for the source release of

  Apache Taverna Engine 3.1.0-incubating
  Apache Taverna Common Activities 2.1.0-incubating
  Apache Taverna Command-line Tool 3.1.0-incubating


This is the first major release of Apache Taverna, following two
library releases which this relies on.

Note that Taverna still suffers from not having enough active mentors;
so we therefore ask kindly for the wider incubator community to help
review this release candidate.

We would also welcome any new mentors to guide us as we feel we move
further towards graduation.


Related podling threads:

[VOTE]: 
https://lists.apache.org/thread.html/03184f452898d3f8280301b93b40fce5902d45997ce03e341afaf3d1@%3Cdev.taverna.apache.org%3E

[RESULT]: 
https://lists.apache.org/thread.html/d0820b3a3166d5cab89203859baa5c35707904fa2efa7b2870ccf291@%3Cdev.taverna.apache.org%3E

[DISCUSS]: 
https://lists.apache.org/thread.html/869109d8c0e33bb537ac02e8286dbba2383454e13fc6986750749e6e@%3Cdev.taverna.apache.org%3E


Apache Taverna Engine executes Taverna workflows, defined using
Apache Taverna Language or Taverna 2's .t2flow format, and
provides OSGi services for monitoring and controlling the
detailed execution of workflow.

Apache Taverna Common Activities provide bindings for the
Taverna Engine to invoke activities such as
command line tools (local/ssh), Beanshell scripts,
REST and WSDL services, spreadsheet import and
user interactions.

Apache Taverna Command-line Tool provides a shell command
for executing Taverna workflows, with output of results to either
a folder or a Research Object bundle including detailed provenance.
In addition to the Taverna Common Activities, the Command-line
supports plugins using Taverna OSGi services.


The release candidates to be voted over are available at:

https://dist.apache.org/repos/dist/dev/incubator/taverna/source/rc3/taverna-engine-3.1.0-incubating/

https://dist.apache.org/repos/dist/dev/incubator/taverna/source/rc3/taverna-common-activities-2.1.0-incubating/

https://dist.apache.org/repos/dist/dev/incubator/taverna/source/rc3/taverna-commandline-3.1.0-incubating/


Build the release candidate *in the above order*, using:

mvn clean install


On a multi-core Linux/OSX machine with a fast disk you may achieve a
speed-up with:

mvn clean install -T1.5C


SHA-1 checksums:

cccbdaf2cac2a05df55c62d03d6308ac75f72a58
apache-taverna-engine-3.1.0-incubating-source-release.zip
94d15c4c1dbd1021b8726e584810a6030e90a16c
apache-taverna-common-activities-2.1.0-incubating-source-release.zip
71ba1a84cf1cb7293de3fef5bbeb81b353634698
apache-taverna-commandline-3.1.0-incubating-source-release.zip


MD5 checksums:

276c36375b28c2a7a01fbb48c8cf66ea
apache-taverna-engine-3.1.0-incubating-source-release.zip
fccf07b3d6fe7245c67466e75fcd840b
apache-taverna-common-activities-2.1.0-incubating-source-release.zip
948b7f0fae080ac4be802571d182a5cb
apache-taverna-commandline-3.1.0-incubating-source-release.zip


The release candidates correspond to the following git commits:

https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-engine.git;a=commit;h=403dbc4a5984798b2ea98dfb37314128b50b2bcf

https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-common-activities.git;a=commit;h=a192c858c65441f33043aeeaa0889e0159a5a4e8

https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-commandline.git;a=commit;h=2db7d9f823e895d33ef2107ebfe5d70ed20e1fc7


Release candidates are signed with a GPG key available at:
  https://dist.apache.org/repos/dist/release/incubator/taverna/KEYS


A staged Maven repository is available for review at:
  https://repository.apache.org/content/repositories/orgapachetaverna-1015/


The changelog for this release is available from JIRA:

  
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318322=12332249
  
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318322=12332250
  
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318322=12332251



Please vote on releasing these packages as:

  Apache Taverna Engine 3.1.0-incubating
  Apache Taverna Common Activities 2.1.0-incubating
  Apache Taverna Command-line Tool 3.1.0-incubating


The vote is open for at least 72 hours and passes if a majority of at
least three +1 Apache Incubator IPMC votes are cast.


[ ] +1 Release this package
[ ]  0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because...


Anyone can participate in testing and voting, not just IPMC members,
please feel free to try out the release candidate and provide your
votes!

How to review a release candidate? https://s.apache.org/review-release



--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

RE: [VOTE] Release Apache Trafodion 2.0.0 (incubating)

[Stian Soiland-Reyes]

Note distributing OpenSSL mean you need to update the Trafodion entry on

http://www.apache.org/licenses/exports/

to also include your dist folder.

On 1 Jun 2016 6:54 p.m., "Steve Varnau"  wrote:

> Justin,
>
> Thanks for clarifying the issues here.  I will write JIRAs to fix the two
> minor issues in next release (clarify the rescinded BSD-4 clause and remove
> the GPL part of the dual license).
>
> Looking at the openssl issue, I want to figure out why we are statically
> linking the libraries.  If there is a key reason it needs to be static
> rather than dynamically linked, then I'll want to go to legal-discuss and
> ask whether we can distribute it, given license changes in the works.
>
> If we can change the build to change to dynamic linking and not include
> openssl in the binaries, then perhaps the expedient thing is to go ahead
> with this release, minus the client binary. And re-package it for next
> release.
>
> Thanks!
>
> --Steve
>
>
> > -Original Message-
> > From: Justin Mclean [mailto:jus...@classsoftware.com]
> > Sent: Tuesday, May 31, 2016 8:15 PM
> > To: general@incubator.apache.org
> > Subject: Re: [VOTE] Release Apache Trafodion 2.0.0 (incubating)
> >
> > Hi,
> >
> > +1 (binding) to release source package, but -1 for the client connivence
> > binary
> > until the 4 clause BSD licensing issue is resolved.
> >
> > For the source released I checked:
> > - all files have incubating
> > - signatures check out
> > - disclaimer exists
> > - LICENSE and NOTICE good
> > - No unexpected binary in source
> > - All ASF licensed file have ASF headers
> >
> > The source LICENSE has a minor issue. It mentions the 4 clause BSD
> license
> > which is not compatible with the Apache license (only the 2 and 3 clause
> > BSD
> > licenses are) [1][2]. In this case the extra clause has been recinded [3]
> > you
> > might want to reword/state that in the license.
> >
> > But that does mean there is an issue with the client binary release as
> > that
> > includes OpenSSL which lists a 6 clause BSD style license (similar to a 4
> > clause
> > BSD license) and SSLeay under a 4 clause BSD license. You may need to
> > clarify
> > this on legal discuss. It may be that their intent to move to an Apache
> > licence
> > may mean you can hold off on doing anything but I’m not 100% sure. [4][5]
> >
> > I would also remove the GPL license text from the server’s LICENSE file
> to
> > make
> > it clear which license it’s included under. If something is dual licensed
> > you
> > select which licence you want to use.
> >
> > Thanks,
> > Justin
> >
> > 1. http://www.apache.org/legal/resolved.html#category-a
> > 2. https://issues.apache.org/jira/browse/LEGAL-185
> > 3. https://opensource.org/licenses/BSD-3-Clause
> > 4. https://www.openssl.org/blog/blog/2015/08/01/cla/
> > 5. https://wiki.openssl.org/index.php/License
> >
> >
> >
> > -
> > 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: Podling name search - early or late?

[Stian Soiland-Reyes]

I think the point is that name search is not a blocker for doing incubator
releases - it can be time consuming and there are many other "bureaucratic"
steps to get through in the beginning like IP clearance and license
checking.

For brand new projects, name search can therefore be delayed - their name
is less important as their community will be fully within the incubator to
start with.

However I think for established distributed projects moving to the
incubator it is more important to sort name earlier - it can be disruptive
enough for the community with the change of infrastructure and the
formalities, so you may might not want to confuse them again with a new
name many months later - effectively changing all infrastructure again.

Some podlings found their name could be tricky trademark wise and had to
change, but getting together and deciding a new name can even be a good
thing, as it breaks any legacy corporate ownership and builds a new
collective identity.
On 27 May 2016 7:20 p.m., "Balaji Ganesan"  wrote:

> Podling namesearch is essential step that needs to be completed before the
> podling graduates. There is no specific guidance, as far as i know, on what
> stage of podling you should do it.
>
> That said, it would be better to do this early enough and get approval on
> the name. If there is any reason to change name, due to a conflict, it is
> better to do it before releases are made and community starts building
> around. Name change is always a pain.
>
> On Fri, May 27, 2016 at 11:07 AM, Jakob Homan  wrote:
>
> > We were getting ready to start the PNS for Airflow when I came across
> > this comment from Shane in regards to Kudu:
> >
> > https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-93
> > "This looks like a pretty good set of search data, but we usually
> > don't work on resolving PODLINGNAMESEARCHES until a podling is clearly
> > established, has a release, community is building, etc."
> >
> > This is surprising to me and different than the last time I was
> > involved in an incubating project.  Is this correct?
> >
> > It seems more useful to determine if a name can be used early in the
> > incubation, before releases, talks, thousands of lines code, package
> > names, emotional attachments, etc.  In the event that a podling fails,
> > nothing is lost by okaying the name early, assuming we don't attempt
> > to trademark (which we haven't been for non-TLPs, I believe).
> >
> > Any thoughts?  Any reason not to start doing the PNS for Airflow now?
> >
> > Thanks,
> > Jakob
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: ECCN cryptography reporting?

[Stian Soiland-Reyes]

Thanks!

I think we need to work more on https://www.apache.org/dev/crypto.html
to add the kind of considerations to make to decide if some software
needs to be registered or not, perhaps suggest various "escape
hatches".

Now we can proceed with the Taverna RCs :)

On 21 May 2016 at 22:24, Ted Dunning <ted.dunn...@gmail.com> wrote:
> I just sent this notification. I added a small amount of language to the
> notification and added secretary@a.o as a cc and as a contact point.
>
> Thanks to the Taverna community for laying the groundwork so assiduously.
> This is a notoriously opaque area which you have illuminated nicely.
>
>
> On Thu, May 19, 2016 at 6:16 AM, Stian Soiland-Reyes <st...@apache.org>
> wrote:
>
>> Hi, Taverna is still waiting for the ECCN registration for Taverna to
>> be sent in from Ted before we can continue to prepare our next release
>> candiates.
>>
>>
>> Taverna's listing is now live on:
>> https://www.apache.org/licenses/exports/
>>
>> See draft email on
>>
>> https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review#TavernaCryptographyreview-Draftregistrationemail
>>
>>
>> FYI: I added the ECCN "flowchart" considerations to
>>
>>
>> https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review
>>
>>
>>
>>
>> On 12 May 2016 at 14:20, Stian Soiland-Reyes <st...@apache.org> wrote:
>> > Ted & John,
>> >
>> >
>> > Should Taverna wait until the ECCN registration has been filed (or
>> > not) before we prepare our next release candidate for voting?
>> >
>> >
>> > On 9 May 2016 at 17:54, Stian Soiland-Reyes <st...@apache.org> wrote:
>> >> We documented it in https://issues.apache.org/jira/browse/TAVERNA-959
>> >> and on
>> https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review
>> >>
>> >> See also
>> https://issues.apache.org/jira/browse/LEGAL-250?focusedCommentId=15272500=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15272500
>> >>
>> >>
>> >>> Taverna Language (while primarily an API for designing workflows)
>> includes a component which functionality is data storage in a ZIP file -
>> the encryption functionality of HTTP Components is however not used, and so
>> Language should not be registered. (unless we make a binary distribution
>> that includes HTTP Components)
>> >>
>> >>> Taverna OSGi's Download API module is "Sending, receiving or storing
>> information" and so should be registered because it is using HTTP
>> Components and can do https.
>> >>
>> >>> Taverna Engine's Credential Manager module is doing "information
>> security" and should be registered.
>> >>
>> >>> Taverna Common Activities are "Sending, receiving or storing
>> information" (talking to web services) and should be registered.
>> >>
>> >>> Taverna Command Line is primarily running a workflow, and should NOT
>> be registered (unless you consider a workflow to be primarily
>> sending/receiving information) - however if we make a binary distribution
>> it would include Bouncy Castle, Derby, HTTPComponents as JARs, and at that
>> point needs to be registered.
>> >>
>> >>
>> >> The README notes show the findings in detail. See the individual repos.
>> >>
>> >>
>> >> We have not done a detailed review on the workbench* modules as we are
>> >> not yet releasing them - however our release of the above is currently
>> >> blocked on this ECCN registration.
>> >>
>> >>
>> >> On 5 May 2016 at 02:23, Ted Dunning <ted.dunn...@gmail.com> wrote:
>> >>> My guess is that this would fall to me.
>> >>>
>> >>> There is considerable analysis to be done to determine whether filing
>> is
>> >>> required.
>> >>>
>> >>> Are you guys documenting the decision points?
>> >>>
>> >>>
>> >>>
>> >>> On Wed, May 4, 2016 at 4:45 AM, Stian Soiland-Reyes <st...@apache.org>
>> >>> wrote:
>> >>>
>> >>>> On 2 May 2016 at 03:23, Stian Soiland-Reyes <st...@apache.org> wrote:
>> >>>>
>> >>>> > Formally - would it need to be the Incubator PMC chair sending the
>&g

Re: ECCN cryptography reporting?

[Stian Soiland-Reyes]

Hi, Taverna is still waiting for the ECCN registration for Taverna to
be sent in from Ted before we can continue to prepare our next release
candiates.


Taverna's listing is now live on:
https://www.apache.org/licenses/exports/

See draft email on
https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review#TavernaCryptographyreview-Draftregistrationemail


FYI: I added the ECCN "flowchart" considerations to

https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review




On 12 May 2016 at 14:20, Stian Soiland-Reyes <st...@apache.org> wrote:
> Ted & John,
>
>
> Should Taverna wait until the ECCN registration has been filed (or
> not) before we prepare our next release candidate for voting?
>
>
> On 9 May 2016 at 17:54, Stian Soiland-Reyes <st...@apache.org> wrote:
>> We documented it in https://issues.apache.org/jira/browse/TAVERNA-959
>> and on 
>> https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review
>>
>> See also 
>> https://issues.apache.org/jira/browse/LEGAL-250?focusedCommentId=15272500=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15272500
>>
>>
>>> Taverna Language (while primarily an API for designing workflows) includes 
>>> a component which functionality is data storage in a ZIP file - the 
>>> encryption functionality of HTTP Components is however not used, and so 
>>> Language should not be registered. (unless we make a binary distribution 
>>> that includes HTTP Components)
>>
>>> Taverna OSGi's Download API module is "Sending, receiving or storing 
>>> information" and so should be registered because it is using HTTP 
>>> Components and can do https.
>>
>>> Taverna Engine's Credential Manager module is doing "information security" 
>>> and should be registered.
>>
>>> Taverna Common Activities are "Sending, receiving or storing information" 
>>> (talking to web services) and should be registered.
>>
>>> Taverna Command Line is primarily running a workflow, and should NOT be 
>>> registered (unless you consider a workflow to be primarily 
>>> sending/receiving information) - however if we make a binary distribution 
>>> it would include Bouncy Castle, Derby, HTTPComponents as JARs, and at that 
>>> point needs to be registered.
>>
>>
>> The README notes show the findings in detail. See the individual repos.
>>
>>
>> We have not done a detailed review on the workbench* modules as we are
>> not yet releasing them - however our release of the above is currently
>> blocked on this ECCN registration.
>>
>>
>> On 5 May 2016 at 02:23, Ted Dunning <ted.dunn...@gmail.com> wrote:
>>> My guess is that this would fall to me.
>>>
>>> There is considerable analysis to be done to determine whether filing is
>>> required.
>>>
>>> Are you guys documenting the decision points?
>>>
>>>
>>>
>>> On Wed, May 4, 2016 at 4:45 AM, Stian Soiland-Reyes <st...@apache.org>
>>> wrote:
>>>
>>>> On 2 May 2016 at 03:23, Stian Soiland-Reyes <st...@apache.org> wrote:
>>>>
>>>> > Formally - would it need to be the Incubator PMC chair sending the
>>>> > ECCN encryption email?
>>>>
>>>> Could anyone from IPMC (e.g. our mentors) do it, or just Ted Dunning?
>>>>
>>>> --
>>>> Stian Soiland-Reyes
>>>> Apache Taverna (incubating), Apache Commons RDF (incubating)
>>>> http://orcid.org/-0001-9842-9718
>>>>
>>>> -
>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>>>
>>>>
>>
>>
>>
>> --
>> Stian Soiland-Reyes
>> Apache Taverna (incubating), Apache Commons RDF (incubating)
>> http://orcid.org/-0001-9842-9718
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/-0001-9842-9718



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Additional mentor steps?

[Stian Soiland-Reyes]

Yes, agree in a single source which should not be svn authorisation, even
as I last added commonsrdf to the people.apache.org directory there were
two similar authorisation files, and it was not clear which one to add to,
in fact even infrachat raised the same questions in this thread that we
need a better solution.

The fact that podlings are listed (and searched for) separately from
projects is also very confusing for any outsiders not fully familiar with
the incubation process.

Could people remind us about the reason why LDAP is not good for podlings?
Is it to do with write permissions to modify the LDAP group? Grant IPMC
members full write access, as they would need to formally approve (even if
it is by passive vote) any new podling committers anyway.

Getting the podling to declare formerly the committers and PPMC in the same
way as top-level projects sounds to me just to be a good thing
("pretending" they are a TLP); for several of the current podlings there
are multiple sources of membership listings, not always in sync or easy to
find.

I don't see why LDAP groups is worse than hunting around doing pull
requests deep inside INFRA's production system management rules.. even
trying to change the documentation for this struggles with continual
development and deprecation within INFRAs infrastructure (which I think
they should be able to do).

Another, more hackish solution would be to drive the phone book for
podlings from podlings.xml or projects/${podling.xml} - I would be a bit
negative to that as it keeps podlings "special", it will break in 18 months
time, and also the podling.xml seems mainly presentational with a HTML-like
. (Why is it not just HTML ;)
On 15 May 2016 12:48 a.m., "Roman Shaposhnik"  wrote:

> On Sat, May 14, 2016 at 4:38 PM, John D. Ament 
> wrote:
> > On Sat, May 14, 2016 at 6:29 PM Roman Shaposhnik 
> > wrote:
> >
> >> On Sat, May 14, 2016 at 3:27 PM, Julian Hyde  wrote:
> >> > My reaction (being ignorant of the machinery behind phonebook and
> >> authorization)
> >> > is that adding to asf-authorization-template on podling creation would
> >> be ok (since it
> >> > is done only once per podling, by a mentor who presumably knows what
> >> they are doing)
> >> > but adding to asf-authorization-template each time a committer is
> >> appointed is probably
> >> > too error-prone.
> >> >
> >> > I might be naive but it seems that the fact that x is a committer to
> >> podling y should be
> >> > represented in one and only one place and the phonebook ought to drive
> >> from that.
> >>
> >> That's where I'm going with this as well.
> >>
> >
> > Unfortunately, I feel that this opinion isn't shared across the entire
> ASF
> > spectrum, see [1] for instance.  Right now, you are correct, my
> > understanding is that we don't want to add podlings to LDAP.  I'm not
> sure
> > the why behind it, and maybe its worth bringing up again.
>
> I'm actually ambivalent about LDAP (although I don't see why not). I'm 100%
> with Julian on having a single DB for podling members. SVN auth file just
> doesn't feel right (especially for those podlings using Git you know).
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: ECCN cryptography reporting?

[Stian Soiland-Reyes]

We documented it in https://issues.apache.org/jira/browse/TAVERNA-959
and on 
https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review

See also 
https://issues.apache.org/jira/browse/LEGAL-250?focusedCommentId=15272500=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15272500


> Taverna Language (while primarily an API for designing workflows) includes a 
> component which functionality is data storage in a ZIP file - the encryption 
> functionality of HTTP Components is however not used, and so Language should 
> not be registered. (unless we make a binary distribution that includes HTTP 
> Components)

> Taverna OSGi's Download API module is "Sending, receiving or storing 
> information" and so should be registered because it is using HTTP Components 
> and can do https.

> Taverna Engine's Credential Manager module is doing "information security" 
> and should be registered.

> Taverna Common Activities are "Sending, receiving or storing information" 
> (talking to web services) and should be registered.

> Taverna Command Line is primarily running a workflow, and should NOT be 
> registered (unless you consider a workflow to be primarily sending/receiving 
> information) - however if we make a binary distribution it would include 
> Bouncy Castle, Derby, HTTPComponents as JARs, and at that point needs to be 
> registered.


The README notes show the findings in detail. See the individual repos.


We have not done a detailed review on the workbench* modules as we are
not yet releasing them - however our release of the above is currently
blocked on this ECCN registration.


On 5 May 2016 at 02:23, Ted Dunning <ted.dunn...@gmail.com> wrote:
> My guess is that this would fall to me.
>
> There is considerable analysis to be done to determine whether filing is
> required.
>
> Are you guys documenting the decision points?
>
>
>
> On Wed, May 4, 2016 at 4:45 AM, Stian Soiland-Reyes <st...@apache.org>
> wrote:
>
>> On 2 May 2016 at 03:23, Stian Soiland-Reyes <st...@apache.org> wrote:
>>
>> > Formally - would it need to be the Incubator PMC chair sending the
>> > ECCN encryption email?
>>
>> Could anyone from IPMC (e.g. our mentors) do it, or just Ted Dunning?
>>
>> --
>> Stian Soiland-Reyes
>> Apache Taverna (incubating), Apache Commons RDF (incubating)
>> http://orcid.org/-0001-9842-9718
>>
>> ---------
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: ECCN cryptography reporting?

[Stian Soiland-Reyes]

I would be happy if Taverna doesn't meet the ECCN registration criteria :)


I think we are not exempt overall from the 2010 decontrolling:

https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items#Three

because we do a lot of "sending and receiving information" - or at
least most Taverna workflows do that.


I would think our Credential Manager is  "designed to use encryption
functionality" - We register handlers with JSSE, in particular to
manage user-accepted client/server certificates (as in the browser).
We don't require JCE Strong Encryption, but recommend you do  (as
otherwise your passphrase is limited to 6 characters!) - we also use
Bouncy Castle (ECCN classified) APIs directly for managing the
keychain.

https://github.com/apache/incubator-taverna-engine/#export-restrictions


Our web service integration use WSS4J and XML Security (also ECCN
classified), and of course the REST service can make https connections
using the above certificate handling.

https://github.com/apache/incubator-taverna-common-activities/#export-restrictions


While the immediate release won't include a binary distribution for
dist.apache.org, we plan that for later releases, and they would
include JARs like Bouncy Castle, HTTPComponent and WSS4J - so while it
could be unclear right now what "use" means - there will be "include"
later.


Likewise some of our Maven Central JARs could include shading of say
Apache HTTPComponents, which is EECN-classified.

On 5 May 2016 at 18:48, John D. Ament <john.d.am...@gmail.com> wrote:
> Ted,
>
> I think that's my point.  It sounds like taverna doesn't meet the criteria.
>
> John
> On May 5, 2016 13:07, "Ted Dunning" <ted.dunn...@gmail.com> wrote:
>
>> John,
>>
>> I love what you do and respect what you say, but do you have a citation for
>> that registration requirement?  Taverna isn't distributing JSSE and it
>> allows weak encryption.
>>
>>
>>
>> On Wed, May 4, 2016 at 7:36 PM, John D. Ament <johndam...@apache.org>
>> wrote:
>>
>> > That's the thing, JSSE is an add-on encryption component in Java.  If the
>> > product requires it, you have to register it.
>> >
>> > Ideally the product shouldn't require it and make it an optional feature
>> to
>> > enable.
>> >
>> > The latter is just my $0.02
>> >
>> > John
>> > On May 4, 2016 21:30, "Ted Dunning" <ted.dunn...@gmail.com> wrote:
>> >
>> > I am pretty dubious that simply building a credential store using
>> standard
>> > JSSE requires registration. Same for HTTPS support.
>> >
>> >
>> >
>> > On Wed, May 4, 2016 at 6:23 PM, Ted Dunning <ted.dunn...@gmail.com>
>> wrote:
>> >
>> > >
>> > > My guess is that this would fall to me.
>> > >
>> > > There is considerable analysis to be done to determine whether filing
>> is
>> > > required.
>> > >
>> > > Are you guys documenting the decision points?
>> > >
>> > >
>> > >
>> > > On Wed, May 4, 2016 at 4:45 AM, Stian Soiland-Reyes <st...@apache.org>
>> > > wrote:
>> > >
>> > >> On 2 May 2016 at 03:23, Stian Soiland-Reyes <st...@apache.org> wrote:
>> > >>
>> > >> > Formally - would it need to be the Incubator PMC chair sending the
>> > >> > ECCN encryption email?
>> > >>
>> > >> Could anyone from IPMC (e.g. our mentors) do it, or just Ted Dunning?
>> > >>
>> > >> --
>> > >> Stian Soiland-Reyes
>> > >> Apache Taverna (incubating), Apache Commons RDF (incubating)
>> > >> http://orcid.org/-0001-9842-9718
>> > >>
>> > >> -
>> > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> > >> For additional commands, e-mail: general-h...@incubator.apache.org
>> > >>
>> > >>
>> > >
>> >
>>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: ECCN cryptography reporting?

[Stian Soiland-Reyes]

On 2 May 2016 at 03:23, Stian Soiland-Reyes <st...@apache.org> wrote:

> Formally - would it need to be the Incubator PMC chair sending the
> ECCN encryption email?

Could anyone from IPMC (e.g. our mentors) do it, or just Ted Dunning?

-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: ECCN cryptography reporting?

[Stian Soiland-Reyes]

Thanks!

We did a dependency clean-up (but not upgrade) as part of license
review. We want to delay some of the upgrades (e.g. to OSGI 5) until
after getting the first full command line release out as this is what
pulls together everything in its lib/.

(Thus this is also why we need to do the encryption review now).


I used

mvn dependency:tree -DoutputFile=`pwd`/target/tree.txt -DappendOutput=true

to check what dependencies we are using across modules - obviously all
the Apache ones are easy to check against
http://www.apache.org/licenses/exports/

but it's harder to check if any of the others are classified or not
beyond heavy googling - e.g.
Jetty is apparantly classified according to
https://dev.eclipse.org/mhonarc/lists/jetty-users/msg05898.html


I wonder if Apache Whisker folks would have any thoughts on how
generating/checking for encryption export dependencies should be
simplified - you would think something like a
META-INF/EXPORT-RESTRICTED in the dependency JARs would work.
(Although some projects put their encryption classification in NOTICE
- I understand this is discouraged?)


Emma seems a bit abandoned (e.g. no Maven 2 plugin) - I know Commons
now use Cobertura and/or JaCoCo - but perhaps those are better to
check coverage of your own code rather than the dependencies.



On 2 May 2016 at 11:22, Martin Gainty <mgai...@hotmail.com> wrote:
> with other apache products to reduce code bloat and reduce deprecated 
> packages you might want to run
> maven dependency:treemvn dependency:tree -Dverbose 
> https://maven.apache.org/plugins/maven-dependency-plugin/examples/resolving-conflicts-using-the-dependency-tree.html
> compare delta(s) with
> emma code coveragehttp://emma.sourceforge.net/
> as I have some spare cycles let me know if I can be of any assistance
> Thanks Stian
> Martin
>
>
>
>> From: st...@apache.org
>> Date: Mon, 2 May 2016 03:23:42 +0100
>> Subject: ECCN cryptography reporting?
>> To: general@incubator.apache.org
>>
>> Hi,
>>
>> Taverna is preparing its cryptography registration for US Export purposes:
>>
>> https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review
>>
>>
>> We want to have this sorted before we make the next release candidate
>> - but we're awaiting LEGAL-250 to see if we can reduce the list of
>> transitive dependencies in this list - it feels excessive if "anything
>> that can do https" needs to be listed (that would presumably affect
>> many more projects)
>>
>>
>> See also http://www.apache.org/dev/crypto.html and already classified
>> ASF products on http://www.apache.org/licenses/exports/
>>
>>
>>
>> Formally - would it need to be the Incubator PMC chair sending the
>> ECCN encryption email?
>>
>> I'll let you know when it's ready to send.
>>
>> --
>> Stian Soiland-Reyes
>> Apache Taverna (incubating), Apache Commons RDF (incubating)
>> http://orcid.org/0000-0001-9842-9718
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

ECCN cryptography reporting?

[Stian Soiland-Reyes]

Hi,

Taverna is preparing its cryptography registration for US Export purposes:

https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review


We want to have this sorted before we make the next release candidate
- but we're awaiting LEGAL-250 to see if we can reduce the list of
transitive dependencies in this list - it feels excessive if "anything
that can do https" needs to be listed (that would presumably affect
many more projects)


See also http://www.apache.org/dev/crypto.html and already classified
ASF products on http://www.apache.org/licenses/exports/



Formally - would it need to be the Incubator PMC chair sending the
ECCN encryption email?

I'll let you know when it's ready to send.

-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Gossip incubator proposal

[Stian Soiland-Reyes]

Ideal would be if Gossip were able to track down original authors and
invite them on as committers (even passive) and get a SGA from them.
Nevertheless SGA(s) for the contributions to the fork would also be good
(although they would also be covered by the Apache license's contribution
clause).

Otherwise there also could also be issues with the name Apache Gossip of
the original "lives on", so you would have to be prepared to change the
name, if needed.
On 21 Apr 2016 6:02 a.m., "Lewis John Mcgibbney" 
wrote:

> Hi Ed,
> If you were able to track down the GoogleCode authors and update this
> thread then that would be good.
>
> @John,
> bq. > I can't speak with 100% certainty, but it sounds like an SGA would be
> > expected prior to importing into an ASF repo.
>
> From whom? The old GoogleCode community who have not touched this codebase
> in over a year? If that is the case then this might get very tricky indeed!
>
> Regardless, this does not block a VOTE on proposing Gossip for the
> Incubator. It is something which may resolve itself at a later date. I
> would suggest that this bridge can be crossed when the Gossip incubating
> community comes to it.
>
> I'll look forward to the Champion opening a VOTE thread.
> Thanks
>
>
> On Tue, Apr 19, 2016 at 6:46 PM,  >
> wrote:
>
> > From: Roman Shaposhnik 
> > To: "general@incubator.apache.org" 
> > Cc:
> > Date: Tue, 19 Apr 2016 08:25:43 -0700
> > Subject: Re: [PROPOSAL] Gossip incubator proposal
> > On Tue, Apr 19, 2016 at 5:55 AM, John D. Ament 
> > wrote:
> > > I can't speak with 100% certainty, but it sounds like an SGA would be
> > > expected prior to importing into an ASF repo.
> >
> > That's the usual protocol.
> >
> > Thanks,
> > Roman.
> >
> >
>

Re: [VOTE] Graduate Zeppelin from the Incubator

[Stian Soiland-Reyes]

+1 (non-binding)

Congratulations on developing a great community!
On 16 Apr 2016 10:01 a.m., "moon soo Lee"  wrote:

> Hi,
>
> Apache Zeppelin started incubating about a year and 4 months ago
> (2014-12-23) and the members of the community think that it is ready to
> graduate from the incubator to be a TLP.
>
> Since it's inception, Zeppelin community has made 3 releases, recruited 4
> PPMC and resolved 500+ issues [1] with 90+ contributors [2]. Now, community
> is very open, active and continuously growing.
>
> The Apache Zeppelin community has discussed and voted on graduation to
> top level
> project.
> The vote passed with 22 +1 votes (9 binding) and no 0 or -1 votes.
>
> Incubation Status:
> http://incubator.apache.org/projects/zeppelin.html
> Maturity Assessment:
>
> https://cwiki.apache.org/confluence/display/ZEPPELIN/Apache+Zeppelin+Project+Maturity+Model
> Discussion:
> https://s.apache.org/gLi0
> https://s.apache.org/GhqY (continue)
> Vote:
> https://s.apache.org/7hCK
> Result:
> https://s.apache.org/1rJD
>
> Please vote on the resolution pasted below to graduate Apache Zeppelin
> from the incubator to top level project.
>
> [ ] +1 Graduate Apache Zeppelin from the Incubator.
> [ ] +0 Don't care.
> [ ] -1 Don't graduate Apache Zeppelin from the Incubator because
>
> This vote will be open for at least 72 hours.
> Many thanks to our mentors and everyone else for the support,
>
> [1] https://s.apache.org/eswD
> [2] https://s.apache.org/gi3o
>
> Apache Zeppelin top-level project 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 a collaborative data analytics and
> visualization tool for general-purpose data processing systems.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Zeppelin Project",
> be and hereby is established pursuant to Bylaws of the
> Foundation; and be it further
>
> RESOLVED, that the Apache Zeppelin Project be and hereby is
> responsible for the creation and maintenance of software
> related to a collaborative data analytics and
> visualization tool for general-purpose data processing systems; and be it
> further
>
> RESOLVED, that the office of "Vice President, Apache Zeppelin" 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 Zeppelin Project, and to have primary responsibility
> for management of the projects within the scope of
> responsibility of the Apache Zeppelin 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 Zeppelin Project:
>
> * Alexander Bezzubov 
> * Anthony Corbacho 
> * Damien Corneau 
> * Felix Cheung 
> * Jongyoul Lee 
> * Kevin Sangwoo Kim 
> * Lee Moon Soo 
> * Mina Lee 
> * Prabhjyot Singh 
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Lee Moon Soo
> be appointed to the office of Vice President, Apache Zeppelin, 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 initial Apache Zeppelin PMC be and hereby is
> tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> Apache Zeppelin Project; and be it further
>
> RESOLVED, that the Apache Zeppelin Project be and hereby
> is tasked with the migration and rationalization of the Apache
> Incubator Zeppelin podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Zeppelin podling encumbered upon the Apache Incubator
> Project are hereafter discharge.
>

Re: [VOTE] Graduate Johnzon from the Incubator

[Stian Soiland-Reyes]

+1 non-binding
On 1 Apr 2016 20:49, "Hendrik Dev"  wrote:

> The Apache Johnzon community has discussed and voted on graduation to
> a top level project. The vote passed with 8 +1 votes (5 from the PPMC)
> and no 0 or -1 votes.
>
> Incubation Status:
> http://incubator.apache.org/projects/johnzon.html
> Maturity Assessment:
> https://s.apache.org/d88S
> Discussions:
> https://s.apache.org/5vxO
> https://s.apache.org/8VkX
> Vote:
> https://s.apache.org/suuK
> (http://markmail.org/message/mawumtfqokgye5xn)
> Result:
> https://s.apache.org/Erd0
> (http://markmail.org/message/qmqvk56ccqkq2gob)
>
> Please vote on the resolution pasted below to graduate Apache Johnzon
> from the incubator to top level project.
>
> [ ] +1 Graduate Apache Johnzon from the Incubator.
> [ ] +0 Don't care.
> [ ] -1 Don't graduate Apache Johnzon from the Incubator because ...
>
> This vote will be open for at least 72 hours.
>
> Many thanks to our mentors and everyone else for the support,
>
> Hendrik Saly on behalf of the Apache Johnzon PPMC
>
> Apache Johnzon top-level project 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 JSR-353 compliant JSON parsing and a
> set of useful modules to help with the usage of JSR-353
> as well as JSR successors (like JSR-374) or related JSRs
> (like JSR-367).
>
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Johnzon Project",
> be and hereby is established pursuant to Bylaws of the
> Foundation; and be it further
>
> RESOLVED, that the Apache Johnzon Project be and hereby is
> responsible for the creation and maintenance of software
> related to JSR-353 compliant JSON parsing and a
> set of useful modules to help with the usage of JSR-353
> as well as JSR successors (like JSR-374) or related JSRs
> (like JSR-367); and be it further
>
> RESOLVED, that the office of "Vice President, Apache Johnzon" 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 Johnzon Project, and to have primary responsibility
> for management of the projects within the scope of
> responsibility of the Apache Johnzon 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 Johnzon Project:
>
> * Justin Mclean 
> * Romain Manni-Bucau 
> * Jean-Louis Monteiro 
> * Mark Struberg 
> * Hendrik Saly 
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Hendrik Saly (salyh)
> be appointed to the office of Vice President, Apache Johnzon, 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 initial Apache Johnzon PMC be and hereby is
> tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> Apache Johnzon Project; and be it further
>
> RESOLVED, that the Apache Johnzon Project be and hereby
> is tasked with the migration and rationalization of the Apache
> Incubator Johnzon podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Johnzon podling encumbered upon the Apache Incubator
> Project are hereafter discharged.
>
> --
> Hendrik Saly (salyh, hendrikdev22)
> @hendrikdev22
> PGP: 0x22D7F6EC
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Graduate Apex from the Incubator

[Stian Soiland-Reyes]

+1 (non-binding)

On 28 March 2016 at 22:20, Pramod Immaneni <pra...@apache.org> wrote:
> The Apache Apex community has discussed and voted on graduation to top
> level project.
> The vote passed with 42 +1 votes (12 from the PPMC) and no 0 or -1 votes.
>
> Maturity Assessment:
> http://apex.incubator.apache.org/maturity.html
> Discussion:
> https://s.apache.org/qrvY
> Vote:
> https://s.apache.org/R8MR
> Result:
> https://s.apache.org/sJIC
>
> Please vote on the resolution pasted below to graduate Apache Apex
> from the incubator to top level project.
>
> [ ] +1 Graduate Apache Apex from the Incubator.
> [ ] +0 Don't care.
> [ ] -1 Don't graduate Apache Apex from the Incubator becauseÖ
>
> This vote will be open for at least 72 hours.
>
> Many thanks to our mentors and everyone else for the support,
>
> Pramod Immaneni, for the Apache Apex PPMC



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: About docker images

[Stian Soiland-Reyes]

Once the docker images are stable you might also want to consider
releasing them as official Docker packages - in which case the Docker
Hub has a repository with external commit references to the recipes -
https://docs.docker.com/docker-hub/official_repos/


See for instance:
https://github.com/docker-library/official-images/blob/master/library/couchdb
https://github.com/docker-library/official-images/blob/master/library/cassandra
https://github.com/docker-library/official-images/blob/master/library/httpd
https://github.com/docker-library/official-images/blob/master/library/maven
https://github.com/docker-library/official-images/blob/master/library/solr
https://github.com/docker-library/official-images/blob/master/library/thrift
https://github.com/docker-library/official-images/blob/master/library/tomcat

Varying practices and levels of officialness there - I notice none of
those reference https://github.com/apache/*


On 1 April 2016 at 02:51, Gino Bustelo <lbust...@gmail.com> wrote:
> Thanks Jake. I'll reach out once we are closer to being ready.
>
> Gino B.
>
>> On Mar 31, 2016, at 8:38 PM, Jake Farrell <jfarr...@apache.org> wrote:
>>
>> We do not enable direct push to Docker hub, we can setup the automated hook
>> for building a given Dockerfile at a set path for master or tags, but there
>> are no plans to allow direct push at this time. We do have a Bintray
>> account which is available for ASF use and we can host Docker images there
>> that projects can control if the automated route does not fit the needed
>> solution. If you have any questions please let me know
>>
>> -Jake
>>
>>> On Thu, Mar 31, 2016 at 5:36 PM, Gino Bustelo <g...@bustelos.com> wrote:
>>>
>>> What would be the process to push Docker images for an incubator project to
>>> https://hub.docker.com/r/apache/?
>>>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Airflow into the Incubator

[Stian Soiland-Reyes]

+1 (non-binding)
On 25 Mar 2016 03:00, "Siddharth Anand"  wrote:

> Following the discussion earlier:
> https://s.apache.org/AirflowDiscussion
>
> I would like to call a VOTE for accepting Airflow as a new incubator
> project.
>
> The proposal is available at:
> https://wiki.apache.org/incubator/AirflowProposal
>
> The proposal is also included at the bottom of this email.
>
> Vote is open until at least Tues, 29 March 2016, 23:59:00 PDT
> [ ] +1 accept Airflow into the Apache Incubator
> [ ] ±0
> [ ] -1 because...
>
> +1 (non-binding)
>
> Thanks,
> -s (Sid)
>
>
> == Abstract ==
>
> Airflow is a workflow automation and scheduling system that can be
> used to author and manage data pipelines.
>
> == Proposal ==
>
> Airflow provides a system for authoring and managing workflows a.k.a.
> data pipelines a.k.a. DAGs (Directed Acyclic Graphs). The developer
> authors DAGs in Python using an Airflow-provided framework. He/She
> then executes the DAG using Airflow’s scheduler or registers the DAG
> for event-based execution. A web-based UI provides the developer with
> a range of options for managing and viewing his/her data pipelines.
> Background
>
> Airflow was developed at Airbnb to enable easier authorship and
> management of DAGs than were possible with existing solutions such as
> Oozie and Azkaban. For starters, both Oozie and Azkaban rely on one or
> more XML or property files to be bundled together to define a
> workflow. This separation of code and config can present a challenge
> to understanding the DAG - in Azkaban, a DAG’s structure is reflected
> by its file system tree and one can find himself/herself traversing
> the file system when inspecting or changing the structure of the DAG.
> Airflow workflows, on the other hand, are simply and elegantly defined
> in Python code, often a single file. Airflow merges the powerful
> Web-based management aspects of projects like Azkaban and Oozie with
> the simplicity and elegance of defining workflows in Python. Airflow,
> less than a year old in terms of its Open Source launch, is currently
> used in production environments in more than 30 companies and boasts
> an active contributor list of more than 100 developers, the vast
> majority of which (>95%) are outside of Airbnb.
>
> We would like to share it with the ASF and begin developing a
> community of developers and users within Apache.
>
> == Rationale ==
>
> Many organizations (>30) already benefit from running Airflow to
> manage data pipelines. Our 100+ contributors continue to provide
> integrations with 3rd party systems through the implementation of new
> hooks and operators, both of which are used in defining the tasks that
> compose workflows.
>
> == Current Status ==
>
> === Meritocracy ===
>
> Our intent with this incubator proposal is to start building a diverse
> developer community around Airflow following the Apache meritocracy
> model. Since Airflow was open-sourced in mid-2015, we have had fast
> adoption and contributions by multiple organizations the world over.
> We plan to continue to support new contributors and we will work to
> actively promote those who contribute significantly to the project to
> committers.
>
> === Community ===
>
> Airflow is currently being used in over 30 companies. We hope to
> extend our contributor base significantly and invite all those who are
> interested in building large-scale distributed systems to participate.
>
> === Core Developers ===
>
> Airflow is currently being developed by four engineers: Maxime
> Beauchemin, Siddharth Anand, Bolke de Bruin, and Chris Riccomini.
> Chris is a member of the Apache Samza PMC and a contributor to various
> Apache projects, including Apache Kafka and Apache YARN. Maxime,
> Siddharth, and Bolke have contributed to Airflow.
>
> === Alignment ===
> The ASF is the natural choice to host the Airflow project as its goal
> of encouraging community-driven open-source projects fits with our
> vision for Airflow.
>
> == Known Risks ==
>
> === Orphaned Products ===
>
> The core developers plan to work part time on the project. There is
> very little risk of Airflow being abandoned as all of our companies
> rely on it.
>
> === Inexperience with Open Source ===
>
> All of the core developers have experience with open source
> development. Chris is a member of the Apache Samza PMC and a
> contributor to various Apache projects, including Apache Kafka and
> Apache YARN. Bolke is contributor on multiple open source projects and
> a few Apache projects as well, including Apache Hive, Apache Hadoop,
> and Apache Ranger.
>
> === Homogeneous Developers ===
>
> The current core developers are all from different companies. Our
> community of 100 contributors hail from over 30 different companies
> from across the world.
>
> === Reliance on Salaried Developers ===
>
> Currently, the only developer paid to work on this project is Maxime.
>
> === Relationships with Other Apache Products ===
>
> Airflow is 

Re: [PROPOSAL] : Airflow

[Stian Soiland-Reyes]

The Airflow project seem to be in good shape! :)


As for mailing list transition, I'm afraid that can be a bit rough for
any community. You can't simply set up forwarding as then the users
would not get any replies to the new list.

Each individual user will have to subscribe again to the new lists,
using email commands, like how you subscribed to this list.


Here's an example of how we provide instructions:
http://taverna.incubator.apache.org/community/lists
(You will notice we link to markmail.org as archive, which has a good
search facility and seems to pick up emails faster than
http://mail-archives.apache.org/ )


If you have access to the existing subscriber list it is possible to
script some emails that effectively invite them to the list - they
would then need to do the usual confirm reply to sign up.  This is
what we did with Taverna mailing lists, after extracting the existing
subscriber list from Mailman. I am not sure if Google Groups would
give you the email addresses though.  (If you choose to do this, warn
the old list well in advance on the existing lists so people will know
to reply!).

Let me know if anyone need the evil script ..


As for your roadmap, I would recommend doing the first Apache release
as a point-release "as is" after clearing any important Intellectual
Property issues - and then work on big new features after that. This
adds continuity to the project and helps you understand differences in
the release process early. (I'm saying this with hindsight bias..:)


If there are no further suggestions to your proposal, then I suggest
you to send it again, adding [VOTE] to the subject :)


On 21 March 2016 at 21:23, Siddharth Anand <san...@agari.com.invalid> wrote:
> Hi Stian,
> Thanks for the feedback. We are committed to moving towards Apache
> community-friendly licensing as documented on
> http://www.apache.org/legal/resolved.html#category-x
>
> I've added this to our Roadmap:
> https://github.com/airbnb/airflow/wiki/Roadmap and I expect to tackle it
> during the incubation phase.
>
> Regarding our Google group - yes. We will move to the
> d...@airflow.incubator.apache.org mailing list.  We currently have *258
> members*, with about 10 new members being added daily! If you have any
> thoughts on how to make that transition more amenable to our community,
> they are welcome. For one, the google group offers more functionality than
> the old-style mailing lists. I don't mind moving. I would like to keep the
> old group's messages searchable and provide an announcement feature to
> point people to the Apache mailing list so they know where to go next if
> they land on the Google group. Some threads will unfortunately be
> decapitated, but we can provide a few months' time for our users to
> transition to the Apache mailing lists, wrapping up topic threads or
> copying them over.  We will also need to stop accepting new members and
> posts in the existing group, but I think that is pretty simple to do.
>
> Thanks for the heads up on CWL and Taverna. We will definitely look into
> both. On our side, our user base is growing faster than we can keep up.
> Hence, we are investing in growing the committer base and documentation,
> and in leveraging processes in order to better meet the growing needs of
> our community. We hope to reduce turn-around time on PR reviews/merges,
> time between releases, bringing new developers on board, and converting
> contributors to committers.
>
>
> -s
>
> On Mon, Mar 21, 2016 at 4:23 PM, Stian Soiland-Reyes <st...@apache.org>
> wrote:
>
>> Airflow sounds like an interesting workflow project!
>>
>>
>> You will need to review the licenses of dependencies - some of them
>> are not compatible with ASF policy [1], e.g.
>>
>> https://pypi.python.org/pypi/psycopg2
>> is LGPL, which is not permitted.
>>
>> (I didn't check all of them)
>>
>> You may be able to work around this particular one if you are using
>> Python's DB API 2.0 and don't have an explicit dependency on psycopg2
>> (e.g. so a downstream user can reasonably use Airflow without
>> psycopg2)
>>
>>
>> (Note: you can solve this as part of incubation process - but say if
>> your project strongly used 15 GPL and LGPL dependencies, then your
>> project might want to reconsider if it would be worth the effort)
>>
>>
>>
>> I recognize the challenge of engaging extension developers to also
>> care about the 'core'. Moving to an "Apache Way" open development will
>> probably help for this, as all dev discussions are in the open. Is
>> your plan to move the existing Airflow Google Groups to what will be
>> the d...@airflow.incubator.apache.org mailing list?
>>
>>
>> Have you b

Re: [PROPOSAL] : Airflow

[Stian Soiland-Reyes]

Airflow sounds like an interesting workflow project!


You will need to review the licenses of dependencies - some of them
are not compatible with ASF policy [1], e.g.

https://pypi.python.org/pypi/psycopg2
is LGPL, which is not permitted.

(I didn't check all of them)

You may be able to work around this particular one if you are using
Python's DB API 2.0 and don't have an explicit dependency on psycopg2
(e.g. so a downstream user can reasonably use Airflow without
psycopg2)


(Note: you can solve this as part of incubation process - but say if
your project strongly used 15 GPL and LGPL dependencies, then your
project might want to reconsider if it would be worth the effort)



I recognize the challenge of engaging extension developers to also
care about the 'core'. Moving to an "Apache Way" open development will
probably help for this, as all dev discussions are in the open. Is
your plan to move the existing Airflow Google Groups to what will be
the d...@airflow.incubator.apache.org mailing list?


Have you been talking to the SciDap folks doing Common Workflow
Language [3] support with Airflow? That could be one angle to look at
increasing the user base. We're also working on Docker and CWL support
in Apache Taverna [4] - so I'm interested in seeing what we could have
in common!


[1] http://www.apache.org/legal/resolved.html
[2] https://github.com/SciDAP/scidap
[3] http://www.commonwl.org/
[4] http://taverna.incubator.apache.org/

On 17 March 2016 at 00:28, Siddharth Anand <san...@agari.com.invalid> wrote:
> https://wiki.apache.org/incubator/AirflowProposal
>
> Thoughts and comments are welcome!
> -s (Sid)



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Hosting links to pre-Apache releases

[Stian Soiland-Reyes]

On 14 March 2016 at 23:52, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> Agreed. The good news is that the previous license has an added benefit
> of being compatible with ALv2, but of course we still have to be crystal clear
> on that.
>
> Any good example of this that currently exist in ASF?

Here's an example of how we do the non-ASF download links for
Taverna Workbench (as we have not yet released the Workbench
repository under ASF):

https://taverna.incubator.apache.org/download/workbench/

(Comments welcome!)

To play safe we made it so the *.exe download links here actually
don't download directly, but go to a third-party legacy page where you
have to select again.   It could be that such a page could just be a
Launchpad, BinTray,  BitBucket or GitHub Releases, which should be
good alternatives for hosting the pre-Apache binaries.  So perhaps you
would be able to link to say
https://github.com/madlib/madlib/releases/tag/v1.7.0 ?

It should be easy for madlib's case as you don't have binary distributions.


>> Note we probably don't want to host the actual downloads themselves;
>> just point to the existing old download page.
> Actually, we'd rather move the bits to ASF infra (if that's ok).

Hmm... although their Apache license would permit this, those earlier
releases has not gone through IP review.

I think this would be confusing as then ASF would be hosting downloads
for non-ASF-vetted releases - which would also be against policy.
Technically ASF also uses the mirror network for downloads - do we
want to inject non-ASF releases there?


-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: IP clearance for importing repos

[Stian Soiland-Reyes]

Yes, a full Software Grant is needed. This forms the basis of the
podling's code base and is a significant contribution that would
otherwise require IP clearance, the original contributors (the legal
copyright holders) need to sign a software grant, sent to
secret...@apache.org.

Only once the secretary emails the private@milagro list back to
confirm reception of the Software Grant can you import the code base
to git.apache.org.


As your code base is Apache-licensed it should normally be sufficient
to have a software grant from the 'original' rights holder per
repository (Certivox?) - as any later contributions would have been
covered by clause 5 in the license:
http://www.apache.org/licenses/LICENSE-2.0#contributions

However any larger contributions in the past may still needs to be
part of the grant (e.g. if NTT contributors added a new module rather
than just fixing some bugs, NTT should also sign the Software Grant).


For more details, see
http://incubator.apache.org/guides/mentor.html#initial-ip-clearance

On 11 March 2016 at 14:30, Nick Kew <n...@apache.org> wrote:
> [note crosspost]
>
> The Milagro podling is looking to import several repos from github
> (enumerated at https://issues.apache.org/jira/browse/MILAGRO-1 ).
>
> They're already Apache-Licensed.  Do we need a full Software
> Grant before importing to the Incubator, or is it sufficient to
> clear that before graduating?
>
> --
> Nick Kew
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[ANNOUNCE] Apache Taverna Language 0.15.1-incubating and Apache Taverna OSGi 0.2.1-incubating

[Stian Soiland-Reyes]

The Apache Taverna (incubating) team is pleased to announce the
release of Apache Taverna Language 0.15.1-incubating and Apache
Taverna OSGi 0.2.1-incubating.

This release note is also available at https://s.apache.org/2016-04-12-tavlang


This release of Taverna Language is an update that fixes bugs and also
adds the Tavlang Tool, contributed by Menaka Madushanka (sponsored by
Google Summer of Code 2015).

Taverna Language is available for download from
https://taverna.incubator.apache.org/download/language/


This release of Taverna OSGi Plugin System will support the upcoming
Apache releases of the Taverna Engine, Taverna Common Activities and
Taverna Command Line.

Taverna OSGi is available for download from
https://taverna.incubator.apache.org/download/osgi/


# New Features

## Addition of Tavlang Tool to Taverna Language

The Taverna Language command line (tavlang) tool accesses the features
of the Taverna language modules. The tool has the following functions:

– Conversion
– Inspection
– Validation
– Viewing workflow statistics.

For more information, see the Apache Taverna Tavlang Tool README:
https://s.apache.org/tavlang


## Taverna OSGi plugin system

This is the first release of Apache Taverna OSGi plugin system, a
plugin system for Java console and desktop applications using OSGi,
including an online update mechanism.

For an overview, see the Taverna OSGi README: https://s.apache.org/taverna-osgi


# Improvements/Enhancements

## wfdesc export

The module taverna-scufl2-wfdesc is now enabled in the build of
Taverna Language.This includes export of workflow structures in RDF
Turtle format using the vocabulary http://purl.org/wf4ever/wfdesc


# Removed / Retired features

The taverna-scufl2-wfdesc module is no longer runnable as a standalone
JAR - this has been superseded by the new tavlang tool.


# Bug Fixes

See JIRA change notes:

Apache Taverna Parent:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12333249=12318322

Apache Taverna Language:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12333250=12318322

Apache Taverna OSGi:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12332248=12318322


# Known Issues

See JIRA:

Apache Taverna Parent:
https://issues.apache.org/jira/browse/TAVERNA/component/12326807

Apache Taverna Language:
https://issues.apache.org/jira/browse/TAVERNA/component/12326808

Apache Taverna OSGi:
https://issues.apache.org/jira/browse/TAVERNA/component/12326809


# Installation Information

Package names have changed to begin with org.apache.taverna and source
code has been reorganized.


## Prerequisites

Java 1.8 or newer. (Tested with OpenJDK 1.8.)
Apache Maven 3.2.5 or newer. (Older versions will probably work.)

## Installation

Taverna Language download instructions:
https://taverna.incubator.apache.org/download/language/

Taverna OSGi download instructions:
https://taverna.incubator.apache.org/download/osgi/


# Stay Informed

Please subscribe to and contact the dev@taverna mailing list for any
questions, suggestions, and discussions about Apache Taverna.
https://taverna.incubator.apache.org/contact


Bugs and feature plans are tracked in the JIRA Issue tracker under the
TAVERNA components language and osgi. Anyone may add an issue.
http://taverna.incubator.apache.org/community/issue-tracker

More details:
http://taverna.incubator.apache.org/


# Disclaimer

Apache Taverna is an effort undergoing incubation at The Apache
Software Foundation (ASF) sponsored by the 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.



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[RESULT] [VOTE] Release taverna-language-0.15.1-incubating-RC5 and taverna-osgi-0.2.1-incubating-RC5

[Stian Soiland-Reyes]

This vote has PASSED with 3 +1 binding votes from IPMC members, and no
0 or -1 votes.

Votes:

+1 Marlon Pierce
+1 Justin Mclean
+1 Suresh Marru

Thread:
http://markmail.org/message/rdcwpfxmqf6rjfsm
http://mail-archives.apache.org/mod_mbox/incubator-general/201603.mbox/%3CCAMBJEmUwZZm0k9Uy4Jtd4MAeGTUC0x4Lk%2BQ8b_mmtSNvLUn4WQ%40mail.gmail.com%3E


On behalf of the Apache Taverna (incubating) PPMC, thank you to all
who reviewed and voted on this release candidate!

I will proceed with promoting the release candidates.



On 2 March 2016 at 17:07, Stian Soiland-Reyes <st...@apache.org> wrote:
> I am pleased to be calling this vote for the source release of
>
>   Apache Taverna Maven Parent 2-incubating
>   Apache Taverna Language 0.15.1-incubating
>   Apache Taverna OSGi plugin system 0.2.1-incubating
>
> The Apache Taverna IPMC has voted in favour of this release with 5 IPMC votes:
>
> http://markmail.org/message/346xxkywuexw6z52
> http://mail-archives.apache.org/mod_mbox/taverna-dev/201603.mbox/<cambjemvv0asztfxwkulqpood1-cfwfydpf320fq_rzgkcuj...@mail.gmail.com>
>
> We now ask for the Incubator PMC to vote on this release candidate.
>
>
> Apache Taverna Language is a set of APIs for workflow definitions
> (SCUFL2) and workflow inputs/outputs/run (DataBundle), as consumed and
> produced by the Apache Taverna workflow system. The API includes
> support for working with Research Object Bundles, and loading/saving
> Taverna workflows in different formats.
>
> Apache Taverna OSGi is a plugin system for OSGi with support for
> online updates, which can be used by Java desktop and command line
> applications.
>
>
> The release candidates to be voted over are available at:
>
>   
> https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna-parent-2-incubating-RC5/
>   
> https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna-language-0.15.1-incubating-RC5/
>   
> https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna-osgi-0.2.1-incubating-RC5/
>
>
> Checksums:
>
> md5sum:
> 8e7ee332896d314877af481b348dbf51
> apache-taverna-parent-2-incubating-source-release.zip
>
> 6bd8ae9e2b1bc2e675e5573b87feaa2a
> apache-taverna-language-0.15.1-incubating-source-release.zip
>
> 4d595212a813f62a0c16a31d3a872af4
> apache-taverna-osgi-0.2.1-incubating-source-release.zip
>
>
> sha1sum:
> d4b675763eb03bc5a9863db27779d725e1209af6
> apache-taverna-parent-2-incubating-source-release.zip
>
> af3a14ec6d9386e9aa97309275f7b147be6f0a38
> apache-taverna-language-0.15.1-incubating-source-release.zip
>
> 2e91b5176322c0e029e1a856f0752159b1564158
> apache-taverna-osgi-0.2.1-incubating-source-release.zip
>
>
> sha512sum:
> d5787ba7066d0d3b7c3b292434eb3de909c8ebaf43f0a3ea5e9dd25f0f19b5c1b7d508ffde97c0e6afd53265835d1aa4f22bb3187011b50b7f5aac99892bd0aa
> apache-taverna-parent-2-incubating-source-release.zip
>
> 7cb4860abb4c57b91e81703a0d362d2824f10f1d2abe62c3df028fdca4f3ce33c4fe572c3349e629c8d409a7b25f3c86b79487d840c642a4b39e84432aa86c04
> apache-taverna-language-0.15.1-incubating-source-release.zip
>
> 31b50a87243a01f3a5a657643d0f3b7f56d86fcc309df74392df3915ef8a787948ff8c74bc6a7684e6f9049b6430324373c50959ff658803dbc2d67d8a3dc45c
> apache-taverna-osgi-0.2.1-incubating-source-release.zip
>
>
>
> To build the release candidates you need Apache Maven 3 and Java 8.
>
>
> Build the release candidate, in the above order, using:
>
> mvn clean install
>
>
> The release candidates correspond to the following git commits:
>
>   
> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-maven-parent.git;a=commit;h=d34dd67fcfa11caead08008d37279b1ea546e3ec
>
>   
> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-language.git;a=commit;h=66866a5454ed23262c055f65155d7a195c68a17d
>
>   
> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-osgi.git;a=commit;h=0b7da331e81febade5ce2f4cf1f068013002b7aa
>
>
> Release candidates are signed with a GPG key available at:
>
>   https://dist.apache.org/repos/dist/release/incubator/taverna/KEYS
>
> A staged Maven repository is available for review at:
>
>   https://repository.apache.org/content/repositories/orgapachetaverna-1011/
>
> The changelog for this release is available from JIRA:
>
>   
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12333249=12318322
>   
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12333250=12318322
>   
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12332248=12318322
>
>
> Please vote on releasing these packages as:
>
>   Apache Taverna Maven Parent 2-incubating
>   Apache Taverna Language 0.15.1-incubating
>   Apache Taver

Re: [VOTE] Release taverna-language-0.15.1-incubating-RC5 and taverna-osgi-0.2.1-incubating-RC5

[Stian Soiland-Reyes]

Hi folks,

With Justin revising his vote to +1 we just need one more binding +1 for
this release candidate from the Taverna podling.

Would someone else have time for a quick review..?
On 3 Mar 2016 16:13, "Pierce, Marlon" <marpi...@iu.edu> wrote:

> Hello Incubator,
>
> Apache Taverna is looking for new active mentors [1] and in the meantime
> will need your help with this vote.
>
> Thanks,
>
> Marlon
>
> [1]
> https://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3CCAMBJEmW6ezFS7Dtsxo2FwSV7dXj1MPQ_=efuiqmkcvsqcj7...@mail.gmail.com%3E
>
>
>
> On 3/2/16, 12:07 PM, "Stian Soiland-Reyes" <st...@apache.org> wrote:
>
> >I am pleased to be calling this vote for the source release of
> >
> >  Apache Taverna Maven Parent 2-incubating
> >  Apache Taverna Language 0.15.1-incubating
> >  Apache Taverna OSGi plugin system 0.2.1-incubating
> >
> >The Apache Taverna IPMC has voted in favour of this release with 5 IPMC
> votes:
> >
> >http://markmail.org/message/346xxkywuexw6z52
> >http://mail-archives.apache.org/mod_mbox/taverna-dev/201603.mbox/<
> cambjemvv0asztfxwkulqpood1-cfwfydpf320fq_rzgkcuj...@mail.gmail.com>
> >
> >We now ask for the Incubator PMC to vote on this release candidate.
> >
> >
> >Apache Taverna Language is a set of APIs for workflow definitions
> >(SCUFL2) and workflow inputs/outputs/run (DataBundle), as consumed and
> >produced by the Apache Taverna workflow system. The API includes
> >support for working with Research Object Bundles, and loading/saving
> >Taverna workflows in different formats.
> >
> >Apache Taverna OSGi is a plugin system for OSGi with support for
> >online updates, which can be used by Java desktop and command line
> >applications.
> >
> >
> >The release candidates to be voted over are available at:
> >
> >
> https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna-parent-2-incubating-RC5/
> >
> https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna-language-0.15.1-incubating-RC5/
> >
> https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna-osgi-0.2.1-incubating-RC5/
> >
> >
> >Checksums:
> >
> >md5sum:
> >8e7ee332896d314877af481b348dbf51
> >apache-taverna-parent-2-incubating-source-release.zip
> >
> >6bd8ae9e2b1bc2e675e5573b87feaa2a
> >apache-taverna-language-0.15.1-incubating-source-release.zip
> >
> >4d595212a813f62a0c16a31d3a872af4
> >apache-taverna-osgi-0.2.1-incubating-source-release.zip
> >
> >
> >sha1sum:
> >d4b675763eb03bc5a9863db27779d725e1209af6
> >apache-taverna-parent-2-incubating-source-release.zip
> >
> >af3a14ec6d9386e9aa97309275f7b147be6f0a38
> >apache-taverna-language-0.15.1-incubating-source-release.zip
> >
> >2e91b5176322c0e029e1a856f0752159b1564158
> >apache-taverna-osgi-0.2.1-incubating-source-release.zip
> >
> >
> >sha512sum:
>
> >d5787ba7066d0d3b7c3b292434eb3de909c8ebaf43f0a3ea5e9dd25f0f19b5c1b7d508ffde97c0e6afd53265835d1aa4f22bb3187011b50b7f5aac99892bd0aa
> >apache-taverna-parent-2-incubating-source-release.zip
> >
>
> >7cb4860abb4c57b91e81703a0d362d2824f10f1d2abe62c3df028fdca4f3ce33c4fe572c3349e629c8d409a7b25f3c86b79487d840c642a4b39e84432aa86c04
> >apache-taverna-language-0.15.1-incubating-source-release.zip
> >
>
> >31b50a87243a01f3a5a657643d0f3b7f56d86fcc309df74392df3915ef8a787948ff8c74bc6a7684e6f9049b6430324373c50959ff658803dbc2d67d8a3dc45c
> >apache-taverna-osgi-0.2.1-incubating-source-release.zip
> >
> >
> >
> >To build the release candidates you need Apache Maven 3 and Java 8.
> >
> >
> >Build the release candidate, in the above order, using:
> >
> >mvn clean install
> >
> >
> >The release candidates correspond to the following git commits:
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-maven-parent.git;a=commit;h=d34dd67fcfa11caead08008d37279b1ea546e3ec
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-language.git;a=commit;h=66866a5454ed23262c055f65155d7a195c68a17d
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-osgi.git;a=commit;h=0b7da331e81febade5ce2f4cf1f068013002b7aa
> >
> >
> >Release candidates are signed with a GPG key available at:
> >
> >  https://dist.apache.org/repos/dist/release/incubator/taverna/KEYS
> >
> >A staged Maven repository is available for review at:
> >
> >
> https://repository.apache.org/content/repositories/orga

Re: Short form IP clearance

[Stian Soiland-Reyes]

So perhaps the clarification (beyond removing SVN reference) would be that
IPMC just records the IP clearance documents for TLPs, and each clearance
mentioned on incubator list gives a possibility to get insight from IPMC
members who do IP clearance more often than each TLP on its own.

However this could not be subject to an IPMC vote, the incubator plays more
of a registrar role.

Obviously any -1 vote from IPMC should be considered by the TLP just like
on their own lists, but ultimately the decision could be the TLPs, which
might have to consult legal (which would look at what the incubator said).

My £0.014. :)
On 8 Mar 2016 16:44, "Jim Jagielski"  wrote:

> This has not been formally or officially requested and/or demanded
> by the Incubator to Legal Affairs.
>
> W/ my legal affairs hat on, I am not going to "take away"
> responsibility from a PMC unless it is required or asked
> or demanded of Legal Affairs. As of right now, this responsibility
> is still the IPMCs until changed.
>
> > On Mar 7, 2016, at 11:45 PM, John D. Ament 
> wrote:
> >
> > Just to follow up on this thread, were the changes ever completed?
> >
> > On Sun, Nov 1, 2015 at 2:20 PM William A Rowe Jr 
> > wrote:
> >
> >> On Sun, Nov 1, 2015 at 6:38 AM, Sam Ruby 
> wrote:
> >>
> >>> On Sun, Nov 1, 2015 at 7:20 AM, Marvin Humphrey <
> mar...@rectangular.com>
> >>> wrote:
>  On Sun, Nov 1, 2015 at 3:41 AM, John D. Ament 
> >>> wrote:
> > I don't think anyone in the incubator is begging to be responsible.
> >> We
> > just need a new process defined.
> 
>  Actually, since the Incubator continues to receive criticism for its
>  role in IP Clearance, I specifically request that the Incubator be
>  relieved of that role. If having the Incubator hold the power to
>  "meddle" causes such alarm, the Board should find somebody else to do
>  this work.
> >>>
> >>> I don't think we should be looking to the Board directly for this, we
> >>> should be looking to Legal Affairs to reaffirm, adjust, or revoke this
> >>> arrangement.
> >>>
> >>
> >> And Legal Affairs has tangential control over Incubator, but the board
> is
> >> responsible
> >> for the IPMC charter, so if you want to change the scope of this
> project,
> >> the board
> >> is the final arbiter.
> >>
> >> Some of this might be confusion over Incubator's role.  From memory,
> >> incubator
> >> generally didn't 'vote' on incoming other PMC code bases, but maintained
> >> the
> >> canonical list of imports (the format is this committee's creation and
> >> choice),
> >> and the general@i.a.o list was used to 'announce' the importation of
> >> external
> >> code bases.  If someone at g@i.a.o noticed something amiss, they are
> >> always
> >> welcome to point out whatever IP provenance issue they perceive to a
> >> receiving
> >> committee (often the IPMC itself for incubating code bases).
> >>
> >> If we trust the importing PMC to understand IP provenance, which we do
> >> because
> >> each of them maintain code bases, than this whole issue of IPMC
> non-voting
> >> vs. record keeping becomes much simpler.  Since the IPMC is good at
> >> specific
> >> things, such as recording entry to the ASF, it still seems like a smart
> >> place for
> >> the records.  The alternative seems like adding a converse to the attic
> >> project,
> >> perhaps we could title it Apache Doormat?
> >>
> >>> We have enough to worry about with our primary responsibility of
>  incubating podlings. We don't need more reasons for powers-that-be to
>  give us grief.
> >>>
> >>> The powers that be (a.k.a., the board) either need to reinstate Jim as
> >>> VP of Affairs or find a replacement, and then hold that individual
> >>> (and associated committee) accountable for revisiting this issue.
> >>>
> >>
> >> That's extra confusing, I don't see where in the prior meeting minutes
> or
> >> any
> >> other ASF resources where there is not an active VP Legal Affairs?  I
> think
> >> you are confusing process (act of resigning, recognition of a
> resignation,
> >> appointing a replacement) with the actual motivation for someone to hold
> >> a role.
> >>
> >> You did a nice job of reinforcing Marvin's concern about
> micromanagement.
> >> Reading this statement above and the tone you used, I personally
> wouldn't
> >> be keen to serve as an officer under your directatorship.  /boggle
> >>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Copyright sign offs

[Stian Soiland-Reyes]

Basically http://incubator.apache.org/projects/datafu.html does not
include any timestamps for the sections Copyright and Verify
Distribution Right. So we don't know if this has happened or not.

In fact no dates appear in this particular incubator, so I guess it's
just not updated. Some email archive digging might be required to find
the right dates..

https://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/datafu.xml
is the file to update.

On 7 March 2016 at 04:49, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> Henri, it seems I'm a bit lost with your terminology. See the question bellow:
>
> On Fri, Feb 26, 2016 at 5:28 PM, Henri Yandell <bay...@apache.org> wrote:
>> Haven't done this in a while :)
>>
>> Thought I'd share that the following podlings have not yet signed off on
>> their Copyright sections in their status reports.
>
> What does it mean exactly? For example...
>
>>   datafu
>
> ...what is the actionable item I need to bring up with this community?
>
>> I'd be interested to hear about any reasons why the above aren't able to
>> sign that element of their status file off.
>>
>> (same, but for those who are < 6 months in the incubator, ie) still working
>> on it)
>>
>>   fineract
>
> Ditto here.
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release taverna-language-0.15.1-incubating-RC5 and taverna-osgi-0.2.1-incubating-RC5

[Stian Soiland-Reyes]

Thank you for a thorough review!

We've started tracking the Category B issues at
https://issues.apache.org/jira/browse/TAVERNA-927
We would appreciate your insight and help as we are a bit short on
active mentors! :-)



The ZIP files under the test directory needs to be zipped because the
Taverna Language deals (in part) with reading and writing a
zip-derived file format.

I've fixed in git master the workflowrun.bundle.zip internal LICENSE
file which was missing the appendix so it should be fine for next
release.


As for code signature, the release candidate and Maven artifacts are
signed by st...@apache.org A0FFD119 which is listed in KEYS. I
switched my primary UID so that st...@apache.org is on the top and
updated
https://dist.apache.org/repos/dist/release/incubator/taverna/KEYS
(See http://unix.stackexchange.com/a/153310 )


(BTW - we used to update KEYS from
https://people.apache.org/keys/group/taverna.asc to make sure that
id.apache.org had the openpgp fingerprint - but this has gone 404 in
the recent update of home.apache.org together with most incubator
groups)

On 5 March 2016 at 23:02, Justin Mclean <jus...@classsoftware.com> wrote:
> Hi,
>
> Sorry it -1 binding due to Category B software in a source release. [10]
>
> I checked:
> - artefacts contain incubating
> - signature and hashes good
> - DISCLAIMER exists
> - LICENSE is good however it lists Category B software
> - NOTICE is good
> - There are a couple of binary files (under the test directory) do these need 
> to be zipped?
> - All source files have headers
>
>
> There are some licensing issues:
> - Several items [3][4][5][6] are licensed under W3C document license, this is 
> not a category A license and looks like they can only be included in binary 
> release [2]. (i.e. Category B but it's not listed) You may need to clarify 
> this on legal discuss.
> - Files [8][9][16][17][18][19][20] licensed under CC-BY-3 can only be 
> included in a binary release. [10]
> - I assume CC-A [11][12] would also need to be handled the same way.
> - It is unclear how [13] is licensed.
> - Looks like [14][15] are not licensed under a Category A license. Again 
> probably needs to be discussed on legal discuss.
>
> The LICENSE and NOTICE in ./taverna-tavlang-tool/src/main/resources/META-INF/ 
> may need updating, looks like the contents don’t match the top level license 
> and year is incorrect.
>
> Also:
> - Please consider signed the artefacts with an apache email address.
> - The workflowrun.bundle.zip [1] file contains a LICENSE which is missing the 
> appendix
>
> Thanks,
> Justin
>
> 1. 
> apache-taverna-language-0.15.1-incubating/taverna-robundle/src/test/resources/workflowrun.bundle.zip
> 2. https://issues.apache.org/jira/browse/LEGAL-111
> 3. 
> ./taverna-scufl2-schemas/src/main/resources/org/apache/taverna/scufl2/rdfxml/xsd/xml.xsd
> 4. ./taverna-robundle/src/main/resources/ontologies/prov-aq.rdf
> 5. ./taverna-robundle/src/main/resources/ontologies/prov-o.rdf
> 6. ./taverna-robundle/src/main/resources/ontologies/prov-o.rdf
> 7. ./taverna-robundle/src/main/resources/ontologies/dcam.owl
> 8. ./taverna-robundle/src/main/resources/ontologies/dcam.owl
> 9. ./taverna-robundle/src/main/resources/ontologies/dcterms_od.owl
> 10. http://www.apache.org/legal/resolved.html#category-b
> 11. ./taverna-robundle/src/main/resources/ontologies/foaf.rdf
> 12. ./taverna-scufl2-wfdesc/src/main/resources/com/xmlns/foaf/foaf.rdf
> 13. ./taverna-robundle/src/main/xsd/xenc-schema.xsd
> 14. ./taverna-robundle/src/main/resources/ontologies/oa.rdf
> 15. ./taverna-robundle/src/main/resources/ontologies/ro.owl
> 16. 
> ./taverna-scufl2-wfdesc/src/main/resources/org/purl/wf4ever/wfdesc/wfdesc.ttl
> 17. 
> ./taverna-scufl2-wfdesc/src/main/resources/org/purl/wf4ever/wfdesc/wfprov.ttl
> 18. 
> ./taverna-scufl2-wfdesc/src/main/resources/org/purl/wf4ever/wfdesc/roterms.ttl
> 19. 
> ./taverna-scufl2-wfdesc/src/main/resources/org/purl/wf4ever/wfdesc/wf4ever.ttl
> 20 
> ./taverna-scufl2-schemas/src/main/resources/org/apache/taverna/scufl2/rdfxml/xsd/roevo.xsd
>
> ---------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Update on Apache Toree and LGPL dependency

[Stian Soiland-Reyes]

I know software licensing can be a difficult thing to investigate, not
to mention change!

So very well done for managing to influence another open source
project!  Apache projects don't live in isolation, and participating
in the wider community is also an important aspect of open
development.

I guess this might also be a good opportunity to promote Apache Toree
within 0MQ community :)


On 3 March 2016 at 14:58, Gino Bustelo <g...@bustelos.com> wrote:
> Wanted to give folks an update on our progress with dealing with JeroMQ, an
> LGPL package that enables us to communicate via 0MQ. The 0MQ community is
> very aware of the issues with LGPL (LGPLv3 + static link exception) and it
> is their intention to try to move projects to MPL v2. This is not an easy
> task depending on the age and size of the projects.
>
> Apache Toree's API access point is through the 0MQ transport layer (using
> JeroMQ) and that is how Apache Toree connects out-of-the-box with Jupyter,
> a very common way of consuming Apache Toree that is already in production.
>
> At this point, the JeroMQ project is still released under LGPL, but our
> team initiated communications in mid-February with members of the JeroMQ
> community to begin their transition to MPL v2 (
> https://github.com/zeromq/jeromq/issues/326). The JeroMQ community reacted
> very positively and quickly began the process of collecting votes from
> their committers (https://github.com/zeromq/jeromq/issues/327). After 15
> days, the current tally stands at 26 out of 32 committers have agreed to
> switch license.
>
> Apache Toree has a JIRA (https://issues.apache.org/jira/browse/TOREE-262)
> where we keep all the relevant links and update with the latest
> information. As that process is underway, we will move forward with plans
> to release a 0.1.0 version of Apache Toree based on the precedence set by
> Apache Mynewt (
> http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E
> ).
>
> Thanks,
> Gino



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Fwd: [VOTE] Release taverna-language-0.15.1-incubating-RC5 and taverna-osgi-0.2.1-incubating-RC5

[Stian Soiland-Reyes]

I am pleased to be calling this vote for the source release of

  Apache Taverna Maven Parent 2-incubating
  Apache Taverna Language 0.15.1-incubating
  Apache Taverna OSGi plugin system 0.2.1-incubating

The Apache Taverna IPMC has voted in favour of this release with 5 IPMC votes:

http://markmail.org/message/346xxkywuexw6z52
http://mail-archives.apache.org/mod_mbox/taverna-dev/201603.mbox/<cambjemvv0asztfxwkulqpood1-cfwfydpf320fq_rzgkcuj...@mail.gmail.com>

We now ask for the Incubator PMC to vote on this release candidate.


Apache Taverna Language is a set of APIs for workflow definitions
(SCUFL2) and workflow inputs/outputs/run (DataBundle), as consumed and
produced by the Apache Taverna workflow system. The API includes
support for working with Research Object Bundles, and loading/saving
Taverna workflows in different formats.

Apache Taverna OSGi is a plugin system for OSGi with support for
online updates, which can be used by Java desktop and command line
applications.


The release candidates to be voted over are available at:

  
https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna-parent-2-incubating-RC5/
  
https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna-language-0.15.1-incubating-RC5/
  
https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna-osgi-0.2.1-incubating-RC5/


Checksums:

md5sum:
8e7ee332896d314877af481b348dbf51
apache-taverna-parent-2-incubating-source-release.zip

6bd8ae9e2b1bc2e675e5573b87feaa2a
apache-taverna-language-0.15.1-incubating-source-release.zip

4d595212a813f62a0c16a31d3a872af4
apache-taverna-osgi-0.2.1-incubating-source-release.zip


sha1sum:
d4b675763eb03bc5a9863db27779d725e1209af6
apache-taverna-parent-2-incubating-source-release.zip

af3a14ec6d9386e9aa97309275f7b147be6f0a38
apache-taverna-language-0.15.1-incubating-source-release.zip

2e91b5176322c0e029e1a856f0752159b1564158
apache-taverna-osgi-0.2.1-incubating-source-release.zip


sha512sum:
d5787ba7066d0d3b7c3b292434eb3de909c8ebaf43f0a3ea5e9dd25f0f19b5c1b7d508ffde97c0e6afd53265835d1aa4f22bb3187011b50b7f5aac99892bd0aa
apache-taverna-parent-2-incubating-source-release.zip

7cb4860abb4c57b91e81703a0d362d2824f10f1d2abe62c3df028fdca4f3ce33c4fe572c3349e629c8d409a7b25f3c86b79487d840c642a4b39e84432aa86c04
apache-taverna-language-0.15.1-incubating-source-release.zip

31b50a87243a01f3a5a657643d0f3b7f56d86fcc309df74392df3915ef8a787948ff8c74bc6a7684e6f9049b6430324373c50959ff658803dbc2d67d8a3dc45c
apache-taverna-osgi-0.2.1-incubating-source-release.zip



To build the release candidates you need Apache Maven 3 and Java 8.


Build the release candidate, in the above order, using:

mvn clean install


The release candidates correspond to the following git commits:

  
https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-maven-parent.git;a=commit;h=d34dd67fcfa11caead08008d37279b1ea546e3ec

  
https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-language.git;a=commit;h=66866a5454ed23262c055f65155d7a195c68a17d

  
https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-osgi.git;a=commit;h=0b7da331e81febade5ce2f4cf1f068013002b7aa


Release candidates are signed with a GPG key available at:

  https://dist.apache.org/repos/dist/release/incubator/taverna/KEYS

A staged Maven repository is available for review at:

  https://repository.apache.org/content/repositories/orgapachetaverna-1011/

The changelog for this release is available from JIRA:

  
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12333249=12318322
  
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12333250=12318322
  
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12332248=12318322


Please vote on releasing these packages as:

  Apache Taverna Maven Parent 2-incubating
  Apache Taverna Language 0.15.1-incubating
  Apache Taverna OSGi plugin system 0.2.1-incubating


The vote is open for at least 72 hours
(let's say Monday 2016-03-07 17:00 GMT)
and passes if a majority of at least
three +1 Incubator PMC votes are cast.

[ ] +1 Release this package
[ ]  0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because...

Anyone can participate in testing and voting, not just Incubator PMC
members, please feel free to try out the release candidate and provide
your votes.


--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

RE: Copyright sign offs

[Stian Soiland-Reyes]

There are two checklist items:

Is the software grant received and cover the (majority?) of the code? (In
which case those files should get the ASF header). This was presumably done
a while ago, so just find the date from email  archives to private@odfdom
when the ASF secretary confirmed

The second point is about any third-party source code in the repository
which was NOT covered by that grant. For odfdom one example is the OASIS
schema files. This can be signed off when they have been checked to be OK
and accounted for (ideally in LICENCE/NOTICE files, but at least in their
headers.)

BTW, the OASIS files are against ASF policy as they have a no-modifications
clause: https://issues.apache.org/jira/browse/ODFTOOLKIT-419
-- but technically they are "legal to distribute" as you have not modified
them. Thus you can backdate the second item as well to when this was
checked.
On 1 Mar 2016 06:06, "Dennis E. Hamilton"  wrote:

> > -Original Message-
> > From: Henri Yandell [mailto:bay...@apache.org]
> > Sent: Monday, February 29, 2016 18:43
> > To: general@incubator.apache.org
> > Cc: Dennis Hamilton 
> > Subject: Re: Copyright sign offs
> >
> > Is 'it was already under Apache 2.0' typically taken to cover:
> >
> >   "Check and make sure that the papers that transfer rights to the ASF
> > been
> > received. It is only necessary to transfer rights for the package, the
> > core
> > code, and any new code produced by the project."
> >
> > ?
> [orcmid]
>
> No, I don't take it to cover that.  I think it is more like speaking of
> third-party code that bears ALv2 license notices already.
>
> [Also "rights" and "transfer" are rather vague and potentially
> over-broad.  I have no interest in haggling about that.  All I am
> suggesting is that the original files do not appear to be transposed to
> having the form of notice preferred by the ASF.  Having not been on the
> PPMC, I have no idea what grants were received in any form.]
>
> >
> > Hen
> >
> >
> >
> > On Mon, Feb 29, 2016 at 4:17 PM, John D. Ament 
> > wrote:
> >
> > > Dennis,
> > >
> > > For some reason, Oliver Rau added you in this commit
> > >
> > >
> > https://svn.apache.org/viewvc/incubator/public/trunk/content/projects/od
> > ftoolkit.xml?r1=1296007=1531246
> > > If you don't belong, you should be able to remove yourself.
> > >
> > > John
> > >
> > > On Mon, Feb 29, 2016 at 6:30 PM Dennis E. Hamilton <
> > > dennis.hamil...@acm.org>
> > > wrote:
> > >
> > > > Henri,
> > > >
> > > > I did a quick look at the odftoolkit repository and the podling
> > page.
> > > >
> > > > The odftoolkit project was originally under ALv2.  The code still
> > carries
> > > > Copyright notices on the individual files and the ALv2 license
> > statement
> > > > has not been updated/replaced by the current one mentioning
> > contribution
> > > to
> > > > the ASF, etc.
> > > >
> > > > In passing, I notice a peculiarity of the incubator page,
> > > > .  I'm certain
> > I
> > > > was never on the PPMC and I don't think I was a committer either,
> > unless
> > > it
> > > > is transitive via incubator (a change since 2012?).  My impression
> > was
> > > that
> > > > the PPMC was rather small.  I have no idea what its current
> > membership
> > > is.
> > > >
> > > > There has been recent maintenance on the source code, some working
> > > against
> > > > JIRA issues, as reported in the February 2016 Incubator Report.
> > > >
> > > >  - Dennis
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Henri Yandell [mailto:bay...@apache.org]
> > > > > Sent: Friday, February 26, 2016 17:28
> > > > > To: general@incubator.apache.org
> > > > > Subject: Copyright sign offs
> > > > >
> > > > > Haven't done this in a while :)
> > > > >
> > > > > Thought I'd share that the following podlings have not yet signed
> > off
> > > on
> > > > > their Copyright sections in their status reports. I mention this
> > > because
> > > > > I
> > > > > believe it's one of the first elements that should be signed off
> > on the
> > > > > status report and it's a worry if projects have not done so:
> > > > >
> > > > >   cmda
> > > > >   datafu
> > > > >   horn
> > > > >   johnzon
> > > > >   odftoolkit
> > > > [ ... ]
> > > > >
> > > > > I'd be interested to hear about any reasons why the above aren't
> > able
> > > to
> > > > > sign that element of their status file off.
> > > > [ ... ]
> > > >
> > > >
> > > > 
> > -
> > > > 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: New mentors for Taverna?

[Stian Soiland-Reyes]

Thank you for your interest, Dan!

Your long experience with Derby and ASF, not to mention the very
relevant Quarks incubator proposal. would be very welcome by the
Taverna incubator!

I believe that as an ASF Member you just need to self-nominate to
become a member of the Incubator PMC, and thus can become a mentor.
The IPMC folks can help you with the karma granting so you can join
the incubator SVN group - after which you can add yourself to
https://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/taverna.xml

IPMC folks - is this roughly right?




On 24 February 2016 at 16:56, ddebrunner <ddebrun...@sbcglobal.net> wrote:
> I might be able to be a mentor, let me check and confirm tomorrow if you 
> still need mentors by then.
>
> Dan.
>
>
> Sent from my T-Mobile 4G LTE Device
>
>  Original message From: Ian Dunlop 
> <ian.dun...@manchester.ac.uk> Date:2016/02/23  07:59  (GMT-08:00) 
> To: general@incubator.apache.org Cc:  
> Subject: Re: New mentors for Taverna? 
> Hello,
>
> It's an exciting phase for Apache Taverna. We are pushing out a new
> release and it is a great time for new mentors to get involved. We are a
> very friendly community. With the new Apache Beam proposal getting
> started and the Apache Taverna integration points with the Common
> Workflow Language initiative it's a great time to move into the workflow
> space.
>
> Cheers,
>
> Ian
>
> On 15/02/2016 08:13, Stian Soiland-Reyes wrote:
>> No, we are still hoping for a new mentor..
>> On 14 Feb 2016 17:13, "John D. Ament" <johndam...@apache.org> wrote:
>>
>>> Just wondering, has anyone stepped up to help Taverna?
>>>
>>> John
>>>
>>> On Sat, Feb 6, 2016 at 6:56 AM Andy Seaborne <a...@apache.org> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm one of the "semi-active mentors" of Taverna. In my case, I have a
>>>> new $job, which is related to some Apache communities but not Taverna.
>>>> A new job is a busy time so I'm really not able to properly support the
>>>> podling at the moment.  I wish I could but I also have to be realistic.
>>>>
>>>> Taverna is (I believe) in good shape. Having done an incubator release
>>>> of part of the codebase, they understand and take the IP issues
>>>> seriously.  They have added a person to the PPMC.  All-in-all, good
>>>> progress towards graduation and getting more of the codebase out is the
>>>> next step.
>>>>
>>>> So - please could Taverna have some additional mentors?
>>>>
>>>>  Andy
>>>>
>>>> On 01/02/16 14:36, Stian Soiland-Reyes wrote:
>>>>> The majority of the mentors of the Taverna podling have raised
>>>>> concerns that they no longer have sufficient time available to help
>>>>> Taverna in the incubator.
>>>>>
>>>>> In effect we will then have 2 semi-active mentors remaining for
>>>> continuity.
>>>>>
>>>>> This has become a concern because Taverna is picking up speed and
>>>>> moving towards releases of the main code base (our first release was
>>>>> for a more self-contained library), and this means some effort is
>>>>> needed to review and guide us through those releases.
>>>>>
>>>>> We in the Taverna PPMC have already learnt a lot about the Apache Way,
>>>>> we have done our first release, we had 3 very successful GSOC
>>>>> students, and we have voted in our first new PPMC member.
>>>>>
>>>>> However knowing the effort needed to review a "new" code base for a
>>>>> release, we think it would not be fair on the remaining 2 mentors to
>>>>> take the full burden of responsibility.
>>>>>
>>>>>
>>>>> Therefore we would like to ask the Incubator PMC if anyone would be
>>>>> interested in becoming an active mentor of Taverna as we enter this
>>>>> exciting phase?
>>>>>
>>>>>
>>>>>
>>>>> About Taverna:
>>>>>
>>>>> http://taverna.incubator.apache.org/
>>>>>
>>>>> Taverna is a domain-independent suite of tools used to design and
>>>>> execute data-driven workflows, which invoke a mixture of local and
>>>>> remote (REST, WSDL) services. Taverna is used by scientists and
>>>>> researchers in domains like bioinformatics, chemistry, m

Re: FW: [DISCUSSION] How to deal with runtime dependencies

[Stian Soiland-Reyes]

Both JDBC drivers and JPA implementations are pluggable by design.

With "huge effort" I guess you mean changing configuration files, setup and
deployment methods, rather than code changes?

If your code could still work using alternatives to Hibernate and MySQL
connector (e.g. Apache Derby and Apache OpenJPA) and you are not replying
on implementation-specific extensions, queries/stored procedures, then I
don't see a problem with using them in integration tests.

You should have a goal towards graduation to not have to rely on them by
default (e.g. switch to Derby and , but keeping the integration tests
("check it also works with Hibernate and MySQL) makes perfect sense.
Downstream consumers don't have to run (all) your integration tests.

It's OK if you don't get the most brilliant performance with the ASF
compatible libraries (that's outside your control!), as long as you don't
say "Apache Foo recommends configuring db as  MySQL and Hibernate for best
performance" - but rather document it like "Some users report improved
performance configuring db as MySQL and Hibernate"

One issue is with binary convenience distributions. If you are planning any
(or likely to do so), then you can't include Hibernate or MySQL (e.g. in
the archived lib/ folder) - at least not in binaries distributed from (or
promoted by) Apache.

Downstream consumers of AFS software also should not get licensing
surprises - so your runtime script can't simply do "Downloading Hibernate"
at first startup. Say a "Connect to database wizard" with MySQL as one of
the options (that then does download), should however be legit, as long as
ASF compatible options are available.


On 10 Feb 2016 08:56, "Markus Geiß"  wrote:

> Hey all,
>
> We've started a thread at our dev list and forgot to send it to the
> general incubator list too.
> Any opinion is appreciated, you can find the original message below.
>
> Best,
>
> Markus
>
> .::YAGNI likes a DRY KISS::.
>
> > From: markus.ge...@live.de
> > To: d...@fineract.incubator.apache.org
> > Subject: [DISCUSSION] How to deal with runtime dependencies
> > Date: Mon, 8 Feb 2016 14:12:04 +0100
> >
> > Hey all,
> >
> > hope this finds you well.
> >
> > I thought instead of discussing this on top of pull request, because it
> is more
> > than just the JDBC driver, it is the right time to create a new thread.
> >
> > We are currently using MySQL's Connector/J and Hibernate's EntityManager
> at
> > runtime as the JDBC driver and JPA implementation. Our source code is not
> > depending on both.
> >
> > It would create a huge effort to replace both for test and production
> environments.
> >
> > The questions is:
> >
> > Would it be compliant with the license policies if we omit them for our
> source
> > release, but keeping them for our own integration tests.
> >
> > If somebody is creating a deployable distribution, the expectation is
> that whomever
> > is creating the distribution can decide what he wants to use.
> >
> > Best,
> >
> > Markus
> >
> > .::YAGNI likes a DRY KISS::.
>

Re: New mentors for Taverna?

[Stian Soiland-Reyes]

No, we are still hoping for a new mentor..
On 14 Feb 2016 17:13, "John D. Ament" <johndam...@apache.org> wrote:

> Just wondering, has anyone stepped up to help Taverna?
>
> John
>
> On Sat, Feb 6, 2016 at 6:56 AM Andy Seaborne <a...@apache.org> wrote:
>
> > Hi all,
> >
> > I'm one of the "semi-active mentors" of Taverna. In my case, I have a
> > new $job, which is related to some Apache communities but not Taverna.
> > A new job is a busy time so I'm really not able to properly support the
> > podling at the moment.  I wish I could but I also have to be realistic.
> >
> > Taverna is (I believe) in good shape. Having done an incubator release
> > of part of the codebase, they understand and take the IP issues
> > seriously.  They have added a person to the PPMC.  All-in-all, good
> > progress towards graduation and getting more of the codebase out is the
> > next step.
> >
> > So - please could Taverna have some additional mentors?
> >
> >  Andy
> >
> > On 01/02/16 14:36, Stian Soiland-Reyes wrote:
> > > The majority of the mentors of the Taverna podling have raised
> > > concerns that they no longer have sufficient time available to help
> > > Taverna in the incubator.
> > >
> > > In effect we will then have 2 semi-active mentors remaining for
> > continuity.
> > >
> > > This has become a concern because Taverna is picking up speed and
> > > moving towards releases of the main code base (our first release was
> > > for a more self-contained library), and this means some effort is
> > > needed to review and guide us through those releases.
> > >
> > > We in the Taverna PPMC have already learnt a lot about the Apache Way,
> > > we have done our first release, we had 3 very successful GSOC
> > > students, and we have voted in our first new PPMC member.
> > >
> > > However knowing the effort needed to review a "new" code base for a
> > > release, we think it would not be fair on the remaining 2 mentors to
> > > take the full burden of responsibility.
> > >
> > >
> > > Therefore we would like to ask the Incubator PMC if anyone would be
> > > interested in becoming an active mentor of Taverna as we enter this
> > > exciting phase?
> > >
> > >
> > >
> > > About Taverna:
> > >
> > > http://taverna.incubator.apache.org/
> > >
> > > Taverna is a domain-independent suite of tools used to design and
> > > execute data-driven workflows, which invoke a mixture of local and
> > > remote (REST, WSDL) services. Taverna is used by scientists and
> > > researchers in domains like bioinformatics, chemistry, musicology,
> > > biodiversity and virtual physiology to combine and process data from
> > > multiple sources using a wide variety of analytical tools.
> > >
> > > Taverna workflows can be designed in a graphical workbench,
> > > programmatically through the Taverna Language API, or using an
> > > RDF/JSON-based workflow format. They can be executed locally (command
> > > line, within workbench or through OSGi-based APIs), or on a Taverna
> > > server (REST/WSDL), which has been integrated by portals and
> > > frontends, including an Android mobile app. Taverna results include
> > > full provenance trace of the execution as we strive to support
> > > reproducible computational research.
> > >
> > > This is an exciting time for us, as we are not just releasing version
> > > 3 of Taverna, but also working on a Common Workflow Language
> > > integration (YaML), including support for coordinating Docker-based
> > > command line tools.
> > >
> > > We rely on a large selection of Apache tools, like Woden, Felix, Jena,
> > > Derby, Tika, Velocity, Commons, HTTP Client and Maven.
> > >
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

New mentors for Taverna?

[Stian Soiland-Reyes]

The majority of the mentors of the Taverna podling have raised
concerns that they no longer have sufficient time available to help
Taverna in the incubator.

In effect we will then have 2 semi-active mentors remaining for continuity.

This has become a concern because Taverna is picking up speed and
moving towards releases of the main code base (our first release was
for a more self-contained library), and this means some effort is
needed to review and guide us through those releases.

We in the Taverna PPMC have already learnt a lot about the Apache Way,
we have done our first release, we had 3 very successful GSOC
students, and we have voted in our first new PPMC member.

However knowing the effort needed to review a "new" code base for a
release, we think it would not be fair on the remaining 2 mentors to
take the full burden of responsibility.


Therefore we would like to ask the Incubator PMC if anyone would be
interested in becoming an active mentor of Taverna as we enter this
exciting phase?



About Taverna:

http://taverna.incubator.apache.org/

Taverna is a domain-independent suite of tools used to design and
execute data-driven workflows, which invoke a mixture of local and
remote (REST, WSDL) services. Taverna is used by scientists and
researchers in domains like bioinformatics, chemistry, musicology,
biodiversity and virtual physiology to combine and process data from
multiple sources using a wide variety of analytical tools.

Taverna workflows can be designed in a graphical workbench,
programmatically through the Taverna Language API, or using an
RDF/JSON-based workflow format. They can be executed locally (command
line, within workbench or through OSGi-based APIs), or on a Taverna
server (REST/WSDL), which has been integrated by portals and
frontends, including an Android mobile app. Taverna results include
full provenance trace of the execution as we strive to support
reproducible computational research.

This is an exciting time for us, as we are not just releasing version
3 of Taverna, but also working on a Common Workflow Language
integration (YaML), including support for coordinating Docker-based
command line tools.

We rely on a large selection of Apache tools, like Woden, Felix, Jena,
Derby, Tika, Velocity, Commons, HTTP Client and Maven.


-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Apache Dataflow Incubator Proposal

[Stian Soiland-Reyes]

As a committer of another "dataflow" incubator Taverna, I think this
looks like an exciting proposal.


Agree on the confusion of the name, and it's probably better to get
that sorted early.

In Taverna we have used the term "dataflow" since 2004, and as a
concept the paradigm was created in the 1960s. So Dataflow is a bit
too broad and likely not trademarkable. Your model seems more of an
Event-driven workflow, as you explain in the paper.


You can do a renaming during the very first month of incubation (which
several indubator projects have done) - it's a simple way to engage
everyone in the newly formed/refreshed incubator community, who should
then feel ownership to the name decission, rather than let selected
few decide beforehand.

In your case you do not already have a single community mailing list
(?), so perhaps it would be harder to do this kind of community
decission as a GitHub issue?

Remember the later you rename, the more you have to rename, like
mailing list address, code repositories, package names, documentation,
website.. :)

On 20 January 2016 at 17:12, Marvin Humphrey <mar...@rectangular.com> wrote:
> On Wed, Jan 20, 2016 at 8:32 AM, James Malone
> <jamesmal...@google.com.invalid> wrote:
>
>> == Abstract ==
>>
>> Dataflow is an open source, unified model and set of language-specific SDKs
>> for defining and executing data processing workflows, and also data
>> ingestion and integration flows, supporting Enterprise Integration Patterns
>> (EIPs) and Domain Specific Languages (DSLs). Dataflow pipelines simplify
>> the mechanics of large-scale batch and streaming data processing and can
>> run on a number of runtimes like Apache Flink, Apache Spark, and Google
>> Cloud Dataflow (a cloud service). Dataflow also brings DSL in different
>> languages, allowing users to easily implement their data integration
>> processes.
>
> In general this seems like an excellent project and a well-thought-through and
> viable proposal -- I certainly anticipate that it will be accepted for
> incubation in one form or another.
>
> However, how does this "Dataflow" project relate to the programming paradigm
> of "dataflow programming"?
>
> https://en.wikipedia.org/wiki/Dataflow_programming
>
> Besides the potential for confusion, it seems like the proposed project name
> would be tough to defend as a trademark.
>
>> With respect to trademark rights, Google does not hold a trademark on the
>> phrase “Dataflow.” Based on feedback and guidance we receive during the
>> incubation process, we are open to renaming the project if necessary for
>> trademark or other concerns.
>
> If a renaming is going to happen, there are advantages to renaming sooner
> rather than later and sparing the community additional disruption.
>
> Marvin Humphrey
>
> ---------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache package naming convention

[Stian Soiland-Reyes]

-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Report for April mostly done

[Stian Soiland-Reyes]

I added to the summary that:

  CommonsRDF SGA filed 2015-03-27


On 5 April 2015 at 04:43, Marvin Humphrey mar...@rectangular.com wrote:
 Greets,

 Since this is Ted's first month as IPMC Chair, I promised lots of
 help and deadlines are coming up, I've gone ahead and completed most
 of the general section of the report.

 Ted, feel free to look things over and edit as you see fit.  Come
 Monday, I'll send out the draft report to this list.  What will remain
 after that is for you to file the report with the Board on Wednesday.

 Next month, we should have you use the report_runbook.py script and
 collaborate more closely.

 Marvin Humphrey

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Ignite (Incubating) 1.0

[Stian Soiland-Reyes]

I change my vote to +1 (non-binding), fixing for next release is good
enough for me. :-)

Perhaps worth also checking that maven plugin (assembly?) and report
upstream - simply picking last license is a bit fragile.
On 31 Mar 2015 22:54, Dmitriy Setrakyan dsetrak...@apache.org wrote:

 On Tue, Mar 31, 2015 at 2:22 PM, Stian Soiland-Reyes st...@apache.org
 wrote:

   ?
  My apologies for not looking up how to actually use Ignite :)
 
 
  The build still requires the edtFTPj dependency to compile, even
  without -Plgpl - using urideploy through Maven would always pull in
  the edtFTPj dependency.
 
  It is also in the zip:
inflating:
  ignite-fabric-1.0.0/libs/optional/ignite-urideploy/edtFTPj-1.5.3.jar
 

 Apologies, I confused it with cron4j, which is part of LGPL-based optional
 schedule module and is not included.


 
 
  I see it says a different license there
 
 
 
 ignite-fabric-1.0.0/libs/optional/ignite-urideploy/licenses/edtftp-license.pdf
  (from http://www.enterprisedt.com/products/edtftpj/doc/license.pdf )
 
  which is Subject to payment of the Source License fee: and have
  several requirements for notices (which may or may not be satisfied by
  you including that PDF :) )
 
 
  This is a bit unclear to me.. have you paid that fee? Do I need to pay
  that fee to use urideploy? Can I give this compiled
  ignite-fabric-1.0.0.zip to a customer, or would they also need to pay
  a fee?
 

 You are absolutely right. I actually completely forgot about this one.
 Looks like the license provided is wrong, and we have a license bug. The
 actual license is LGPLv2. You can clearly see it from here:
 https://enterprisedt.com/products/edtftpj/

 Currently, we are not excluding it from the release binary by mistake and
 can fix it in the next release. However, we do not include any edtFTPj
 source code into Apache Ignite, so the source code of Apache Ignite is LGPL
 free. During the build, it ends up in the libs/optional folder and is not
 turned on, unless explicitly moved to the libs folder.

 We will definitely address it in the next release. Ticket has been filed:
 https://issues.apache.org/jira/browse/IGNITE-660



 
  I guess this comes from
 
 
 http://central.maven.org/maven2/com/enterprisedt/edtFTPj/1.5.3/edtFTPj-1.5.3.pom
  and some  Maven plugin just picking the last license ?
 
 
  On 31 March 2015 at 16:43, Dmitriy Setrakyan dsetrak...@apache.org
  wrote:
   On Tue, Mar 31, 2015 at 8:35 AM, Stian Soiland-Reyes st...@apache.org
 
   wrote:
  
   That thread does not mention edtFTPj or the test dependencies.
  
   http://enterprisedt.com/products/edtftpj/
  
  
   but if edtFTPj is optional, why is it then not marked as such in the
   modules/urideploy/pom.xml?
  
   If I comment out edtFTPj, then I get lots of compiler errors.
  
  
   Stian, edtFTPj is also optional (sorry, forgot to mention). I am not
 sure
   what you mean by commenting it, but the maven build does not include it
   into the release with default settings, no need to change anything.
  
   - Execute mvn clean package -DskipTests with JDK 7
   - Go into target folder and unzip ignite-fabric-1.0.0.zip file
   - You will notice that there is not a single LGPL dependency there.
  
   If users would like to explicitly include LGPL dependencies into their
  own
   build, then they should build the project with the following command:
  
   mvn clean package -DskipTests -Prelease,lgpl
  
   These instructions are also listed in the DEVNOTES.txt.
  
   Hope this clarifies things.
  
   D.
  
  
  
   modules/urideploy is depended on by modules/spring which is depended
   on by lots of other modules, it does not look optional to me.
  
   On 31 March 2015 at 16:26, Marvin Humphrey mar...@rectangular.com
  wrote:
On Tue, Mar 31, 2015 at 8:16 AM, Stian Soiland-Reyes 
  st...@apache.org
   wrote:
-0 because of required LGPL dependencies.
   
I think we established that these were optional and thus allowed
  during
the last release:
   
http://s.apache.org/vfN
   
As far as LGPL, to my knowledge, Ignite only has 2 optional LGPL
dependencies which are for the optional integration with the
   following
products:
   
- Hibernate ORM, http://hibernate.org/orm/
- JTS Topology Suite from VividSolutions for geospatial
 indexing,
http://www.vividsolutions.com/jts/JTSHome.htm
   
Marvin Humphrey
   
   
 -
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
   
  
  
  
   --
   Stian Soiland-Reyes
   Apache Taverna (incubating), Apache Commons RDF (incubating)
   http://orcid.org/-0001-9842-9718
  
   -
   To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
   For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Ignite (Incubating) 1.0

[Stian Soiland-Reyes]

That thread does not mention edtFTPj or the test dependencies.

http://enterprisedt.com/products/edtftpj/


but if edtFTPj is optional, why is it then not marked as such in the
modules/urideploy/pom.xml?

If I comment out edtFTPj, then I get lots of compiler errors.


modules/urideploy is depended on by modules/spring which is depended
on by lots of other modules, it does not look optional to me.

On 31 March 2015 at 16:26, Marvin Humphrey mar...@rectangular.com wrote:
 On Tue, Mar 31, 2015 at 8:16 AM, Stian Soiland-Reyes st...@apache.org wrote:
 -0 because of required LGPL dependencies.

 I think we established that these were optional and thus allowed during
 the last release:

 http://s.apache.org/vfN

 As far as LGPL, to my knowledge, Ignite only has 2 optional LGPL
 dependencies which are for the optional integration with the following
 products:

 - Hibernate ORM, http://hibernate.org/orm/
 - JTS Topology Suite from VividSolutions for geospatial indexing,
 http://www.vividsolutions.com/jts/JTSHome.htm

 Marvin Humphrey

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Ignite (Incubating) 1.0

[Stian Soiland-Reyes]

sorry, my send button was trigger happy..

+0 - due to build errors (see below)

Verified:

1) GPG signature matches BD656948 from KEYS
2) MD5/SHA1 signatures
3) No binaries (except PNGs, test  SSL certificates, PDF)
4) DISCLAIMER, LICENSE and NOTICE
5) rat plugin happy (mvn clean validate -Pcheck-licenses)

but:

6) FAILS mvn clean package -DskipTests   (as DEVNOTES.txt says I
should run) -- see below
7) Which git tag is this?
https://github.com/apache/incubator-ignite/releases has a lot of RCs..
I will assume 'ignite-1.0.0' aka
5fc2cd053467e65872f796e11e3edd2e6017d80d aka
https://git-wip-us.apache.org/repos/asf?p=incubator-ignite.git;a=commit;h=5fc2cd053467e65872f796e11e3edd2e6017d80d
-- which matches 100% with the src.zip.

8) It would be good to avoid all those RC RCs as it's confusing to
have multiple levels of release candidates - in Apache, a Release
Candidate is this particular thing you are asking us to vote over.
(this might have been pointed out earlier). A pre-release can be
called anything else, like alpha, golden master, etc.
https://www.apache.org/dev/release.html#what


https://repository.apache.org/content/repositories/releases/org/apache/ignite/ignite-core/
http://archive.apache.org/dist/incubator/ignite/
contains 1.0.0-RC1/ and 1.0.0-RC3/ -- are these released release
candidates? Well, done is done, I guess :)


8) Which of these many open staging Maven repositories is it you are
planning to release? Although the voting thread is strictly over
source release - it would be nice to know (I think those also should
be subject to some checks), and drop the the others.
https://repository.apache.org/content/repositories/

9) Due to the build errors I have not checked the dependency licenses,
mvn license:aggregate-add-third-party fails with the above error as
well.


Build error:

[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR] 
/tmp/92/people.apache.org/~dsetrakyan/incubator-ignite-1.0.0/incubator-ignite-1.0.0-src/modules/schema-import/src/main/java/org/apache/ignite/schema/ui/ModalDialog.java:[20,1]
package javafx.stage does not exist
[ERROR] 
/tmp/92/people.apache.org/~dsetrakyan/incubator-ignite-1.0.0/incubator-ignite-1.0.0-src/modules/schema-import/src/main/java/org/apache/ignite/schema/ui/ModalDialog.java:[25,43]
cannot find symbol
  symbol: class Stage
[ERROR] 
/tmp/92/people.apache.org/~dsetrakyan/incubator-ignite-1.0.0/incubator-ignite-1.0.0-src/modules/schema-import/src/main/java/org/apache/ignite/schema/ui/ModalDialog.java:[27,21]
cannot find symbol
  symbol:   class Stage
  location: class org.apache.ignite.schema.ui.ModalDialog
[ERROR] 
/tmp/92/people.apache.org/~dsetrakyan/incubator-ignite-1.0.0/incubator-ignite-1.0.0-src/modules/schema-import/src/main/java/org/apache/ignite/schema/ui/ModalDialog.java:[34,27]
cannot find symbol
  symbol:   class Stage
  location: class org.apache.ignite.schema.ui.ModalDialog


DEVNOTES.txt does not mention anything special about this. Is this
related to javafx?


Tested with Maven 3.3.1 on Open JDK 8 on Ubuntu 14.10/x64

stain@biggie-utopic:/tmp/92/people.apache.org/~dsetrakyan/incubator-ignite-1.0.0/incubator-ignite-1.0.0-src$
mvn -version
Apache Maven 3.3.1 (cab6659f9874fa96462afef40fcf6bc033d58c1c;
2015-03-13T20:10:27+00:00)
Maven home: /home/stain/software/maven
Java version: 1.8.0_40-internal, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: linux, version: 3.16.0-33-generic, arch: amd64, family: unix


If I try again with Open JDK 7 instead I get:

[ERROR] Failed to execute goal on project ignite-schema-import: Could
not resolve dependencies for project
org.apache.ignite:ignite-schema-import:jar:1.0.0: The following
artifacts could not be resolved:
org.apache.ignite:ignite-core:jar:1.0.0, javafx:jfxrt:jar:1.7.0_75:
Failure to find org.apache.ignite:ignite-core:jar:1.0.0 in
https://repo.maven.apache.org/maven2 was cached in the local
repository, resolution will not be reattempted until the update
interval of central has elapsed or updates are forced - [Help 1]






On 31 March 2015 at 14:27, Stian Soiland-Reyes st...@apache.org wrote:
 You did not include the hashes, so I will assume:

 stain@biggie-utopic:/tmp/92/people.apache.org/~dsetrakyan/incubator-ignite-1.0.0$
 cat *md5 *sha1
 401e8407bb262aacb1600bb188f9  incubator-ignite-1.0.0-src.zip
 a8f643ffdc5b45101cf5a9ad5f19b9fce5a4099f  incubator-ignite-1.0.0-src.zip


 I would have expected KEYS to be in the version-independent folder, e.g.

 https://dist.apache.org/repos/dist/release/incubator/ignite/KEYS


 I would have expected the release candidate to have been uploaded to
 ignite/ under
 https://dist.apache.org/repos/dist/dev/incubator/
 rather than at people.apache.org
 (and then just do a svn move of the version folder after approval -
 which pretty much guarantees that it's the correct files that were
 voted over).


 Verified:

 1) GPG

Re: [VOTE] Release Apache Ignite (Incubating) 1.0

[Stian Soiland-Reyes]

-0 because of required LGPL dependencies.

(As much as I would prefer LGPL dependencies to be allowed, they are not:
https://www.apache.org/legal/resolved.html )


They are not technically *included* - so legally I think it is
passable for this release, as long as you only distribute this source
release - but it's still not good to have required runtime
dependencies on LGPL as it means anyone distributing binaries of
Apache Ignite will fall under the LGPL license requirements for
Combined Work.

You might want to be careful about putting the binary of
modules/urideploy in Maven - have you checked this with legal@apache?
(IANAL - others on this list might have many other views :) )


BUILD SUCCESS with Oracle JDK 7.

stain@biggie-utopic:/tmp/92/people.apache.org/~dsetrakyan/incubator-ignite-1.0.0/incubator-ignite-1.0.0-src$
mvn -version
Apache Maven 3.3.1 (cab6659f9874fa96462afef40fcf6bc033d58c1c;
2015-03-13T20:10:27+00:00)
Maven home: /home/stain/software/maven
Java version: 1.7.0_72, vendor: Oracle Corporation
Java home: /usr/lib/jvm/jdk1.7.0_72/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: linux, version: 3.16.0-33-generic, arch: amd64, family: unix


What is the license of javafx?




potentially dubious dependency licenses as reported by mvn
license:aggregate-add-third-party:

 (GNU LESSER GENERAL PUBLIC LICENSE) c3p0:JDBC
DataSources/Resource Pools (c3p0:c3p0:0.9.1 -
http://c3p0.sourceforge.net)

from modules/core
OK, only scopetest/scope



(GNU Lesser General Public License Version 2.1) IRMI
(org.ow2.carol.irmi:irmi:1.1.2 - no url defined)
 (GNU Lesser General Public License Version 2.1) Java EE: JTA API
v1.1 (org.ow2.spec.ee:ow2-jta-1.1-spec:1.0-M1 - no
url defined)

from ./modules/jta
OK as it is scopetest/scope via jotm-core



BUT:


 (LGPL) (Unrestricted) edtFTPj (com.enterprisedt:edtFTPj:1.5.3 -
http://www.enterprisedt.com/products/edtftpj/overview.html)

from modules/urideploy/pom.xml

This one is -1 I am afraid :-(

Perhaps move modules/urideploy to the -Plgpl profile and modify modules/spring?




On 31 March 2015 at 15:29, Dmitriy Setrakyan dsetrak...@apache.org wrote:
 On Tue, Mar 31, 2015 at 7:00 AM, Stian Soiland-Reyes st...@apache.org
 wrote:

 sorry, my send button was trigger happy..

 +0 - due to build errors (see below)


 Verified:

 1) GPG signature matches BD656948 from KEYS
 2) MD5/SHA1 signatures
 3) No binaries (except PNGs, test  SSL certificates, PDF)
 4) DISCLAIMER, LICENSE and NOTICE
 5) rat plugin happy (mvn clean validate -Pcheck-licenses)

 but:

 6) FAILS mvn clean package -DskipTests   (as DEVNOTES.txt says I
 should run) -- see below


 It should work with Oracle JDK 7, can you try? In the next release JDK will
 not matter, but for now we require Oracle Java 7.


 7) Which git tag is this?
 https://github.com/apache/incubator-ignite/releases has a lot of RCs..
 I will assume 'ignite-1.0.0' aka
 5fc2cd053467e65872f796e11e3edd2e6017d80d aka

 https://git-wip-us.apache.org/repos/asf?p=incubator-ignite.git;a=commit;h=5fc2cd053467e65872f796e11e3edd2e6017d80d
 -- which matches 100% with the src.zip.


 Correct.



 8) It would be good to avoid all those RC RCs as it's confusing to
 have multiple levels of release candidates - in Apache, a Release
 Candidate is this particular thing you are asking us to vote over.
 (this might have been pointed out earlier). A pre-release can be
 called anything else, like alpha, golden master, etc.
 https://www.apache.org/dev/release.html#what



 https://repository.apache.org/content/repositories/releases/org/apache/ignite/ignite-core/
 http://archive.apache.org/dist/incubator/ignite/
 contains 1.0.0-RC1/ and 1.0.0-RC3/ -- are these released release
 candidates? Well, done is done, I guess :)


 Agreed. Will not use RCs in the future.



 8) Which of these many open staging Maven repositories is it you are
 planning to release? Although the voting thread is strictly over
 source release - it would be nice to know (I think those also should
 be subject to some checks), and drop the the others.
 https://repository.apache.org/content/repositories/


 I think neither. The ones you see are just for testing and will be cleaned
 up.

 We are currently experiencing problems with Apache Maven when trying to
 deploy to the repository. I can send another link once the issue is
 resolved.




 9) Due to the build errors I have not checked the dependency licenses,
 mvn license:aggregate-add-third-party fails with the above error as
 well.


 Again, please rerun with Oracle JDK7.  Ideally, devnotes should say
 something about it (will mention this on the website).




 Build error:

 [ERROR] COMPILATION ERROR :
 [INFO] -
 [ERROR] /tmp/92/
 people.apache.org/~dsetrakyan/incubator-ignite-1.0.0/incubator-ignite-1.0.0-src/modules/schema-import/src/main/java/org/apache/ignite/schema/ui/ModalDialog.java:[20,1]
 package javafx.stage does not exist
 [ERROR] /tmp/92

Re: [VOTE] Release Apache Ignite (Incubating) 1.0

[Stian Soiland-Reyes]

Agree that release.html needs some polishing, and that there are no
hard rules on the versions (even don't re-release the same version
is not written down in letters).

Obviously it would still be confusing to vote over say RC2 of
1.0.0-RC3 and best avoided if possible.   This vote is luckily over
the proper 1.0.0 release - but I also spotted a 1.0.1-RC1 in the Maven
repositories.



On 31 March 2015 at 15:44, Branko Čibej br...@apache.org wrote:
 On 31.03.2015 16:00, Stian Soiland-Reyes wrote:
 8) It would be good to avoid all those RC RCs as it's confusing to
 have multiple levels of release candidates - in Apache, a Release
 Candidate is this particular thing you are asking us to vote over.
 (this might have been pointed out earlier). A pre-release can be
 called anything else, like alpha, golden master, etc.
 https://www.apache.org/dev/release.html#what

 We've been through this and I disagree. Do not confuse release process
 with release naming. That page conflates the two, which makes it just a
 bit broken IMO. There are no rules for release naming in Apache.

 -- Brane


 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Ignite (Incubating) 1.0

[Stian Soiland-Reyes]

 ?
My apologies for not looking up how to actually use Ignite :)


The build still requires the edtFTPj dependency to compile, even
without -Plgpl - using urideploy through Maven would always pull in
the edtFTPj dependency.

It is also in the zip:
  inflating: 
ignite-fabric-1.0.0/libs/optional/ignite-urideploy/edtFTPj-1.5.3.jar


I see it says a different license there

ignite-fabric-1.0.0/libs/optional/ignite-urideploy/licenses/edtftp-license.pdf
(from http://www.enterprisedt.com/products/edtftpj/doc/license.pdf )

which is Subject to payment of the Source License fee: and have
several requirements for notices (which may or may not be satisfied by
you including that PDF :) )


This is a bit unclear to me.. have you paid that fee? Do I need to pay
that fee to use urideploy? Can I give this compiled
ignite-fabric-1.0.0.zip to a customer, or would they also need to pay
a fee?

I guess this comes from
http://central.maven.org/maven2/com/enterprisedt/edtFTPj/1.5.3/edtFTPj-1.5.3.pom
and some  Maven plugin just picking the last license ?


On 31 March 2015 at 16:43, Dmitriy Setrakyan dsetrak...@apache.org wrote:
 On Tue, Mar 31, 2015 at 8:35 AM, Stian Soiland-Reyes st...@apache.org
 wrote:

 That thread does not mention edtFTPj or the test dependencies.

 http://enterprisedt.com/products/edtftpj/


 but if edtFTPj is optional, why is it then not marked as such in the
 modules/urideploy/pom.xml?

 If I comment out edtFTPj, then I get lots of compiler errors.


 Stian, edtFTPj is also optional (sorry, forgot to mention). I am not sure
 what you mean by commenting it, but the maven build does not include it
 into the release with default settings, no need to change anything.

 - Execute mvn clean package -DskipTests with JDK 7
 - Go into target folder and unzip ignite-fabric-1.0.0.zip file
 - You will notice that there is not a single LGPL dependency there.

 If users would like to explicitly include LGPL dependencies into their own
 build, then they should build the project with the following command:

 mvn clean package -DskipTests -Prelease,lgpl

 These instructions are also listed in the DEVNOTES.txt.

 Hope this clarifies things.

 D.



 modules/urideploy is depended on by modules/spring which is depended
 on by lots of other modules, it does not look optional to me.

 On 31 March 2015 at 16:26, Marvin Humphrey mar...@rectangular.com wrote:
  On Tue, Mar 31, 2015 at 8:16 AM, Stian Soiland-Reyes st...@apache.org
 wrote:
  -0 because of required LGPL dependencies.
 
  I think we established that these were optional and thus allowed during
  the last release:
 
  http://s.apache.org/vfN
 
  As far as LGPL, to my knowledge, Ignite only has 2 optional LGPL
  dependencies which are for the optional integration with the
 following
  products:
 
  - Hibernate ORM, http://hibernate.org/orm/
  - JTS Topology Suite from VividSolutions for geospatial indexing,
  http://www.vividsolutions.com/jts/JTSHome.htm
 
  Marvin Humphrey
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 



 --
 Stian Soiland-Reyes
 Apache Taverna (incubating), Apache Commons RDF (incubating)
 http://orcid.org/-0001-9842-9718

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org





-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Ignite (Incubating) 1.0

[Stian Soiland-Reyes]

You did not include the hashes, so I will assume:

stain@biggie-utopic:/tmp/92/people.apache.org/~dsetrakyan/incubator-ignite-1.0.0$
cat *md5 *sha1
401e8407bb262aacb1600bb188f9  incubator-ignite-1.0.0-src.zip
a8f643ffdc5b45101cf5a9ad5f19b9fce5a4099f  incubator-ignite-1.0.0-src.zip


I would have expected KEYS to be in the version-independent folder, e.g.

https://dist.apache.org/repos/dist/release/incubator/ignite/KEYS


I would have expected the release candidate to have been uploaded to
ignite/ under
https://dist.apache.org/repos/dist/dev/incubator/
rather than at people.apache.org
(and then just do a svn move of the version folder after approval -
which pretty much guarantees that it's the correct files that were
voted over).


Verified:

1) GPG signature matches BD656948 from KEYS
2)

On 31 March 2015 at 02:38, Dmitriy Setrakyan dsetrak...@apache.org wrote:
 Hello,

 The Apache Ignite PPMC voted to release Apache Ignite (incubating) 1.0.

 We now request the IPMC to vote on the release.

 Here is the PPMC voting result form Apache Ignite IPMC (note that 2 votes
 are from the IPMC members)

 2 +1 (IPMC)
 5 +1 (PPMC)

 The dev list voting thread:
 http://s.apache.org/N5N

 All release artifacts have been uploaded here:
 http://people.apache.org/~dsetrakyan/incubator-ignite-1.0.0/

 Please start voting.

 +1 - to accept Apache Ignite (incubating) 1.0 release
 0 - don't care either way
 -1 - DO NOT accept Apache Ignite (incubating) 1.0 release (explain why)



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [POLL] Using this list to discuss pTLP proposals, ok?

[Stian Soiland-Reyes]

The main job of the Incubator is to evaluate and develop incoming
projects into eventually becoming TLPs (or to attic those that don't).

So far, this has been done by having them as podlings under the
supervision of the Incubator PMC.

In the case of pTLPs, candidate projects would be at a stage where
they would already are deemed mature enough to become TLPs (e.g. they
include at least 3 existing Members, or whatever the criteria becomes)
- but the evaluation of that being the case or not could still be see
within the merits of the Incubator project -  until the 'podling' has
become a pTLP itself - as there is no intermediate podling state.

In a way the incubator should be happy about this - pTLPs are podlings
that requires no podling time, only evaluation and bootstrapping. (I'm
undecided if that evaluation would require a [VOTE] or not).

It is true that the prospective pTLP could in theory propose itself
directly to the board - but the board would probably be happier with a
process where a pre-evaluated proposal come up through the incubator.

There is still many of the same practical issues - describing the
project and its community, IP clearance, discussions and guidance,
even growing the initial community (but not as mentors!). Whatever we
learn from evaluating pTLPs will also guide other podlings, e.g. we
can recognize and advise when a new proposal should aim for a pTLP or
not.



On 23 March 2015 at 08:12, Bertrand Delacretaz bdelacre...@apache.org wrote:
 On Sun, Mar 22, 2015 at 8:27 PM, Alan D. Cabrera l...@toolazydogs.com wrote:
 ...The mailing lists derive their power from being focused on specific 
 topics

 I disagree, our mailing lists are focused on *communities*, not topics.

 ...With that said, pTLP and direct-to-TLP issues have no business being on 
 the
 Incubator lists since they are not under the purvey of the Incubator

 I also disagree ;-)

 The Incubator community, on which this list is focused, has experience
 handling the formation of podlings and their graduation. Creating a
 TLP without incubating shares a lot of steps and concerns which those
 operations, so discussing that here makes perfect sense.

 -Bertrand

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Groovy into the Apache Incubator

[Stian Soiland-Reyes]

+1 (non-binding)
On 19 Mar 2015 06:56, Roman Shaposhnik r...@apache.org wrote:

 Following the discussion earlier in the thread:
http://s.apache.org/KWE

 I would like to call a VOTE for accepting Groovy
 as a new incubator project.

 The proposal is available at:
 https://wiki.apache.org/incubator/GroovyProposal
 and is also included at the bottom of this email.

 Vote is open until at least Saturday, 21st March 2015, 23:59:00 PST

  [ ] +1 accept Groovy in the Incubator
  [ ] ±0
  [ ] -1 because...

 Thanks,
 Roman.

 == Abstract ==
 Groovy is an object-oriented programming language for the Java
 platform. It is a language with features similar to those of Python,
 Ruby, Java, Perl, and Smalltalk.
 Groovy, if accepted by Incubator, will be a first major programming
 language developed under the umbrella of Apache Software Foundation.

 == Proposal ==
 Groovy is a programming language for the Java platform. It is a
 primarily dynamic language with features similar to those of Python,
 Ruby, Perl, and Smalltalk. It also has optional static type checking
 and static compilation facilities. It can be used as a scripting
 language for the Java Platform or to write complete applications, is
 compiled to Java Virtual Machine (JVM) bytecode, and interoperates
 with other Java code and libraries. Groovy uses a Java-like
 curly-bracket syntax. Most Java code is also syntactically valid
 Groovy, although semantics may be different. Groovy has long been
 developed under an Apache License v2.0 under an open governance
 community management process. However, so far Groovy has been a
 project mostly sponsored by a single company. This proposal aims at
 bringing Groovy community under the umbrella of the Apache Software
 Foundation.

 It must be explicitly noted, that a few sister projects such as Groovy
 Eclipse and others (some of them hosted under
 https://github.com/groovy and listed at
 http://groovy-lang.org/ecosystem.html) are not covered by this
 proposal. It is possible that these other projects will be joining ASF
 either independently or as sub-projects of Apache Groovy in the
 future. For now, we are only proposing groovy-core.

 == Background ==
 Groovy 1.0 was released on January 2, 2007, and Groovy 2.0 in July,
 2012. Groovy 2.5 is planned for release in 2015. Groovy 3.0 is planned
 for release in 2016, with support for a new Meta Object Protocol.
 Since version 2, Groovy can also be compiled statically, offering type
 inference and performance very close to that of Java. Groovy 2.4 will
 be the last major release under Pivotal Software's sponsorship, which
 is scheduled to end on March 31, 2015.

 == Rationale ==
 Groovy is a pretty mature language. After 12 years of development, it
 has grown from being primarily a dynamic scripting language on the JVM
 to an optionally statically compiled language allowing the same
 performance level as Java applications. With the release of Groovy
 2.4, the language targets the largest pool of mobile developers with
 native Android support. Groovy has been integrated in a large number
 of applications, including well known open-source projects like
 Jenkins, Gradle, ElasticSearch, Spring and more.

 There are multiple alternative languages on the JVM: Scala, Clojure,
 Ceylon, Kotlin, JRuby, Golo and others but Groovy is the only one
 which has proved to be very easy to integrate with Java in both ways:
 Groovy code using Java code, but also Java code using Groovy code.
 Groovy even provides a joint compiler which allows interdependent Java
 and Groovy classes to compile together. Groovy also supports dynamic
 code generation, that is to say classes at runtime, making it a
 perfect fit for scripting. With a very lightweight and malleable
 syntax, it is also easy to build internal Domain Specific Languages
 (DSLs) which integrate smoothly within applications.

 Groovy provides a number of unique features, like builders (Java 8 has
 lambdas but still has syntactic overhead and no notion of delegate),
 AST transformations (compile-time metaprogramming) or type checking
 extensions (which allows the developer to bring the compiler to levels
 of type checking and type inference that go far beyond what other
 languages do). Groovy also provides powerful integration options and
 customizations which set it apart from other languages. Groovy is also
 unique in the way it allows the developer to choose between various
 paradigms without compromise: functional vs object-oriented,
 statically compiled vs dynamic, scripting vs applications, etc.

 Despite all those advantages, and the fact that Groovy is widely
 adopted (4.5 million downloads in 2014 for Groovy alone), only a few
 Apache projects include Groovy and not a lot of them leverage its full
 power. Some developers tend to choose Scala for example to build DSLs
 without even knowing that the learning curve is much easier with
 Groovy, or that they can leverage powerful type inference in their own
 DSLs.

 Android 

Re: [DISCUSS] Groovy Incubation proposal

[Stian Soiland-Reyes]

First of all, this is a great proposal and as a occasional Groovy coder,
Groovy would be a very valuable addition to the Apache family.

My only concern is with the timing of the below:

 Groovy 2.4 will
 be the last major release under Pivotal Software's sponsorship, which
 is scheduled to end on March 31, 2015.

 Groovy has historically been hosted at Codehaus. While the project has
started
 to migrate off the Codehaus infrastructure, some critical tools of the
 project are
 still hosted there: JIRA, the mailing-list, and the deprecated wiki.
 Codehaus has
 announced end-of-support for mid-April, making the migration critical.

 Even though the sponsorship of the core team by
 Pivotal is ending on March 31st, the sheer size and diversity of the
 community is a guarantee against the project being orphaned.

Apache is a largely volunteer-driven organization. Some podling setup
stages, like getting git repositories and web pages can take up to two
weeks - Easter is also around the corner.

Migration of mailing lists is very much a manual operation where each
subscriber has to sign up manually. You can script-invite (ask me for one
such script), but still each subscriber has to confirm to move over.

Migrating issues and wikis can take some preparation.

Importing code from Github is however very easy (DVCS!), but only after the
Software Grants + CLAs have been signed, sent and accepted.

Just creating @apache.org accounts can take a week or two.

Several of the above are in a dependency chain. Obviously your mentors will
know this and guide you (and help you ping the right people when needed).
You have a very strong mentor list, so I am not too concerned.

Is the wider Groovy community aware that transitioning to Apache is not
done overnight? There is no guarantee this will be complete by mid-April,
which to me sounds optimistic.

Have anything be done to ask Codehaus for an extension of support during
the migration process?

Re: [DISCUSS] Groovy Incubation proposal

[Stian Soiland-Reyes]

The github-asf integration is fairly smooth, if not as cool as the big
Merge button. For the requester there is no difference, only the Apache
committer have to do manual steps.

An example email, which we set up to go to dev@:

http://apache-taverna-dev.markmail.org/thread/gq62b33me5mjjkjw

If you just do those commands as in the email, you are done.

Any replies on the mailing list thread as goes back to github (and hence
the submitter) and vice versa - although with the occasional formatting
issue.

The only awkward bit is that you have to use dummy commits to close any
pull requests that you don't want to merge.

Btw, I think the example commands could be improved, --no-ff or something
should force a merge commit (where you can say the This closes #15 in the
commit message)

It has also been suggested to do a trial of GitLab installation at Apache,
with various feedback.

http://mail-archives.apache.org/mod_mbox/community-dev/201503.mbox/
CADmm%2BKff9qR_zQstYxbW%3DsHMfV7%3DzZrFvuND_Mn7-8Ljp819hQ%40mail.gmail.com
On 11 Mar 2015 20:42, Guillaume Laforge glafo...@gmail.com wrote:

 Yes Benedikt, we're aware of that.
 It's actually been one of the (pain) points we raised when discussing with
 our (then-soon-to-be) mentors and champion.
 Working with the Github infrastructure was very smooth, very handy and
 practical.
 But we'll have to get used to this new approach!

 Guillaume

 On Wed, Mar 11, 2015 at 9:24 PM, Benedikt Ritter brit...@apache.org
 wrote:

  Is the groovy project aware that (to my knowledge) the coding has to
  happen on ASF infrastructure? You won't be able to use the github web UI
  for merging PRs for example, because currently the ASF only mirrors git
  repositories from git.apache.org to github.
 
  I'm very excited about this project, and will definitively be on board if
  groovy enters incubation.
 
  Benedikt
 
  2015-03-11 21:11 GMT+01:00 Cédric Champeau cedric.champ...@gmail.com:
 
  A good answer to this is to take a look at who actually contributed for
  the
  past 4 years:
 
 
 https://github.com/groovy/groovy-core/graphs/contributors?from=2011-01-01to=2015-03-11type=c
  and you will see that there are not so many regular contributors. GitHub
  helped us a lot recently to have more contributions, from simple typos
 to
  complex bug fixes, but one should not forget that a contribution in
 GitHub
  doesn't mean that the author is a committer : it's just that authors are
  preserved.
 
  While we have a lot of contributors, only a few of us have a deep
  knowledge
  of Groovy internals. We will certainly encourage regular contributors to
  become committers (we already think of some), as long as those are
  following quality standards, take care of important things like
  maintaining
  backwards compatibility etc... We had more than 5 committers in the
 past,
  but lots of them just stopped pushing code, for various reasons. In the
  end
  I would be the first pleased to see more committers, but meritocracy is
  also important. And to be clear, we do not think only about code:
  contributions like documentation or tests are also very important.
 
  2015-03-11 20:17 GMT+01:00 Roman Shaposhnik ro...@shaposhnik.org:
 
   On Wed, Mar 11, 2015 at 12:08 PM, jan i j...@apache.org wrote:
Hi.
   
Having just skimmed the proposal, that in general look good, one
 thing
caught my eye.
   
The proposal talks several places about a vibrant community and the
   initial
commiters are only 5.
  
   This, is a GREAT question! Thank you so much for raising it. While
   preparing a proposal I've struggled with the same issue, because
 looking
   at this: https://github.com/groovy/groovy-core/graphs/contributors
  makes
   me wonder exactly the same thing.
  
   In the end, we decided to go ahead with the proposal the way it is and
   position
   the initial list of committers more as a PMC for the project.
  
   That still doesn't answer your (or mine! ;-)) question of what's the
  best
   way
   to make sure than anybody who feels like they have a stake in the
  project
   and have contributed in the past get invited.
  
   There are a few alternatives I could see, but I would really
   appreciate Incubator's
   collective wisdom on what would be the best way to proceed here given
   that Groovy is a very mature project with a lot of contributors in the
   past.
   Some of whom may or may not wish to keep contributing.
  
   Thanks,
   Roman.
  
 
 
 
 
  --
  http://people.apache.org/~britter/
  http://www.systemoutprintln.de/
  http://twitter.com/BenediktRitter
  http://github.com/britter
 



 --
 Guillaume Laforge
 Groovy Project Manager

 Blog: http://glaforge.appspot.com/
 Social: @glaforge http://twitter.com/glaforge / Google+
 https://plus.google.com/u/0/114130972232398734985/posts

Re: GPL Code in GitHub

[Stian Soiland-Reyes]

 of the
 University of Nottingham.

 This message has been checked for viruses but the contents of an
 attachment may still contain software viruses which could damage your
 computer system, you are advised to perform your own checks. Email
 communications with the University of Nottingham may be monitored as
 permitted by UK legislation.




-- 
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: GPL Code in GitHub

[Stian Soiland-Reyes]

 of an
 attachment may still contain software viruses which could damage your
 computer system, you are advised to perform your own checks. Email
 communications with the University of Nottingham may be monitored as
 permitted by UK legislation.






 This message and any attachment are intended solely for the addressee
 and may contain confidential information. If you have received this
 message in error, please send it back to me, and immediately delete it.

 Please do not use, copy or disclose the information contained in this
 message or in any attachment.  Any views or opinions expressed by the
 author of this email do not necessarily reflect the views of the
 University of Nottingham.

 This message has been checked for viruses but the contents of an
 attachment may still contain software viruses which could damage your
 computer system, you are advised to perform your own checks. Email
 communications with the University of Nottingham may be monitored as
 permitted by UK legislation.




-- 
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

www.apache-extras.org wrong redirect (was: GPL Code in GitHub)

[Stian Soiland-Reyes]

That must be a configuration error for http://www.apache-extras.org/

http://apache-extras.org/ redirect correctly to
https://code.google.com/a/apache-extras.org/hosting/

I've raised it as https://issues.apache.org/jira/browse/INFRA-9229


On 4 March 2015 at 15:26, John D. Ament johndam...@apache.org wrote:
 I notice that apache-extras is now forwarding to Any23.  Is that on purpose?

 On Wed, Mar 4, 2015 at 10:15 AM Benson Margulies bimargul...@gmail.com
 wrote:

 An Apache project may not manage a codebase outside of Apache. Some people
 who happen to be members of an Apache community can maintain code outside
 of Apache, if they are very clear in distinguishing; it must not be a
 product of the project. See 'Apache Extras'.

 On Wed, Mar 4, 2015 at 8:46 AM, Jean-Baptiste Onofré j...@nanthrax.net
 wrote:

  Hi Julian,
 
  the code is not included in the project (just a reference) ?
 
  Regards
  JB
 
 
  On 03/04/2015 02:44 PM, Julian Tenney wrote:
 
  Question: I know I've seen this discussed here before, and in any case,
  you guys are the best source for an answer:
 
  Can we have GPL code in a repository as long as that is not distributed
  with the product in a 'official' release?
 
  Thanks a lot,
 
  Julian
 
 
 
 
  This message and any attachment are intended solely for the addressee
  and may contain confidential information. If you have received this
  message in error, please send it back to me, and immediately delete it.
 
  Please do not use, copy or disclose the information contained in this
  message or in any attachment.  Any views or opinions expressed by the
  author of this email do not necessarily reflect the views of the
  University of Nottingham.
 
  This message has been checked for viruses but the contents of an
  attachment may still contain software viruses which could damage your
  computer system, you are advised to perform your own checks. Email
  communications with the University of Nottingham may be monitored as
  permitted by UK legislation.
 
 
  -
  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
 
 




-- 
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

RE: GPL Code in GitHub

[Stian Soiland-Reyes]

In *github* you should not be worried about GPL code. In git.apache.org you
should. (Apache's git repos are mirrored back again to github.com/apache
but that is another matter)

Apologies for not knowing your context..

If you are staging the github repos to move them into Apache, then I would
remove any GPL-using code first to new repos, or (less disruptive) set up
intermediate forks that you clean up and then stage to git.apache.

Just to check: You don't have any code/binary that is GPL *in your git
repository* which you don't have the right to relicense to Apache (under
the Software Grant), right?  That could complicate things slightly.
 On 4 Mar 2015 16:37, Julian Tenney julian.ten...@nottingham.ac.uk
wrote:

 Thanks to everyone for their contributions. The key uncertainty is whether
 GPL code in the github is problematic, and the answer is 'yes'.

 I wrote the following back to our own lists:
 The whole reason to do Apache license is to make it super-crystal clear
 that this code is absolutely fine for whatever re-use you want to make of
 it, and GPL is definitely not even the merest inkling of a problem for you.
 That would be undermined if we had a repo with GPL code in it.

 Cheers.

 -Original Message-
 From: Stian Soiland-Reyes [mailto:st...@apache.org]
 Sent: 04 March 2015 15:45
 To: general@incubator.apache.org
 Subject: Re: GPL Code in GitHub

 Releases explained here:

 https://www.apache.org/dev/release.html

 Basically putting into git/svn is not a release - but as anyone
 (practically any committer) can propose a release candidate for voting
 based on the code in the source code repository, it should still be code
 that is distributable under the Apache License.


 On 4 March 2015 at 15:29, Julian Tenney julian.ten...@nottingham.ac.uk
 wrote:
  The following should help the developer understand why we can't accept
 GPL code in Apache projects:
 
  The question is more about when does 'distribution' happen? When you put
 something in your github? Or when you make a release and the files
 associated with that release?
 
  -Original Message-
  From: Matt Franklin [mailto:m.ben.frank...@gmail.com]
  Sent: 04 March 2015 15:26
  To: general@incubator.apache.org
  Subject: Re: GPL Code in GitHub
 
  On Wed, Mar 4, 2015 at 10:23 AM Julian Tenney 
 julian.ten...@nottingham.ac.uk wrote:
 
  We have two things that are GPL: one is optional, I don't have any
  problem with that. I'm trying to get a bit more understanding of the
 other one!
 
  But the point is taken: if that component is needed to make a certain
  function work, and that function is considered a central part of the
  software (a feature as it were), then there is a problem.
 
  So it follows that any GPL based stuff must be optional, bringing
  additional functionality.
 
  I know the developer is going to ask why can't it live in the
 repository.
  But first I'll find out if it is a feature or an option.
 
 
  The following should help the developer understand why we can't accept
 GPL code in Apache projects:
 
  http://www.apache.org/licenses/GPL-compatibility.html
  http://www.apache.org/legal/resolved.html
 
 
 
  -Original Message-
  From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net]
  Sent: 04 March 2015 15:17
  To: general@incubator.apache.org
  Subject: Re: GPL Code in GitHub
 
  Exactly, that's why I asked ;)
 
  Just to be sure, else it's an issue IMHO.
 
  Regards
  JB
 
  On 03/04/2015 04:14 PM, Benson Margulies wrote:
   An Apache project may not manage a codebase outside of Apache. Some
   people who happen to be members of an Apache community can maintain
   code outside of Apache, if they are very clear in distinguishing;
   it must not be a product of the project. See 'Apache Extras'.
  
   On Wed, Mar 4, 2015 at 8:46 AM, Jean-Baptiste Onofré
   j...@nanthrax.net
   wrote:
  
   Hi Julian,
  
   the code is not included in the project (just a reference) ?
  
   Regards
   JB
  
  
   On 03/04/2015 02:44 PM, Julian Tenney wrote:
  
   Question: I know I've seen this discussed here before, and in any
   case, you guys are the best source for an answer:
  
   Can we have GPL code in a repository as long as that is not
   distributed with the product in a 'official' release?
  
   Thanks a lot,
  
   Julian
  
  
  
  
   This message and any attachment are intended solely for the
   addressee and may contain confidential information. If you have
   received this message in error, please send it back to me, and
  immediately delete it.
  
   Please do not use, copy or disclose the information contained in
   this message or in any attachment.  Any views or opinions
   expressed by the author of this email do not necessarily reflect
   the views of the University of Nottingham.
  
   This message has been checked for viruses but the contents of an
   attachment may still contain software viruses which could damage
   your computer system, you are advised to perform your own checks.
   Email

Re: GPL Code in GitHub

[Stian Soiland-Reyes]

It depends how you integrate it - you can't put LGPL or GPL stuff into
distributions from Apache - and you can't really do a release that is
incomplete without it (e.g. To make X work, download the GPL library
Y and put it into lib)

Optional dependencies (e.g. plugins) should however be fine to be
externally managed - but you have to make it very clear that they are
not affiliated with Apache.

For instance for Apache Taverna we had an in the pre-incubator code
some optional plugins that have LGPL dependencies, so we simply put
them at https://github.com/taverna-extras and link to it from
http://taverna.incubator.apache.org/download/code/#taverna-extra as
independent community-submitted plugins.

A common thing is mysql-client.jar which is GPL - so as long as your
code is happy to work with other JDBC drivers (why wouldn't it?) you
can just have instructions on how to download it and put it in lib/
for those that are happy to use mySQL - and have some other reasonable
default otherwise (e.g. Apache Derby)



On 4 March 2015 at 13:44, Julian Tenney julian.ten...@nottingham.ac.uk wrote:
 Question: I know I've seen this discussed here before, and in any case, you 
 guys are the best source for an answer:

 Can we have GPL code in a repository as long as that is not distributed with 
 the product in a 'official' release?

 Thanks a lot,

 Julian




 This message and any attachment are intended solely for the addressee
 and may contain confidential information. If you have received this
 message in error, please send it back to me, and immediately delete it.

 Please do not use, copy or disclose the information contained in this
 message or in any attachment.  Any views or opinions expressed by the
 author of this email do not necessarily reflect the views of the
 University of Nottingham.

 This message has been checked for viruses but the contents of an
 attachment may still contain software viruses which could damage your
 computer system, you are advised to perform your own checks. Email
 communications with the University of Nottingham may be monitored as
 permitted by UK legislation.




-- 
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept CommonsRDF into the Apache Incubator

[Stian Soiland-Reyes]

+1 (non-binding) :-)
On 27 Feb 2015 19:19, Lewis John Mcgibbney lewis.mcgibb...@gmail.com
wrote:

 Hi general@,

 Over the last while a number of individuals have been putting together a
 proposal and gathering interest in proposing Commons RDF for acceptance
 into the Apache Incubator. Having worked our way through the Incubator
 documentation checklists -
 http://incubator.apache.org/guides/proposal.html#formulating, we are now
 brining this proposal back to the general@ list.

 Commons RDF is a set of interfaces for the RDF 1.1 concepts that can be
 used to expose common RDF-1.1 concepts using common Java interfaces. The
 current CommondRDFProposal document can be found at -
 https://wiki.apache.org/incubator/CommonsRDFProposal

 This thread is therefore aimed at obtaining general consensus from the
 incubator community on whether the proposal document is suitable and
 whether the project as described should begin an incubation period at
 Apache.

 The VOTE is therefore as follows

 [ ] +1 I am happy with Commons RDF entering incubation
 [ ] +0/-0 I am neither yay or nay
 [ ] -1 I am not happy with this proposal because

 The VOTE will be open for at least 72 hours.

 p.s. Here is my +1 PPMC binding

 --
 *Lewis*

Re: How to add a committer that is not incubator.

[Stian Soiland-Reyes]

On 24 Feb 2015 08:36, jan i j...@apache.org wrote:

 If we want to add a existing committer (one with an apache ID) to our
 project as PPMC and committer, we of course have the normal vote.


If that committer happens to also be an Apache Member, then it probably
would be great for that person to also join IPMC directly so that you would
have one more +1 for you release votes here.
Technically (s)he needs to be added to the incubator LDAP group by IPMC
through the lazy consensus forwarding of the podling vote.

Re: [VOTE] Release Apache Johnzon 0.6-incubating

[Stian Soiland-Reyes]

The email does not define any hashes on the source releases, so I
assume the following (as reported by Nexus *.sha1 files)

742c6e38de9dbc9a9d01363ea93e3168740af278  johnzon-0.6-incubating-src.tar.gz
c1518db14f1256bb4b69aa461f6e04e8f459aeac  johnzon-0.6-incubating-src.zip

(I'm OK with this for now as I checked they match the git commit - but
it would be great to include the src hashes in the voting email as
that is what is usually verified)


+1 (non-binding)

There is no README in the source download, so I was not quite what to
do  - but mvn clean install worked.


Checked:

* sha1 hashes (see above)
* 22D7F6EC: is in KEYS
* pgp signatures verified for zip and tar.gz
* zip and tar.gz content match
* git checkout of commit dda975b327211277fc96c4155b6e98bc54a4a7d9
matches src tar.gz
* LICENSE/NOTICE/DISCLAIMER present/correct
* No binaries in source release
* mvn clean install works
  (Maven 3.2.1, openjdk 1.8.0_40-internal, ubuntu 14.10 x64, empty
.m2/repository
* rat reports OK
* mvn license:aggregate-add-third-party OK (incl. 2 dual CDDL/GPL)



(Stian's extra-extra-today-only-binary-checks):

* 
https://repository.apache.org/content/repositories/orgapachejohnzon-1003/org/apache/johnzon/
does not include any additional modules not in the source release
* File listing of Nexus JARs match what is produced on build (I could
not compare the *.class files! :) )
* asc on JARs verified (all by 22D7F6EC)
* sha1 on JARs verified
* produced JARs don't contain anything not in org/apache/* package
(except a couple of resources and META-INF)

I did not verify the content of -source.jars in Nexus. :)



On 20 February 2015 at 13:23, Hendrik Dev hendrikde...@gmail.com wrote:
 The Apache Johnzon PPMC has voted to release Apache Johnzon
 0.6-incubating based on the release candidate described below. Now it
 is the IPMC's turn to vote.

 Git commit for the release is
 https://git-wip-us.apache.org/repos/asf?p=incubator-johnzon.git;a=commit;h=dda975b327211277fc96c4155b6e98bc54a4a7d9

 Maven staging repo:
 https://repository.apache.org/content/repositories/orgapachejohnzon-1003/

 Source releases (zip/tar.gz):
 https://repository.apache.org/content/repositories/orgapachejohnzon-1003/org/apache/johnzon/johnzon/0.6-incubating/johnzon-0.6-incubating-src.zip
 https://repository.apache.org/content/repositories/orgapachejohnzon-1003/org/apache/johnzon/johnzon/0.6-incubating/johnzon-0.6-incubating-src.tar.gz

 PGP release keys (signed using 22D7F6EC):
 https://dist.apache.org/repos/dist/release/incubator/johnzon/KEYS

 Project vote passes with 3 binding +1 votes, one non-binding +1 vote
 and no -1 votes:
 http://markmail.org/thread/25qwunhagpurthev
 http://markmail.org/thread/tppdxzn7dz3rhdxq

 This release fixes a few bugs related to comment parsing and mapper.

 The vote will be open for at least 72 hours.

 [ ] +1  approve
 [ ] -1  disapprove (and reason why)

 Thanks

 --
 Hendrik Saly (salyh, hendrikdev22)
 @hendrikdev22
 PGP: 0x22D7F6EC

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




-- 
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: -incubator in versions of podling maven artifacts

[Stian Soiland-Reyes]

Agreed. Both podlings and graduated projects might release components that
are at different maturity levels.

So formally incubation status should really be indicated with a different
groupId, not as a version qualifier.

This would however cause unnecessary confusion if/when the project
graduates, as the groupId would suddenly change.

With different groupIds, Maven would not easily detect the duplicate if a
project somehow pulled in both an incubator and a graduate release

Downstream users would just see there were no further releases beyond the
last incubator one. (Maven renames help, but are still underutilized)

So personally, as a heavy Maven user, I very much still more prefer the
current norm of indicating the incubation status in the version field, even
though it is not quite technically correct by some measures.
On 11 Feb 2015 21:29, Roman Shaposhnik ro...@shaposhnik.org wrote:

 On Wed, Feb 11, 2015 at 1:01 AM, Stian Soiland-Reyes st...@apache.org
 wrote:
  An incubator release is a kind of pre-release - community wise. But
 perhaps
  you mean this is not ideal for mature projects who were codewise stable
  before joining the incubator?

 To me the biggest signaling that needs to happen has little to do with
 the quality/maturity
 of the code (which is a subjective metric anyway) but with the fact
 that something coming
 out of org.apache.* groupID is NOT YET a full member of ASF family
 (and worse case
 scenario may never be).

 Thanks,
 Roman.

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: -incubator in versions of podling maven artifacts

[Stian Soiland-Reyes]

When you say break, do you mean some software is unable to compare version
numbers correctly, or that we don't comply with the text of
http://semver.org ?

 A pre-release version MAY be denoted by appending a hyphen and a series
of dot separated identifiers immediately following the patch version.
Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-].
Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading
zeroes. Pre-release versions have a lower precedence than the associated
normal version. A pre-release version indicates that the version is
unstable and might not satisfy the intended compatibility requirements as
denoted by its associated normal version. Examples: 1.0.0-alpha,
1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

An incubator release is a kind of pre-release - community wise. But perhaps
you mean this is not ideal for mature projects who were codewise stable
before joining the incubator?
On 10 Feb 2015 23:29, Julien Le Dem jul...@ledem.net wrote:

 Hi Incubator,
 I'd like some context about the requirement of adding -incubating in the
 file name of podling releases.

 http://incubator.apache.org/guides/releasemanagement.html
 http://incubator.apache.org/guides/release-java.html#best-practice-maven

 It seems we require adding -incubating in the version for maven artifacts
 which breaks Semantic versioning as hyphen is used for pre-releases.
 It is also confusing as we vote on a version number but that's not what we
 use as the artifact version.
 We are already publishing the source release in the incubator project and
 have incubating in its file name as well as DISCLAIMER files.
 So it seems to me that adding it in the maven artifact is a bit overkill.
 Every release as to get through the vote of the IPMC anyway so it's not
 like podlings releases are not vetted appropriately.

 opinions from the IPMC?

 Julien

Re: Draft Report February 2015 - please review

[Stian Soiland-Reyes]

 adoption.

 Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
 aware of?

   - None at this time.

 How has the community developed since the last report?

   - 8 new JIRA issues filed since last report (2014-11-01)
   - 12 JIRA issues resolved since last report (2014-11-01)
   - 3 new contributors submitted patches

 How has the project developed since the last report?

   - Version 0.4.1-incubating RC3 being voted upon

 Date of last release:

   - 2014-11-17: 0.4.0-incubating

 When were the last committers or PMC members elected?

   - No new committers since incubation.

 Signed-off-by:

   [ ](twill) Arun C Murthy
   [ ](twill) Tom White
   [X](twill) Patrick Hunt
   [ ](twill) Andrei Savu

 Shepherd/Mentor notes:

   Konstantin Boudnik (cos):

 Very modest activity on the mailing list: pretty much just JIRAs and very
 light of it.

 
 Zeppelin

 A collaborative data analytics and visualization tool for distributed,
 general-purpose data processing systems such as Apache Spark, Apache Flink,
 etc.

 Zeppelin has been incubating since 2014-12-23.

   1. SGA: IP clearance to be signed by NFLabs
   2. Finish migration to ASF infra: code and issues
   3. Complete PODLINGNAMESEARCH-64


 Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
 aware of?

   None.

 How has the community developed since the last report?

   We've received several patches from contributors outside of the initial
   committers list.  They are also participating in some discussions @dev

 How has the project developed since the last report?

   All code base is ready to be migrated.

   The project is waiting for the Software Grant from NFLabs legal
   department.

   Major features implemented are: custom Zeppelin interpreters-to-note
   binding and dynamic .jar dependency loading

 Date of last release:

   None.

 When were the last committers or PMC members elected?

   None since incubation

 Signed-off-by:

   [X](zeppelin) Konstantin Boudnik
   [X](zeppelin) Henry Saputra
   [ ](zeppelin) Roman Shaposhnik
   [X](zeppelin) Ted Dunning
   [ ](zeppelin) Hyunsik Choi

 Shepherd/Mentor notes:

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




-- 
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Commons RDF to join the Apache Incubator

[Stian Soiland-Reyes]

For your convenience, here's the proposal text for CommonsRDF:

= Apache Commons RDF incubation proposal =

TableOfContents()

== Status ==

Draft

== Abstract ==

Commons RDF is a set of interfaces for the RDF 1.1 concepts that can
be used to expose common RDF-1.1 concepts using common Java
interfaces.

== Proposal ==

The main motivation behind this simple library is revise an historical
incompatibility issue. This library does not pretend to be a generic
api wrapping those libraries, but a set of interfaces for the RDF 1.1
concepts that can be used to expose common RDF-1.1 concepts using
common Java interfaces. In the initial phase commons-rdf is focused on
a subset of the core concepts defined by RDF-1.1 (URI/IRI, Blank Node,
Literal, Triple, and Graph). In particular, commons RDF aims to
provide a type-safe, non-general API that covers RDF 1.1. In a future
phase we may define interfaces for Datasets and Quads.

The goal is to provide a compact API that could be implemented by the
upcoming versions of the main Java toolkits (Apache Jena 3.0 and
OpenRDF Sesame 4.0) as well as for other libraries (OWLAPI) and other
JVM languages (Banana RDF and so on).


In addition, the project could provide some simple implementations
suitable for some basic scenarios. But the major and established Java
toolkits will always remain the recommend implementations to use.

== Background ==

In the Java world there has been historically an incompatibility issue
between the two major RDF toolkits: Apache Jena and OpenRDF Sesame.
Many libraries have tried to wrap them, but besides technical
considerations, they normally end up being unmaintained.

Together, we came up with the idea of Commons RDF for solving the
incompatibility problem. The community has been in healthy development
at Github, including participants from the major Java RDF toolkits.

The natural path to Apache Commons Sandbox has been studied, but we
think that in this phase of the project, which focuses on the API
design and actively involves the developers of existing toolkits, it
is better to have a more focused community and infrastructure. Rather
than a new Top-Level Project, the goal is still to graduate as part of
Apache Commons, that is when API has achieve the required maturity and
the project goes into maintenance mode.

Part of the motivation for doing the incubator process would therefore
be to bring together the existing Commons RDF community in the Apache
Way, mature the API, and then gradually prepare the Commons RDF
community for working within the larger Apache Commons community.

== Rationale ==

The library comes from the need for providing a generic and neutral
API for RDF 1.1 that everybody can transparently use without bounding
the design to concrete implementations. It is the result of
cooperation between contributors to the main Java toolkits, and will
try to be available in a timely manner to influence the major version
updates Jena 3.0 and Sesame 4.0.

== Initial Goals ==

 * Evolve the API towards a generalized and agreed shape
 * Bootstrap basic implementations
 * Support the implementation

== Current Status ==

The API is already quite agreed by all involved players, and it's been
started to be prototyped, both by the major toolkits and by simple
implementations.

=== Meritocracy ===

Commons RDF has been completely designed by committee using git
workflows, where every single feature has been discussed based on a
Pull Request. We plan to keep such methodology where the commons
understanding comes first than personal decisions.

=== Community ===

Commons RDF addresses the developers who are working with Semantic Web
technologies in the JVM. The initial committers are core contributors
to that community.

=== Core Developers ===

 * Sergio Fernández (wikier dot apache dot org)
 * Andy Seaborne (andy dot apache dot org)
 * Peter Ansell (ansell dot apache dot org)
 * Stian Soiland-Reyes (stain at apache dot org)
 * Reto Gmür (reto at apache dot org)

=== Alignment ===

Commons RDF comes to help in the integration of the different ASF
projects using RDF technologies, where Apache Jena can be integrated
with others which use Sesame (Any123 and Marmotta). In addition,
proposals by other projects (Clerezza and Stanbol) can be also
aligned.

== Known Risks ==

=== Orphaned Products ===

Probably one of the major risks will that the API provided does not
fit well in the development plan of the main Java toolkits. But we try
to minimize such risk by having on board core developers of those
framework, the API will live or die on its own merits.

=== Inexperience with Open Source ===

The committers have large experience with open source development and
ASF communities.

=== Homogeneous Developers ===

The initial list of developers come from five different organizations
and four different countries.

=== Reliance on Salaried Developers ===

Although the project is also in the strategic agenda of project of our
current employers, so far

Re: [DISCUSS] Commons RDF to join the Apache Incubator

[Stian Soiland-Reyes]

 is important, unfortunately it's
 not a valid nomination.

We pointed this out, we would however still like to keep Benedikt as
an informal mentor and our Commons representative - in a way we have
to learn also the Commons Way.

Voting-wise we have 2 IPMC members already, but obviously it would be
good to have more IPMC folks mentoring so we don't have to 'fish' for
release votes.


 I'd nudge newly elected IPMC member Rob Vesse, but maybe the roster is already
 Jena-heavy?

Good idea. :) And not unknown territory for Rob.

So I agree to be careful of getting Jena-heavy (I'm not quite neutral
either), but it would be great to have Rob involved - I'm sure he
would try to keep his clean fresh mentor hat on  - just like I try to
keep my API user hat on in this project. :-)

We were hoping to also get some RDF neutral mentors.

-- 
Stian Soiland-Reyes

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: -incubator in versions of podling maven artifacts

[Stian Soiland-Reyes]

Agree about the worry about breaking semantic versioning. OSGi-wise
for example this is a bit tricky, where you have to do
0.5.3.incubating instead to ensure incubating is a qualifier rather
than part of the 3.


But if the project is publishing Maven artifacts, then I believe it's
pretty clean if a project release time-line goes like this:

(groupId:artifactId:version)

org.apache.thingie:thingie-api:0.5.0-incubating
org.apache.thingie:thingie-api:0.6.0-incubating
org.apache.thingie:thingie-api:0.6.1
org.apache.thingie:thingie-api:1.0.0

.. rather than varying the groupId or artifactId before/after
graduation. Here 0.6.1 is still a patch release from 0.6.0-incubating
(so not breaking anything), but community-wise it is sending a
stronger signal.

I think formally the requirement is just that there is incubating
somewhere in the released downloadables, it doesn't have to be part of
the version number.

On 10 February 2015 at 23:25, Julien Le Dem jul...@ledem.net wrote:
 Hi Incubator,
 I'd like some context about the requirement of adding -incubating in the file 
 name of podling releases.

 http://incubator.apache.org/guides/releasemanagement.html
 http://incubator.apache.org/guides/release-java.html#best-practice-maven

 It seems we require adding -incubating in the version for maven artifacts 
 which breaks Semantic versioning as hyphen is used for pre-releases.
 It is also confusing as we vote on a version number but that's not what we 
 use as the artifact version.
 We are already publishing the source release in the incubator project and 
 have incubating in its file name as well as DISCLAIMER files.
 So it seems to me that adding it in the maven artifact is a bit overkill.
 Every release as to get through the vote of the IPMC anyway so it's not like 
 podlings releases are not vetted appropriately.

 opinions from the IPMC?

 Julien






-- 
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Incubating with Apache Commons as champion?

[Stian Soiland-Reyes]

The discussion on dev@commons about coming-to-Apache Commons-RDF
(https://github.com/commons-rdf/commons-rdf/) seems to be rejecting a
temporary mailing list like rdf@commons as it is seen t be splitting
Apache Commons as a project - the ideal committer on Apache Commons is
caring about all its components (avoiding the Jakarta pitfalls).


We had not considered becoming a TLP as once the API (mainly a set of
interfaces) is settled, by then it will probably be pretty much a
quiet project except the odd maintenance patch - and also by being a
common component of several RDF projects within Apache, its best home
then would be under Commons (presumably with most of the original
committers still involved).


However the large traffic of dev@commons (~400/month) about all the
other components can be a problem for trying to engage the non-Apache
community around commons-rdf while we flesh out the API. (This has
currently been done solely through Github issues, pull requests, and
watching the project).

In a way we are limited by the technology of the Apache mailing lists.
(I know, I know...).

(I mentioned gitlab.com )


The suggestion is that Commons-RDF could be a incubator project, but
with a projected path to become part of the Apache Commons instead of
a TLP.  (I believe this path has not happened before)


So this would be using the old structure of having a champion of
Apache Commons - could this be a workable incubator project?

In a way it would be incubating just the code until API maturity
rather than the community or Apache Way as both of those already
exist.

In such an (old skool) setup, would it be the Commons PMC /
dev@commons who would vote over the incubating releases?

Once graduating it would just become a component under Apache
Commons and the community would just be dev@commons where the
committers would already be members - the dev@rdf.incubator list would
simply close.

.. and where would mentors come from? Would existing committers from
those other Apache projects (Jena, Marmotta, Clerezza) be enough - or
should it be someone from IMPC or from dev@commons?


See 
http://mail-archives.apache.org/mod_mbox/commons-dev/201501.mbox/%3CCAB917RLJE%2BgFEpw%3Dyp-c-HpXEnvL12JZLLpc4wphGyjGH_6%3D9Q%40mail.gmail.com%3E
for the whole threads :)


-- Forwarded message --
From: Stian Soiland-Reyes st...@apache.org
Date: 20 January 2015 at 14:06
Subject: Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
To: Commons Developers List d...@commons.apache.org


Agree that maybe the the Incubator with a projected path to the
Commons could be a workable middle ground while Commons-RDF is still
incubating code-wise (but not community or Apache Way-wise).

No earlier project has gone through this route
(https://incubator.apache.org/projects/ ) - this would reuse the
deprecated Champion project to be Apache Commons instead of
Incubator PMC in this case.

Such a proposal has some good features - I presume commons-rdf
releases would still be voted over (and thus involve) the Commons PMC
and dev@commons  (as they would after graduating).

As an API, then Commons-RDF should not be considered stable while
being in 0.x.x-incubating anyway.



On 20 January 2015 at 13:58, Torsten Curdt tcu...@vafer.org wrote:
  There are several ASF projects in the
 RDF space.  They have been through the incubator.  Please do talk to those
 projects if you have concerns.

 I am sorry - but how are those projects relevant in this case?

 And what's so bad about the incubator? You could (maybe) later on come
 to Commons.

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


--
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/-0001-9842-9718

-- 
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubating with Apache Commons as champion?

[Stian Soiland-Reyes]

Just because a lot of Apache committers are involved and could put
things right into another project (or even propose a new TLP directly)
doesn't mean it happens.

https://wiki.apache.org/incubator/BeanShellProposal was voted -1 in
the incubator because it had many Apache folks already and didn't need
to learn anything. Yet the project didn't move into Apache - perhaps
because it didn't have any pressure or framework to go through the
Incubator process?

(It now lives semi-dormantly as an Apache Extras thing at
https://code.google.com/a/apache-extras.org/p/beanshell/ - I joined
recently and it is slowly awakening :) )


I think the incubator should be open also for a group of experienced
Apache folks - although their needs would be different, e.g. more of a
focus on the project goals and growing their community, and not so
much worry about IP issues, licenses and build/release procedures.


On 20 January 2015 at 15:08, Rob Vesse rve...@dotnetrdf.org wrote:
 Stian

 If a community made predominantly of existing Apache committers (or
 containing a strong core of) already exists and this would be a small self
 contained module as part of Apache Commons then why does the Incubator
 need be involved at all?

 Why can this not just be submitted directly to Apache Commons via the IP
 Clearance procedure (http://incubator.apache.org/ip-clearance/index.html)?


 Commons already allows any ASF committer to commit so the existing
 community can continue working on the code just fine.  The only sticking
 point would be once Commons-RDF wants to release in which case you'd
 likely need to canvas the larger commons community for votes until such
 time as the Commons-RDF committers have earned sufficient merit to be
 offered PMC membership

 On the other hand does Commons-RDF necessarily need to come to the ASF at
 all?  If it is a small self-contained interface module that will remain
 stable what does it gain (other than brand association) by coming to the
 ASF?

 Rob

 On 20/01/2015 14:28, Stian Soiland-Reyes st...@apache.org wrote:

The discussion on dev@commons about coming-to-Apache Commons-RDF
(https://github.com/commons-rdf/commons-rdf/) seems to be rejecting a
temporary mailing list like rdf@commons as it is seen t be splitting
Apache Commons as a project - the ideal committer on Apache Commons is
caring about all its components (avoiding the Jakarta pitfalls).


We had not considered becoming a TLP as once the API (mainly a set of
interfaces) is settled, by then it will probably be pretty much a
quiet project except the odd maintenance patch - and also by being a
common component of several RDF projects within Apache, its best home
then would be under Commons (presumably with most of the original
committers still involved).


However the large traffic of dev@commons (~400/month) about all the
other components can be a problem for trying to engage the non-Apache
community around commons-rdf while we flesh out the API. (This has
currently been done solely through Github issues, pull requests, and
watching the project).

In a way we are limited by the technology of the Apache mailing lists.
(I know, I know...).

(I mentioned gitlab.com )


The suggestion is that Commons-RDF could be a incubator project, but
with a projected path to become part of the Apache Commons instead of
a TLP.  (I believe this path has not happened before)


So this would be using the old structure of having a champion of
Apache Commons - could this be a workable incubator project?

In a way it would be incubating just the code until API maturity
rather than the community or Apache Way as both of those already
exist.

In such an (old skool) setup, would it be the Commons PMC /
dev@commons who would vote over the incubating releases?

Once graduating it would just become a component under Apache
Commons and the community would just be dev@commons where the
committers would already be members - the dev@rdf.incubator list would
simply close.

.. and where would mentors come from? Would existing committers from
those other Apache projects (Jena, Marmotta, Clerezza) be enough - or
should it be someone from IMPC or from dev@commons?


See
http://mail-archives.apache.org/mod_mbox/commons-dev/201501.mbox/%3CCAB917
RLJE%2BgFEpw%3Dyp-c-HpXEnvL12JZLLpc4wphGyjGH_6%3D9Q%40mail.gmail.com%3E
for the whole threads :)


-- Forwarded message --
From: Stian Soiland-Reyes st...@apache.org
Date: 20 January 2015 at 14:06
Subject: Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
To: Commons Developers List d...@commons.apache.org


Agree that maybe the the Incubator with a projected path to the
Commons could be a workable middle ground while Commons-RDF is still
incubating code-wise (but not community or Apache Way-wise).

No earlier project has gone through this route
(https://incubator.apache.org/projects/ ) - this would reuse the
deprecated Champion project to be Apache Commons instead of
Incubator PMC in this case.

Such a proposal has

Re: [VOTE] Release Apache Usergrid 1.0.1 (incubating) RC5

[Stian Soiland-Reyes]

 that we accept the following release candidate as the
  official Apache Usergrid 1.0.1 release.
 
  Usergrid 1.0.1-rc5 includes the following:
  ---
  The CHANGELOG for the release is available
  at:https://git-wip-us.apache.org/repos/asf?p=incubator-
  usergrid.gitf=CHANGELOGhb=1.0.1-rc5
 
  The branch used to create the release candidate
  is:https://git-wip-us.apache.org/repos/asf?p=incubator-
  usergrid.githb=1.0.1-rc5
 
  The current Git commit ID is 867c6dd6f229f929f4528aa5677ee346a70f620d
 
  The release candidate is available
  at:https://dist.apache.org/repos/dist/dev/incubator/
  usergrid/1.0.1-rc5/apache-usergrid-1.0.1-rc5-incubating.tar.gz
 
  The MD5 checksum of the release candidate can be found
  at:https://dist.apache.org/repos/dist/dev/incubator/
  usergrid/1.0.1-rc5/apache-usergrid-1.0.1-rc5-incubating.tar.gz.md5
 
  The signature of the release candidate can be found
  at:https://dist.apache.org/repos/dist/dev/incubator/
  usergrid/1.0.1-rc5/apache-usergrid-1.0.1-rc5-incubating.tar.gz.asc
 
  The GPG key used to sign the release are available
  at:https://dist.apache.org/repos/dist/dev/incubator/usergrid/KEYS
 
  Please download, verify, and test.
 
  The vote will close on Sun Jan 11 21:22:33 EST 2015
 
  [ ] +1 Release this as Apache Usergrid 1.0.1
  [ ] +0
  [ ] -1 Do not release this as Apache Usergrid 1.0.1 because...
 




-- 
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[pTLP] Apache Commons sub-mailing lists discussion

[Stian Soiland-Reyes]

Relating to IncubatorV2 and pTLP proposals - on Apache Commons I seem
to have spurred a discussion about making sub-mailing lists (And thus
forming sub-communities) - but keep the formalities on the general
list.

(email below)
http://mail-archives.apache.org/mod_mbox/commons-dev/201501.mbox/%3C23d5b03fc1cdb4079ceb52c55458f0e3%40scarlet.be%3E


My slight concern (even though I would benefit from the proposal :))
is that this is in danger of forming a mini incubator with less
clear guidance and follow-up:

http://mail-archives.apache.org/mod_mbox/commons-dev/201501.mbox/%3CCAPRnXt%3DDwqk9p-b-yYBYRnrp%3DanvLgdTanMkenLfm6fGQgcHfw%40mail.gmail.com%3E


The pTLP proposal has not mentioned what would be the process for
projects with a sponsor different from Incubator (e.g. which don't
aspire to become TLPs) - presumably they would usually have mentors
from and report to the parent project?


I don't see any proposals with Apache Commons as the sponsor at
http://incubator.apache.org/projects/index.html

.. is that because Commons already have a lightweight entry path with
its sandbox?

https://commons.apache.org/sandbox.html



-- Forwarded message --
From: Gilles gil...@harfang.homelinux.org
Date: 16 January 2015 at 00:47
Subject: [ALL] Too much traffic on the dev ML
To: Commons Developers List d...@commons.apache.org


Hi.

In the discussion that started about RDF, it seems that the
traffic volume is a stumbling block.
[For some time now, it has been a growing nuisance, and the
usual dismissal about filters won't change the fact: Setting
up a filter that will redirect stuff to /dev/null is a waste
of bandwidth.]

If different ML are created, people interested in everything
can subscribe _once_, and nothing will change for them.
For people who spend a lot of time just deleting dozens messages
and notifications a day, it will be a relief.

Maintaining community conversation is not a problem: just
create an all-...@commons.apache.org ML for things that
need input form a larger audience (like votes).


Best regards,
Gilles


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

-- 
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Graduation question

[Stian Soiland-Reyes]

Will it be updated here that Flink has graduated?

http://incubator.apache.org/projects/index.html
http://incubator.apache.org/projects/flink.html

In particular the Incubation checklist is empty.

BTW - I fixed so the missing
http://incubator.apache.org/ip-clearance/index.html re-appeared - missing
quote in the index.xml

..strangely this didn't give any red flags in
http://ci.apache.org/builders/incubator-site-staging.

On 15 December 2014 at 22:07, Alan Gates ga...@hortonworks.com wrote:

 I've added the resolution to the board agenda for Wednesday's meeting.
 Thanks Marvin for the guidance.

 Alan.

   Marvin Humphrey mar...@rectangular.com
  December 15, 2014 at 11:20

 Short answer: go ahead.

 Long answer: There's no role requirement, so in theory literally
 anyone could send an email to board@apache with the resolution text.
 However, it helps if it's someone who's subscribed to board@apache
 (and thus whose messages won't get stuck in moderation) and who has
 sufficient privileges to commit changes to the board agenda in svn.
 In practice, that means that resolutions tend to be submitted by
 Mentors who are also ASF Members subscribed to board@apache.

 Marvin Humphrey

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

   Alan Gates ga...@hortonworks.com
  December 15, 2014 at 10:36
  As a Flink mentor can I submit the graduation resolution to the board now
 that it has passed, or is that a job for Roman as IPMC chair?

 Alan.


 --
 Sent with Postbox http://www.getpostbox.com

 CONFIDENTIALITY NOTICE
 NOTICE: This message is intended for the use of the individual or entity
 to which it is addressed and may contain information that is confidential,
 privileged and exempt from disclosure under applicable law. If the reader
 of this message is not the intended recipient, you are hereby notified that
 any printing, copying, dissemination, distribution, disclosure or
 forwarding of this communication is strictly prohibited. If you have
 received this communication in error, please contact the sender immediately
 and delete it from your system. Thank You.




-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/-0001-9842-9718

Re: [pTLP] Apache Commons sub-mailing lists discussion

[Stian Soiland-Reyes]

Right - then Incubator guidance really needs updated, because reading
it, it sounds like using the IPMC as a sponsor is a special case for
when you really could not find a sponsor project. Going over the list
of incubating project this hasn't really been the case this decade
except for a couple of clear sub-projects.


http://incubator.apache.org/incubation/Process_Description.html even
links to exactly to the umbrella project Jakarta.


I removed the confusing Jakarta reference and have updated it slightly
- see staging:

http://incubator.staging.apache.org/incubation/Process_Description.html

.. but more work is needed as it still describes the process as
normally sending proposals directly to the champion project, where
IPMC submission is a special case. So I agree with you that it is now
the other way around. (Also please remember people won't know jargon
like IPMC at this stage..)


I added these paragraphs to help explain what the champion will help
you with before you write and submit a proposal - we found that very
useful for our proposal and for understanding what Apache and Apache
Way really would mean for us and our project.


 Simply email that person directly (e.g. usern...@apache.org, see the 
 committer list to find the username), describe informally yourselves and your 
 project, and ask kindly if she would be willing to act as your Champion for 
 your project within the Apache incubator. Remember that all Apache Committers 
 and Members are volunteers with limited spare time, but you will hopefully 
 find that the person is honoured by your request to be a Champion and sees a 
 potential for your project as a future Apache project.

 Once you have found an eligible person who is willing to act as Champion, you 
 can use this person to help you determine if and how your proposal can fit 
 within the ASF, and if the Apache Way of open development would be right 
 for your project. This might happen over a series of emails, telephone calls 
 or online chat sessions, and should cover any practical concerns such as 
 project infrastructure (e.g. mailing lists, web, source code repositories, 
 issue tracker, wiki) but also the implications of licensing, governance and 
 Intellectual Property management.



I have not updated from section Acceptance  and beyond to make
Incubator as Champion the default.

- any takers? :)

Or should larger parts of Process_Description.html be removed as it is
also covered by the much nicer
http://incubator.apache.org/guides/proposal.html?  (which on the other
hand doesn't say much about where you find a Champion and Sponsor).


On 16 January 2015 at 16:21, Benson Margulies bimargul...@gmail.com wrote:
 On Fri, Jan 16, 2015 at 10:39 AM, Stian Soiland-Reyes st...@apache.org 
 wrote:
 Relating to IncubatorV2 and pTLP proposals - on Apache Commons I seem
 to have spurred a discussion about making sub-mailing lists (And thus
 forming sub-communities) - but keep the formalities on the general
 list.

 (email below)
 http://mail-archives.apache.org/mod_mbox/commons-dev/201501.mbox/%3C23d5b03fc1cdb4079ceb52c55458f0e3%40scarlet.be%3E


 My slight concern (even though I would benefit from the proposal :))
 is that this is in danger of forming a mini incubator with less
 clear guidance and follow-up:

 http://mail-archives.apache.org/mod_mbox/commons-dev/201501.mbox/%3CCAPRnXt%3DDwqk9p-b-yYBYRnrp%3DanvLgdTanMkenLfm6fGQgcHfw%40mail.gmail.com%3E


 The pTLP proposal has not mentioned what would be the process for
 projects with a sponsor different from Incubator (e.g. which don't
 aspire to become TLPs) - presumably they would usually have mentors
 from and report to the parent project?

 Well, the idea of non-incubator sponsors seems to me to have been a
 dead letter for years. As of now, the board's expectation is that all
 incubating projects are supervised by the IPMC. While the proposal
 template still has a slot for sponsor, it does not mean anything in
 practice. It's the IPMC and only the IPMC that accepts new projects,
 and then supervises them.

 In the very remote case that my version of the pTLP proposal goes
 anywhere, the board would, of course, have the option of passing a
 resolution to establish a pTLP without prior vetting by the Incubator
 Committee.

 As for subcommunities, I reference the very complex process of a few
 years back of _getting rid of_ 'umbrella projects.'



 I don't see any proposals with Apache Commons as the sponsor at
 http://incubator.apache.org/projects/index.html

 .. is that because Commons already have a lightweight entry path with
 its sandbox?

 https://commons.apache.org/sandbox.html



 -- Forwarded message --
 From: Gilles gil...@harfang.homelinux.org
 Date: 16 January 2015 at 00:47
 Subject: [ALL] Too much traffic on the dev ML
 To: Commons Developers List d...@commons.apache.org


 Hi.

 In the discussion that started about RDF, it seems that the
 traffic volume is a stumbling block.
 [For some time now

Re: Git write access for podlings

[Stian Soiland-Reyes]

Git allows you to commit as whoever you want - e.g. like in SMTP
email, the headers are decided by the sender. SVN on the other hand
will show the authenticated user in the commit log. So - speaking as a
former sysadmin - it sounds a bit daring to let anyone new to Apache
from a fresh Incubator proposal to also get instant write access to
all Incubator projects, including those that are just about to
graduate.

That said - assuming there has not been any reported abuse of this
global write access - then it is a very good sign of all the new
committers being responsible people - or perhaps they just didn't know
they had that write access to begin with :). It's a trust-thing - I
remember when I started my first proper sysadmin job, and on day one
received the root passwords for systems running web and email for
30.000 students. Don't mess it up was implicit.

Apache Commons has already given write access to *all* ASF committers
[1] - which would presumably include any incubator committers.  If
it's good enough for for Commons, it should be good enough for
Incubator. Part of moving to Apache is also to trust all your
committers.

[1] 
https://mail-archives.apache.org/mod_mbox/commons-dev/201412.mbox/%3ccab917rjy57z-4pnwthvr9tuq7y3td8usg8jcmhvdthalwho...@mail.gmail.com%3E


Even with the danger of introducing a bigger temptation by explicitly
documenting the incubator-wide write policy - I would still +1 to
document this so you are aware and don't accidentally push back (as
git workflow is to commit locally and it is a bit easy to accidentally
do git push) - with a clause that this does not mean you have
formally become a committer on the other incubator projects.


I would propose to also improve documentation at

http://wiki.apache.org/general/GitAtApache
http://www.apache.org/dev/git.html
http://www.apache.org/dev/writable-git

so it does not give impression you have to use SVN-with-git-mriroring
or that writeable GIT is experimental. I don't know enough about the
particular setup at git.apache.org yet to do it myself.

On 31 December 2014 at 14:56, Ted Dunning ted.dunn...@gmail.com wrote:
 On Wed, Dec 31, 2014 at 12:27 PM, John D. Ament johndam...@apache.org
 wrote:

 On Wed Dec 31 2014 at 2:45:48 PM David Nalley da...@gnsa.us wrote:

  On Wed, Dec 31, 2014 at 2:40 PM, John D. Ament johndam...@apache.org
  wrote:
   On Wed Dec 31 2014 at 2:24:36 PM David Nalley da...@gnsa.us wrote:
  
   On Wed, Dec 31, 2014 at 11:59 AM, John D. Ament 
 johndam...@apache.org
   wrote:
Hi,
   
So something Jan and I ran into on the infra list, does anyone know
definitively what the access rights given to a podling's git repo
  are, if
they request one (instead of a svn directory)?
   
If nothing else we should document it somewhere on the incubator
 site
indicating the permission sets for both svn and git.  My current
understanding is that svn sites are typically incubator wide, svn
  repos
   are
confined to a specific list, and git repos are incubator wide.  The
  git
   one
in particular because we don't create ldap groups for podlings and
  I've
heard that we only do groups in git (not individual lists).
   
  
   git is tied to LDAP, and all podling repos are writable by anyone in
   the incubator LDAP group. (there are no podling LDAP groups)
  
  
   Got it thanks.  I'll update the docs to reflect this as the permission
   scheme.
  
   And here I think will come in Jan's bigger question - do we really want
  all
   podling committers to be able to commit to all other podlings?
  
 
  My question is: What problem are you trying to solve? And has it
  really proven to be a problem?
  I don't think anyone has abused their ability to commit to all
  projects, and it's been this way as long as git has been available.
 

 I'm not sure that there will be an issue.  It could just be a couple of
 IPMC members being a little more cautious that needed.  It's more than
 likely no one's going to care.

 To date, we have always told podlings that the initial committers and your
 mentors are the ones who have write access.  Now we're saying if you're
 using git, it's any of the 1k + (i might be way off) members of the
 incubator group.

 Would it be much harder to create the ldap group up front when the
 podling's created, and shuffle people in/out at graduation?



 If it ain't broke ...

 Is there even a problem?  I haven't ever heard of it.

 If there isn't a problem, why are you worried about it?



-- 
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Process over Ego [Was: Re: Incubator report sign-off

[Stian Soiland-Reyes]

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




-- 
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator report sign-off

[Stian Soiland-Reyes]

On 22 Dec 2014 10:42, Roman Shaposhnik r...@apache.org wrote:

 Well, than I suggest we solicit an opinion on this list of how many
mentors
 will remain if the requirement is to be put in place. I can tell you this
much:
 personally I will have to resign from every single poddling I am currently
 mentoring. There is absolutely no way I can promise the level of
commitment
 that goes beyond helping them with 'the Apache Way' and releases. IOW,
 if I were to be required to understand their technology -- I don't think
I can
 stay.

I fully agree that mentors should not be expected to gain full
understanding of the incubator's project.

The role of the mentor is to guide the project along Apache Ways, with
regards to community building and management, but also on ensuring releases
are done in an open source manner.

As part of an incubutor, I would however be grateful if at least one of the
mentors were capable in the foundational  technology, e.g. in our case
Java/Maven/OSGi. Why? There is a strong tie between those and release
management, dependency management and licensing.

We have found that our champion had the right camera and has helped with
most of the bootstrapping, while mentors have had a wider view and can say
things like Look at project X and how they do Y.

Re: Incubator report sign-off

[Stian Soiland-Reyes]

On 23 Dec 2014 11:39, Stian Soiland-Reyes st...@apache.org wrote:

 We have found that our champion had the right camera and has helped with
most of the bootstrapping

Before people start joking about incubator selfies, cameraabove is the
auto complete version of karma.. ;) although I think Andy also has a good
camera somewhere.

Re: Mail command to allow marvin emails

[Stian Soiland-Reyes]

Has there been some consideration for apache.org to use a mailing list
system with a regular web interface instead of just magic email addresses?
We've been using Mailman at Sourceforge since 2005 or so, and this ezlm
just feels like a step backwards to the 1990s. (Our university still use
ListServ. So It could be worse! ;-) )

Just yesterday I spent 15 minutes trying to find out how to link to a
thread in the apache.org mbox mail archive. It turns out you can't, in
thread view the URL never change, and in message view the thread is hidden.

Don't get me started on trying to explain how to subscribe to a list with a
different  email address than Sender header leaks (e.g. if using gmail with
a secondary email address).

I can appreciate that these kind of shortcuts can make it efficient for an
experienced moderator, but for incubating projects who are transitioning
from infrastructure like Github, Google Groups and yes, even Sourceforge,
getting used to the apache.org infrastructure is a bit of a challenge, even
for dinosaurs like myself who used this kind of technology 15 years ago.

/rant ;)
On 25 Nov 2014 11:03, Tim Ellison t.p.elli...@gmail.com wrote:

 On 24/11/14 17:39, John D. Ament wrote:
  On Mon Nov 24 2014 at 10:29:02 AM Tim Ellison t.p.elli...@gmail.com
 wrote:
 
  On 24/11/14 14:35, John D. Ament wrote:
  Does anyone know the mail command to send out to allow marvin emails
  to get to a list without moderation?
 
  If the mail hits moderation then I/some other mod will allow it through
  and add Marvin to the allowed senders' list.
 
 
  Are you referring to general@ or something else? I'm specifically
 referring
  to dev@tamaya.i.a.o and I was hoping to white list marvin (the board
 report
  email reminder).

 Well I can moderate general@ requests, but other moderators can do the
 equivalent for lists they oversee.

  I can't seem to find instructions on how to white list
  people anywhere.

 When you get the MODERATE mail you should replyAll and send the
 acknowledgement to the *-accept-* and *-allow-tc.* addresses.

 The 'accept' permits the current e-mail through, and the 'allow' address
 will add the sender to the whitelist for future mails.  There are other
 command to remove the sender if you change your mind later.

 See http://www.apache.org/dev/committers.html#mail-moderate

  If you're saying that only you can white list Marvin.. please white list
  Marvin on the listed mail alias.

 No, it requires a moderator for dev@tamaya.i.a.o to do that, and an
 incoming moderation request.

 HTH
 Tim

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: IP clearance clarification: copyright notices

[Stian Soiland-Reyes]

Right, good idea If you do the internal area, I would ensure it is not
publicly visible to non-apache.org users then. In Github we can get
away with it as it is a bit cowboy land (most small projects don't
even state their license!!).. but you wouldn't want to end up with
projects that live too long in Apache Incubator quarantine space! :)

On 14 November 2014 09:15, Bertrand Delacretaz bdelacre...@apache.org wrote:
 Hi,

 On Thu, Nov 13, 2014 at 11:14 PM, Stian Soiland-Reyes
 soiland-re...@cs.manchester.ac.uk wrote:
 For our incubator project (Taverna), we saw the need to reorganize our
 current git repositories...
 We therefore have made a separate staging area on Github, and then
 basically we will move from github.com/taverna/* to
 github.com/taverna-incubator/* step by step

 Ok, that resonates with the quarantine space idea, he you did that
 externally but we can also suggest an internal quarantine are (which
 might be just a folder with this name) when code that's not fully
 cleaned up is imported.

 -Bertrand

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: IP clearance clarification: copyright notices

[Stian Soiland-Reyes]

.

 -Alex




-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

How to make an incubator website?

[Stian Soiland-Reyes]

Hi, I seem to be very confused by the documentation for Apache CMS,
the incubator website, and SVN.


https://incubator.apache.org/guides/sites.html says:

 The published site for each podling should conform to this URL space:
 http://podlingname.incubator.apache

 The website lives in the following directory on people.apache.org:
 /www/podlingname.apache.org/content/


https://www.apache.org/dev/cmsref.html#svn

says

 Easiest way to get setup quickly is to use the boilerplate site setup. It has 
 the right files in the right structure. Just export it and add it to svn.

 svn export https://svn.apache.org/repos/infra/websites/cms/template site
 svn add site
 svn ci site -m initial setup for the cms



All of these documentations use incomplete URIs like In SVN, so I
have no idea about what is the SVN space I am meant to modify.


I was able to follow the above and add site to
https://svn.apache.org/repos/asf/incubator/taverna/ - but I believe
this is totally the wrong place, because nothing appears on

http://taverna.incubator.apache.org/


SSH to people.apache.org reveals no folder for Taverna in /www

stain@minotaur:/www$ ls -al *taverna*
ls: *taverna*: No such file or directory



Any hints or suggestions on how to improve this documentation? Is some
more bootstrapping required through INFRA and our mentors?




-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [Proposal] Taverna workflow

[Stian Soiland-Reyes]

Right - many, many levels of provenance... provenance of source code is not
very much different from provenance of workflow definitions. We already did
quite a bit of work with that on a social level with our generic workflow
sharing platform myExperiment - http://www.myexperiment.org/home  -- e.g.
Version 4 of this workflow - attributed to this other workflow by someone
else.  This might be of interest to other Workflow-like projects within
Apache - as myExperiment can deal with any workflow type.

For instance, my workflow at http://www.myexperiment.org/workflows/3860
attributes http://www.myexperiment.org/workflows/3369 because I have
embedded it as a nested workflow. I have therefore also given the original
authors credit on my workflow.  Lots of this information can be deduced by
inspecting the definitions, looking at hashes and identifiers, etc.
(Taverna workflow definitions includes a chain of identifiers throughout
its evolution - so you can even tell if an earlier, unpublished version of
a workflow has been reused).



Provenance of a workflow *execution* is also quite related to, but still
quite distinct from, the higher level provenance of research data and of
the scientific analysis it has been going through. Similarly the provenance
of a command line tool can be on system-level Ran for 14 seconds on a
Linux host asdkjasd using 1127 MB of memory and these shared libraries -
or on a semantic level like Aligned these two biological sequences from
mouse and rat.

The big challenge is trying to bind these kinds of provenance together, and
to infer one level of provenance from another.


But I am digressing!  My apologies to the rest of the list.. but do let me
know if you are interested in workflows, provenance, versioning and
semantics, and we can put together some kind of interest group.



On 23 October 2014 07:41, Bertrand Delacretaz bdelacre...@apache.org
wrote:

 Hi,

 Thanks for the clarifications.

 On Thu, Oct 23, 2014 at 4:43 AM, Stian Soiland-Reyes
 soiland-re...@cs.manchester.ac.uk wrote:
  ...Provenance exchange - I am thinking in particular if it would be
  possible to combine our W3C PROV-O provenance support -
  https://github.com/taverna/taverna-prov (which describes a workflow
  run) - with exposing service-level provenance...

 Ok got it now. We sometimes talk about the provenance of our code,
 which must be traceable etc. so I was confused why you'd exchange
 provenance with other projects ;-)

 All clear now.
 -Bertrand

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/-0001-9842-9718

Re: [RESULT] [VOTE] Accept Taverna into the Apache Incubator

[Stian Soiland-Reyes]

On behalf of the Taverna community, thank you for all your support!

On 20 October 2014 08:46, Andy Seaborne a...@apache.org wrote:
 To: general@incubator.apache.org

 This VOTE passes with 13 +1 binding votes

 Suresh Marru
 Alan D. Cabrera
 jan I
 Ralph Goers
 Bertrand Delacretaz
 Andy Seaborne
 Suresh Srinivas
 Chris Mattmann
 Jean-Baptiste Onofré
 Jake Farrel
 Leif Hedstrom
 Jean-Louis Monteiro
 Roman Shaposhnik

 and no 0's or -1's

 I'll start the podling setup process.

 Thank you everyone.

 Andy

 On 16/10/14 16:54, Andy Seaborne wrote:

 Following the discussion earlier in the thread:

 https://www.mail-archive.com/general@incubator.apache.org/msg45241.html

 I would like to call a Vote for accepting Taverna as a new incubator
 project.

 The proposal is available at:

 https://wiki.apache.org/incubator/TavernaProposal

 Vote is open until at least Sunday, 19th October 2014, 23:59:00 UTC

   [ ] +1 accept Taverna in the Incubator
   [ ] ±0
   [ ] -1 because...

 Only Votes from Incubator PMC members are binding, but everyone is
 welcome to contribute to the process.



 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [Proposal] Taverna workflow

[Stian Soiland-Reyes]

On 25 September 2014 17:34, David Nalley da...@gnsa.us wrote:
 Can you make sure a comprehensive list of those currently incompatible
 list of dependencies is included in your proposal.

I have added them to
http://dev.mygrid.org.uk/wiki/display/developer/Third-party+licenses

and added references to this from
https://wiki.apache.org/incubator/TavernaProposal#External_Dependencies
and added complete resolution of the remaining unknown licenses to
https://wiki.apache.org/incubator/TavernaProposal#Initial_Goals


Should I move those sections from the Taverna wiki to embed in the
proposal? (I think it could be a bit noisy).


See https://github.com/taverna/taverna-build/tree/master/licenses for
the complete lists as generated by Maven.



 Taverna 2 is licensed as LGPL 2.1, which meant we could use several
 LGPL libraries like Hibernate and RShell. Hibernate can be replaced by
 other JPA providers (with some code update to remove Hibernate
 specific calls), while the RShell support would have to be moved out
 to an separately installable plugin.
 Do you have adequate rights to change the license wholesale?

Yes, as we declare under
https://wiki.apache.org/incubator/TavernaProposal#Source_and_Intellectual_Property_Submission_Plan
we the University of Manchester is the copyright holder and
contributitions from outside the University have all signed CLAs that
allow us to change the license and redelegate copyright.


 This sounds like fragmenting your existing community before you really
 even get started. I believe the ASF is a great place, but I am not
 convinced it's the best place for everyone.

Yes, I am afraid the AstroTaverna community was not too keen on the
perceived fragmentation, but as long as we keep the AstroTaverna
developers involved in Apache Taverna (Julián Garrido is included as
an Initial Committer), and keep the existing plugin support (with an
additional What do you want splash screen on first start) it should
not be a big change for existing users or indeed for developers.

AstroTavena is already a separate project - at
https://github.com/wf4ever/astrotaverna (of which I am personally also
taking part) - and it is only in the recent Taverna Astronomy Edition
(introduced in Taverna 2.5) that this plugin was brought into the
release.

The Astronomy Edition (if it is with a different plugin system in
Taverna 3) can be distributed as a non-Apache release by the
AstroTaverna community - our build system already have the editions
parametrized so that this is not too difficult.


 I see two paragraphs here that don't answer the question posed. Where
 will plugin development happen in an ideal world?

I guess as separate projects, but with a clear invitation to the
Apache project so that such developers also get involved in the Apache
Taverna community.

One way to do such invitation is to include those plugins in the
release (optional on install).


 One followup question - what kind of build/CI resources does the
 University of Manchester provide? What manner of resources do you
 believe you'll need if the project moves to the ASF?

We tried to detail this under
https://wiki.apache.org/incubator/TavernaProposal#Required_Resources

We should be fine with the existing capabilities as ASF already have
Jenkins, Jira, Confluence, Git and Maven repositories.  There would
obviously be migrations jobs needed for existing documentation, issues
etc.



-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [Proposal] Taverna workflow

[Stian Soiland-Reyes]

On 25 September 2014 19:19, Suresh Marru sma...@apache.org wrote:
 Hi Stian,

 If you need a mentor, count me in. I actively contribute to Apache Airavata, 
 and will be happy to bring our experiences from a similar journey. Infact 
 Ross queried on airavata lists few years ago about potential taverna move to 
 airavata/apache(Ross mentioned it further in this thread), good to see 
 finally its happening. Integrating plugin community into the apache project 
 (once its voted in) seems to be a low hanging fruit to diversify.

Very interesting to have you in as a mentor - it will be exciting to
also look at working together with Airavata.

 David questions are right on. Two things you may want to consider addressing 
 before you call for a vote are: listing of non-apache compatible license in 
 the proposal and having adequate rights to change the license to Apache V2.

I have added a link to these at the end of
https://wiki.apache.org/incubator/TavernaProposal#External_Dependencies

I have added a sentence to make it explicit that we can change the
license at the end of
https://wiki.apache.org/incubator/TavernaProposal#Source_and_Intellectual_Property_Submission_Plan


 Not a blocker for the proposal and voting, but a blocker for importing the 
 code will be to have on file the University signed CCLA/SGA to donate the 
 code.

The lawyers have told me some time ago that they have signed the CCLA
- which I needed for a contribution to Apache CXF - I am not sure
where on Apache.org to check for the list of CCLA signatures as only
individual signatures seems to be listed.



-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: FW: [Proposal] Taverna workflow

[Stian Soiland-Reyes]

Thanks, I have signed up to the Airavata Architecture mailing list to
follow the discussion.

If you could Reply to the existing thread I can chip in with a
description of SCUFL2.

On 30 September 2014 17:31, Shameera Rathnayaka shameerai...@gmail.com wrote:
 Hi Devs,



 Apache Airavata http://airavata.apache.org/ is a software framework
 for executing and managing computational jobs and workflows on
 distributed computing resources. Taverna's concern is not as much job
 coordination, but more of a data flow between services. Airavata's
 XBaya Workflow Suite can export workflows in Taverna 1 format SCUFL,
 but could be updated to work with Taverna 3's SCUFL2 format.


 I am a committer of Apache Airavata project and interesting to contribute
 for Airavata-SCUFL2 integrations. I already have started a mail [1] thread
 in apache Airavata architecture mailing list to explore the next generation
 workflow description language for Airavata which best support and suit for
 Scientific domains.

 [1] http://markmail.org/thread/tkpbj3sr4jhg6o6z

 Thanks,
 Shameera.



-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [Proposal] Taverna workflow

[Stian Soiland-Reyes]

Would any of the Taverna mentors be interested in joining the Taverna
Development Workshop at the end of the month?

http://taverna2014.eventbrite.co.uk/
http://dev.mygrid.org.uk/wiki/display/developer/Taverna+Open+Development+Workshop

I know most of you are not really based near Manchester - but we are
already arranging for remoting in for another participant, so that is
always an option if the time-zones allow.


On 15 October 2014 10:02, Andy Seaborne a...@apache.org wrote:
 On 14/10/14 16:51, Marlon Pierce wrote:

 Hi all--

 I'm a bit late on this but I would also like to serve as a mentor. I'm a
 PMC member of Apache Airavata and Apache Rave, and I've also served as a
 mentor for Apache Stratos.

 Marlon


 Marlon,

 Thank you for the offer - I've added you to the the mentor list on the
 proposal.

 Andy



 On 9/26/14, 10:18 AM, Andy Seaborne wrote:

 On 25/09/14 19:19, Suresh Marru wrote:


 If you need a mentor, count me in.
 I actively contribute to Apache Airavata, and will be happy to bring
 our experiences from a similar journey. Infact Ross queried on
 airavata lists few years ago about potential taverna move to
 airavata/apache(Ross mentioned it further in this thread), good to
 see finally its happening. Integrating plugin community into the
 apache project (once its voted in) seems to be a low hanging fruit to
 diversify.


 On 25/09/14 17:36, Suresh Srinivas wrote:
If you you need a volunteer, I am available.

 Hi there,

 It being Friday, and Stian is about to be away, I've added you both to
 the mentors list.  Taverna has a long history so getting as much
 experience from mentors will be very valuable.

 Thanks
 Andy

 PS I put Michael in as Not formally a mentor



 -
 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




-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [Proposal] Taverna workflow

[Stian Soiland-Reyes]

Thanks, Andy, and all who responded and volunteered (yay!).

I'm sure Shoaib will respond, but as I have been the main maven and build
guy on the project I guess I should also chip in. I'll try to find time to
respond properly to the excellent questions next week, in between my baby
duties. Some heads up for now, hyperlink-less as I am on mobile:

Two things came up in several of the responses:

(L)GPL dependencies. We know we have some, and we have a Dependencies wiki
page that is linked to from the proposal, but more work is needed with
Maven licensing plugin  to double check we have not also got something
coming in from transitive dependencies.

Due to the occasional use of OSGi repackaging, the licensing seems to have
been lost in some of the modules, requiring manual citation (e.g. googling
;). I agree that the definitive list should be in the proposal and it would
be something we will work on producing.

The infrastructure we need is listed in the proposal, it is bog standard
confluence, hits, Jenkins and maven repository (obviously we would hope for
importants for the first two). I have a script for making all the Jenkins
jobs based on listing of github repositories, it could be modified to do
the same for the repos once on Apache git server.

I admit that the scale might be a bit different for our project, but part
of moving to the incubator would be to also restructure/merge the
repositories (and hence Jenkins jobs) as I have mentioned.

(We know the big structure is also scaring potential developers away - part
reason for the size of the existing structure is the homebrew Maven-based
plugin system we used before moving to OSGi)

It would probably make sense to do this merge restructure outside Apache
before transitionin the code base, as on Github it is just a click away to
make another repo.

Perhaps making an alternative github group taverna-incubator as the
staging area - would it be possible to do this as part of the early
incubation period? It is a process that could do with community effort for
discussion, testing and also in a way give a better feel for what the
different modules are and do, so perhaps a nice way to get the ball rolling.

(Why would it take 2-3 days to clone 70 repos anyway..? The make script we
have in the taverna-build repo checks out all of them in 3-4 minutes, even
dynamically picking up any new repos).
 On 26 Sep 2014 16:18, Andy Seaborne a...@apache.org wrote:

 On 25/09/14 19:19, Suresh Marru wrote:


 If you need a mentor, count me in.
 I actively contribute to Apache Airavata, and will be happy to bring our
 experiences from a similar journey. Infact Ross queried on airavata lists
 few years ago about potential taverna move to airavata/apache(Ross
 mentioned it further in this thread), good to see finally its happening.
 Integrating plugin community into the apache project (once its voted in)
 seems to be a low hanging fruit to diversify.


 On 25/09/14 17:36, Suresh Srinivas wrote:
If you you need a volunteer, I am available.

 Hi there,

 It being Friday, and Stian is about to be away, I've added you both to the
 mentors list.  Taverna has a long history so getting as much experience
 from mentors will be very valuable.

 Thanks
 Andy

 PS I put Michael in as Not formally a mentor



 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: Access to wiki

[Stian Soiland-Reyes]

I still can't get the wiki to work. I believe my wiki username is
StianSoilandReyes - not soilandreyes (which turns out only to be my
login)

How do I go about to create a new proposal page?

On 24 September 2014 13:54, Stian Soiland-Reyes
soiland-re...@cs.manchester.ac.uk wrote:
 Hi,

 Could I get write access to the incubator wiki?

 username: soilandreyes

 --
 Stian Soiland-Reyes, myGrid team
 School of Computer Science
 The University of Manchester
 http://soiland-reyes.com/stian/work/ http://orcid.org/-0001-9842-9718



-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [Proposal] Taverna workflow

[Stian Soiland-Reyes]

 is licensed under GPL 2 with classpath
exception. It is likely that under Apache we could not distribute
OpenJDK - but perhaps it would instead be allowed to distribute the
normal JDK binaries? (For Taverna 2 we did not distribute the normal
JDK as it can be seen as incompatible with GPL, which LGPL can be
upgraded to).  Do you know of any Apache projects that do this, like
perhaps OpenOffice?

An alternative is for the installer to download JDK on demand - but
would that require the installer itself (currently Install4j) to be
replaced?


 * Would you like developer-contributed plugins to be covered within a future
 Apache Taverna project?

As we've seen, keeping plugin developers on the outside of the
project has isolated them from the core development. We would
therefore like to encourage any new plugin developers to eventually
make their plugin a part of an Apache Taverna project - as we have
done historically with successful plugins. Apache's use of CLAs is I
must admit a bit of a hindrance to this as opposed to the Github
Laissez-faire style - - it has kept myself away from Apache projects
earlier when my suggested patch was deemed significant - yet the
legal department of the University spent 8 months reviewing that patch
and Apache's CLA before finally signing.

Yet we consider Taverna to be such a mature project that we want IP
and licensing to be done correctly - and as you see our earlier
insistence on keeping CLAs for all Taverna 2 development means that we
are now in a position to relicense Taverna and change ownership to a
foundation like Apache.


-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [Proposal] Taverna workflow

[Stian Soiland-Reyes]

In addition to what I said to Marion,

One of the things we want to achieve in the short-term is to get
non-Manchester developers comfortable with working with the code base.

We already have a fair amount of documentation on this -
http://dev.mygrid.org.uk/wiki/display/developer/Developers+Guide - but
it is still mainly centred around creating plugins.

In a way, earlier, we have inadvertently tried to push people away
from the core codebase because in most cases what they wanted to do
could be achieved using the plugin mechanism - which simplifies both
development and distribution (you don't need to distribute your own
build of Taverna).  As I mentioned to Marion, this has had the
unfortunate effect of almost nobody else working with that code base.

In the Taverna Development workshop, as mentioned, we have included in
the agenda several items on working with the code base, how to create
a build, showing how to fix a bug.  We would want to keep working with
Github mirrors, as we have seen what an enormous boost to third-party
developer engagement it can be to, lowering the barrier for forking,
changing, customizing, fixing. However we we recognize that our
current large number of git repositories is also effectively a blocker
to such engagement.

The CLAs of Apache (and Taverna) is likewise such a barrier - but we
would keep a similar stand as other Apache projects I've been involved
with (Jena), where small contributors are accepted as-is, creating a
stepping stone for further engagement that encourages signing of CLA
and a deeper feeling of commitment.



On 25 September 2014 13:55, Suresh Marru sma...@apache.org wrote:
 Hi Sitan,

 I am also interested in knowing your responses to some of the questions below.

 Looking through this list archives you will find that the issue of homogenous 
 developers comes up every now and then. Its a welcoming move from Taverna 
 team to pursue ASF as a potential home, but its important to understand on 
 plans of diversifying core development beyond University of Manchester.

 Suresh

 On Sep 23, 2014, at 1:54 PM, Marlon Pierce marpi...@iu.edu wrote:

 Thanks, Stian, for submitting a well-developed proposal and for your 
 interest in Apache. I have a few questions:

 * Can you say more about why you want to take Taverna to the ASF?

 * What is your strategy for increasing the diversity of your committer base?

 * Do you have any third party dependencies in the Taverna core that have 
 incompatible licenses (like GPL)?

 * Would you like developer-contributed plugins to be covered within a future 
 Apache Taverna project?

 My main goal here is to give the Incubator community a little more 
 background and foster discussion, which will be useful in attracting 
 mentors, so don't worry about right or wrong answers.

 Marlon

 On 9/23/14, 8:43 AM, Stian Soiland-Reyes wrote:
 I hereby present the Apache Incubator proposal for the project Taverna.


 Also available in rich text in the Taverna wiki (with more hyperlinks!):

 http://dev.mygrid.org.uk/wiki/display/developer/Taverna+incubator+proposal

 (Could someone grant me access to edit the Incubator wiki pages? My
 wiki username is soilandreyes)




 # Abstract

 Taverna is an open source and domain-independent suite of tools used
 to design and execute data-driven workflows.


 # Proposal

 The Taverna suite includes:

 * Taverna Workbench, a Java-based desktop application for graphically
 composing, editing and executing workflows of distributed web services
 and local tools
 * Taverna Commandline Tool which allows repeated execution of
 parameterized workflow definitions
 * Taverna Server provides a REST and SOAP API for executing workflows
 * Taverna Player is a Ruby-based web interface towards the Server,
 providing a high-level view of workflow executions and their results,
 and allows further integrations with Ruby on Rails applications.

 Taverna can browse and combine different service types, allowing
 workflows to integrate steps of arbitrary REST and SOAP web services
 with command line tools (local and SSH), scripts (Beanshell, R,
 Jython) and finally visualize the results.

 The goal of the Taverna suite is to help researchers to access
 distributed datasets and processing capabilities by the construction
 of pipelines, and also to simplify the execution of  these pipelines
 in various environments.

 The Taverna suite of products is already successful and in wide-use
 across different domains. The software is currently licensed as LGPL
 2.1, with copyright owned by University of Manchester. External
 contributors have all signed Apache-like CLAs.


 # Background

 Taverna workflows coordinate inputs and outputs between computational
 processes and Web Services. The workflow is designed in a graphical
 interface which shows the workflow as a series of boxes and arrows;
 representing processes and their data connections. The different
 processes in a workflow can be command line tools, REST and WSDL Web

Re: Access to wiki

[Stian Soiland-Reyes]

Thanks! Seems to work. Not very fast, though..

On 25 September 2014 16:37, Bertrand Delacretaz bdelacre...@apache.org wrote:
 On Thu, Sep 25, 2014 at 5:23 PM, Stian Soiland-Reyes
 soiland-re...@cs.manchester.ac.uk wrote:
 ...I believe my wiki username is
 StianSoilandReyes - not soilandreyes...

 I have added the former to
 https://wiki.apache.org/incubator/ContributorsGroup, please try again.

 -Bertrand

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [Proposal] Taverna workflow

[Stian Soiland-Reyes]

Proposal now moved to the Apache wiki:

https://wiki.apache.org/incubator/TavernaProposal

I just used copy-paste - so there might be some mistakes introduced -
feel free to correct.


I will be away for 2 weeks - but my colleague Shoaib Sufi should have
signed up to this list to assist in any question during that period.



On 23 September 2014 13:43, Stian Soiland-Reyes
soiland-re...@cs.manchester.ac.uk wrote:
 I hereby present the Apache Incubator proposal for the project Taverna.


 Also available in rich text in the Taverna wiki (with more hyperlinks!):

 http://dev.mygrid.org.uk/wiki/display/developer/Taverna+incubator+proposal

 (Could someone grant me access to edit the Incubator wiki pages? My
 wiki username is soilandreyes)




 # Abstract

 Taverna is an open source and domain-independent suite of tools used
 to design and execute data-driven workflows.


 # Proposal

 The Taverna suite includes:

 * Taverna Workbench, a Java-based desktop application for graphically
 composing, editing and executing workflows of distributed web services
 and local tools
 * Taverna Commandline Tool which allows repeated execution of
 parameterized workflow definitions
 * Taverna Server provides a REST and SOAP API for executing workflows
 * Taverna Player is a Ruby-based web interface towards the Server,
 providing a high-level view of workflow executions and their results,
 and allows further integrations with Ruby on Rails applications.

 Taverna can browse and combine different service types, allowing
 workflows to integrate steps of arbitrary REST and SOAP web services
 with command line tools (local and SSH), scripts (Beanshell, R,
 Jython) and finally visualize the results.

 The goal of the Taverna suite is to help researchers to access
 distributed datasets and processing capabilities by the construction
 of pipelines, and also to simplify the execution of  these pipelines
 in various environments.

 The Taverna suite of products is already successful and in wide-use
 across different domains. The software is currently licensed as LGPL
 2.1, with copyright owned by University of Manchester. External
 contributors have all signed Apache-like CLAs.


 # Background

 Taverna workflows coordinate inputs and outputs between computational
 processes and Web Services. The workflow is designed in a graphical
 interface which shows the workflow as a series of boxes and arrows;
 representing processes and their data connections. The different
 processes in a workflow can be command line tools, REST and WSDL Web
 Services; which are used for combining steps such as data acquisition,
 filtering, cleaning, integrating, analysis and visualization. Taverna
 calls these processes services, as they generally are provided by
 remote (third-party) servers.

 These kind of computational workflows, also known as pipelines and
 dataflows, focus on the movement of data rather than the execution
 order of the underlying processes. Features such as implicit
 iterations (where an input list of values causes multiple process
 executions) and parallel invocations (independent processes are
 executed as soon as their data is available) are intrinsic to a
 dataflow system, not requiring any particular constructs by the
 workflow designer.

 As a visual programming environment, workflows aids collaboration and
 reuse of workflows. At the highest level, a workflow represents the
 conceptual level of an analysis, allowing understanding, discussion
 and communication of the overall analysis protocol. More detail can be
 revealed and modified for individual steps. At the individual process
 level, the workflow defines execution specifics such as operations,
 parameters and command line tools.

 Sharing of the workflow definitions allows re-use and re-purposing of
 the computational analysis. During workflow execution, provenance can
 be collected from every step, allowing deep inspection of intermediate
 values for the purpose of debugging and validation.


 # Rationale

 There is a strong need to lower the barrier of entry to datasets and
 computational resources widely available on the Internet, to increase
 their use by researchers who understand the computational steps needed
 to produce their results, but who are not necessarily expert
 programmers. Taverna has already shown its success and popularity in a
 wide range of scientific disciplines.


 # Initial Goals

 * Transition mailing lists to Apache (keep existing subscribers, but
 invite more)
 * Taverna developer workshop (2014-10-30)
 * Prepare git repositories for move:
   * Update headers/metadata to indicate Apache License 2.0
   * Restructure git repositories
   * Rename Maven groupIds to org.apache.taverna.*
   * Rename packages to org.apache.taverna.*

 * Move Github repositories to Apache git
 * Automated builds in Apache's Jenkins
 * Update to latest releases of Apache dependencies
 * Propose updated release  testing procedure under Apache
 * Moved Website