[jira] [Resolved] (INCUBATOR-238) Milagro has updated milagro.xml

[ https://issues.apache.org/jira/browse/INCUBATOR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Fisher resolved INCUBATOR-238. --- Resolution: Fixed The project xml files are processed and staged into git once a day from

Re: [DISCUSS] check LICENSE and NOTICE for Apache Tuweni

OK, I inlined the MIT license texts from the various dependencies. Does this look better? The CC0 dependencies are public domain. Do you have an example of dealing with public domain dependencies? > On Jun 2, 2019, at 3:15 PM, Justin Mclean wrote: > > Hi, > > When use the short form of

[jira] [Created] (INCUBATOR-238) Milagro has updated milagro.xml

Brian Spector created INCUBATOR-238: --- Summary: Milagro has updated milagro.xml Key: INCUBATOR-238 URL: https://issues.apache.org/jira/browse/INCUBATOR-238 Project: Incubator Issue Type:

Re: [VOTE] Apache Tuweni (incubating) 0.7.0

Thanks. I did some research and removed the gradle wrapper just now. > On Jun 2, 2019, at 3:20 PM, Justin Mclean wrote: > > Hi, > >>> The two archives in the source release make sense as exceptions. A >>> rewritten README.md would explain the gradle wrapper. > > One does as it contains no

Re: [VOTE] Apache Tuweni (incubating) 0.7.0

Hi, >> The two archives in the source release make sense as exceptions. A rewritten >> README.md would explain the gradle wrapper. One does as it contains no code, but the gradle wrapper is not allowed. This has been discussed before on this list, and also see [1] which suggests a way around

Re: [DISCUSS] check LICENSE and NOTICE for Apache Tuweni

Hi, When use the short form of including a LICNSE, you need to include a link to the file containing license text not a URL. Some projects make a licenses directory and put the licenses in that. MIT requires you include the full text of the license and a URL doesn’t quite cover that. There’s

Re: Podling releases and release policy

Hi, > That is demonstrably not true, as (historically) the Incubator has made > releases with GPL'd code in them (eg. Hibernate). I assume you mean a dependancy on? I can think of 2 occasions this has occurred, both times permission of VP legal was required. Thanks, Justin

[DISCUSS] check LICENSE and NOTICE for Apache Tuweni

Folks, Would you please kindly review the NOTICE [0] and LICENSE [1] files for Apache Tuweni? Feedback is very welcome. Thanks, Antoine [0]:https://github.com/apache/incubator-tuweni/blob/master/LICENSE

Re: [VOTE] Apache Tuweni (incubating) 0.7.0

Thanks for the review. I originally replied on the private list. I’ll reply again here: > On May 31, 2019, at 12:37 PM, Dave Fisher wrote: > > Apologies for the delay. > > -1 (binding) > > Policy violations: > The missing DISCLAIMER in the source release is a blocker. > Please move

Re: [VOTE] Apache Tuweni (incubating) 0.7.0

OK thanks for the review. I have applied some of the fixes here: https://github.com/apache/incubator-tuweni/commit/fa12f390165559a4afaf522c02672adbcd9dfb67 I’ll open another thread to discuss. > On

Re: Podling releases and release policy

On Sun, Jun 2, 2019 at 1:22 PM Hen wrote: >... > * Incubating releases are Apache releases. > That is demonstrably not true, as (historically) the Incubator has made releases with GPL'd code in them (eg. Hibernate). Cheers, -g

Re: Podling releases and release policy

Wrote a long thing... decided it wasn't useful :) The tldr; * Incubating releases are Apache releases. No user cares if they are endorsed or official (for whatever they may mean). Perhaps if we said GA we might be clearer. * We end up having an argument about easiness of release vs

Re: [VOTE] Apache Tuweni (incubating) 0.7.0

OK, the vote is now closed. The vote does not pass with 2 -1 votes from Dave Fisher and Justin Mclean. Thank you all for your feedback. I will take you up on the offer of helping draw the release. > On May 31, 2019, at 10:01 PM, Justin Mclean wrote: > > Hi, > >> This class is not GPL. It

Re: Podling releases and release policy

I think the fact that incubating releases are not official ASF releases covers this issue.  The full effect of the shield is more a risk for the programmers in the limbo state of incubating from my perspective. On 6/1/2019 11:27 PM, Justin Mclean wrote: > Hi, > > The other though that occurred to

[ANNOUNCE] Apache Zipkin Dependencies (Incubating) version 2.2.0 Released

Hello Community, The Apache Zipkin (incubating) team is pleased to announce that Zipkin Dependencies 2.2.0 has just been released. Apache Zipkin Dependencies (incubating) collects spans from storage, analyzes links between services, and stores them for later presentation in the web UI. This

Re: [VOTE] [RESULT] Release Apache Zipkin Reporter (incubating) version 2.8.3

Thanks to everyone that participated. The vote to release Release Apache Zipkin Reporter (incubating) version 2.8.3 is now closed. It PASSED with 3 (+1 binding) votes and no 0 or -1 votes: +1 Andriy Redko (binding) +1 Willem Ning Jiang (binding) +1 Sheng Wu (binding) Vote thread:

Re: [VOTE] Release Apache Zipkin Reporter (incubating) version 2.8.3

My +1 binding. 1. Sha512 checked 2. Acs checked 3. Compile and tests passed 4. Rat checked. 5. Incubating exists in zip, asc, sha512 names 6. LICENSE, NOTICE and DISCLAIMER exist. Sheng Wu Apache Skywalking, ShardingSphere, Zipkin > 在 2019年5月28日，上午12:56，Jorge Quilcate 写道： > > Hello All, >

Re: Is the DEPENDENCIES file a requirement or a nice-to-have?

Thanks, Justin. Crystal clear! On Sun, Jun 2, 2019 at 3:58 PM Justin Mclean wrote: > > Hi, > > > Can someone clarify if packaging a file named DEPENDENCIES is required > > or a nice-to-have? > > It’s a nice to have. You’re releases do need to have no Category X licence > (e.g. GPL)

Re: Is the DEPENDENCIES file a requirement or a nice-to-have?

Hi, > Can someone clarify if packaging a file named DEPENDENCIES is required > or a nice-to-have? It’s a nice to have. You’re releases do need to have no Category X licence (e.g. GPL) dependancies. Thanks, Justin - To

Is the DEPENDENCIES file a requirement or a nice-to-have?

Hi, all. We tripped on some bugs related to maven projects generating the file DEPENDENCIES which includes information about runtime dependencies. We marked this as a graduation blocker assuming that is required. Later, we noticed a certain lack of clarity on how to handle this for javascript..

Re: Podling releases and release policy

Hi, > I was providing the converse: has the IPMC been told *not* to make podling > releases? For ones that don’t comply with release policy? Yes they have. > I'm stipulating that "podling release" != "Foundation release", so > different policies apply. That’s the first time I’ve head it put