I like it. I'll try to get something started in the next few days.
On Thu, Mar 10, 2016 at 3:48 PM Stian Soiland-Reyes
wrote:
> I like how Groovy used the Project Maturity Model (see below)
>
> Perhaps we could maintain a similar doc in our wiki, add those
> Taverna-specific
I sent an email... I intersting in 2 ideas...
El mar. 10, 2016 18:14, "Stian Soiland-Reyes" escribió:
> Great! I am also registered as a gsoc mentor now.
>
> Yes, add yourself as a mentor to the issues, although we will need to see
> which proposals we get in before we can
Great! I am also registered as a gsoc mentor now.
Yes, add yourself as a mentor to the issues, although we will need to see
which proposals we get in before we can assign mentorship.
Anyone else willing to mentor..? I think it is not too late.
On 10 Mar 2016 11:38, "Alan Williams"
Github user asfgit closed the pull request at:
https://github.com/apache/incubator-taverna-server/pull/1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if
Github user stain commented on the pull request:
https://github.com/apache/incubator-taverna-server/pull/1#issuecomment-194788068
Well spotted! Thank you for the pull request, @gmlewis! I've raised it as
https://issues.apache.org/jira/browse/TAVERNA-934 as I think we need to upgrade
On 09/03/16 14:59, Stian Soiland-Reyes wrote:
On the http://wiki.apache.org/incubator/March2016 report, our Chris
Mattmann added:
Chris: I have to retire as a Taverna mentor. That said - what's stopping
Taverna from being ready to graduate? If it's just mentor activity then consider
I think generally if you see consistently a x.y.z versioning scheme - at
least in Java Maven projects, you can assume some kind of Semantic
Versioning compliance and moan back at the project if it isn't :). But as
usual, the devil is in the details.
We are exposing Jackson classes in the API of
Thank you for the pull request! Agree that this should be updated to avoid
the potential deserialization remote code attack vulnerability.
I think we should specify the commons collection version as
${commons.collections.version} so this is fixed across the Taverna
repositories.
No, I don't think we expose the Commons Collection types in any of our
APIs, so it should be easier to upgrade.
On 9 Mar 2016 20:02, "Gale Naylor" wrote:
> Doesn't this pull request to Upgrade Apache Commons Collections to v3.2.2
> also
> affect Scufl2 API?
>
>