Re: Redirecting pagespeed.incubator.apache.org to modpagespeed.com

[Julian Hyde]

I (as a Druid mentor) suggested the placeholder page, for the exact reasons 
Greg describes. Short term, I promise, and better than a 404. 

Julian

> On Apr 13, 2018, at 20:15, Greg Stein  wrote:
> 
> One step at a time. If they want to throw a single page up *today* rather
> than wait six weeks to fully port their website... I would take the page.
> We already had an inquiry on Druid of where their site is.
> 
> A placeholder is better than a 404. Unless, of course, you are personally
> volunteering to quickly move their entire site and workflow... ?
> 
> Cheers,
> -g
> 
> 
>> On Fri, Apr 13, 2018, 22:03 John D. Ament  wrote:
>> 
>> Gian, Otto,
>> 
>> I can tell you that the proposed plan from Druid is not an OK plan from my
>> perspective.  One of your short term goals should be moving infrastructure
>> over to the ASF.  This includes moving your website over.  Redirecting your
>> ASF webpage to your old webpage will not fly.
>> 
>> While we can't give the same level of support as you would see on github
>> pages (maybe we'll get there one day), setting up builds in Jenkins or
>> Buildbot is pretty straight forward.  Even the incubator website runs in
>> this model.
>> 
>> It's perfectly acceptable to link to pre-Apache releases on your website.
>> I'm not sure if any of the docs lead you to believe otherwise, but this is
>> a fine thing to do.  They just need to be clearly marked as not Apache
>> releases.
>> 
>> The disclaimer that we request is meant to be shown on all pages of the
>> podling's website.  Not just the landing page.  If these are user facing
>> documents, then they must have the disclaimer on them.
>> 
>> John
>> 
>>> On Fri, Apr 13, 2018 at 5:42 PM Gian Merlino  wrote:
>>> 
>>> Hi Otto,
>>> 
>>> I am just another podling committer, so this isn't authoritative advice,
>>> but for Druid's incubating page we are planning to put up a placeholder
>>> page with a link to the current community site. It isn't up yet, but the
>>> html we are planning to use is here:
>>> 
>> https://github.com/apache/incubator-druid-website/blob/asf-site/index.html
>>> 
>>> Our rationale was:
>>> 
>>> 1) Before the site is migrated, it's better to have a placeholder than a
>>> 404.
>>> 2) A placeholder with a link can make it more clear that the releases on
>>> druid.io are not Apache releases.
>>> 3) A placeholder helps satisfy the requirement that podling web sites
>> must
>>> have an incubation disclaimer (
>>> https://incubator.apache.org/guides/branding.html).
>>> 
>>> When we migrate the community site to Apache infra then it would replace
>>> the placeholder.
>>> 
>>> Gian
>>> 
>>> On Fri, Apr 13, 2018 at 2:09 PM, Otto van der Schaaf >> 
>>> wrote:
>>> 
 Hi all,
 
 Currently pagespeed.incubator.apache.org responds with a 404, which
>>> isn't
 very nice.
 
 So now we are wondering if there are any concerns with issueing a
>>> temporary
 redirect to
 modpagespeed.com.
 
 One concern could be that modpagespeed.com links to code / releases
>> that
 have not yet been
 through the formal Apache release process. Would explicitly mentioning
>>> that
 fact
 be sufficient to address it?
 
 I would be grateful for any input / guidance on this topic.
 
 Kind regards,
 
 Otto
 
>>> 
>> 

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

Re: Redirecting pagespeed.incubator.apache.org to modpagespeed.com

[Greg Stein]

One step at a time. If they want to throw a single page up *today* rather
than wait six weeks to fully port their website... I would take the page.
We already had an inquiry on Druid of where their site is.

A placeholder is better than a 404. Unless, of course, you are personally
volunteering to quickly move their entire site and workflow... ?

Cheers,
-g


On Fri, Apr 13, 2018, 22:03 John D. Ament  wrote:

> Gian, Otto,
>
> I can tell you that the proposed plan from Druid is not an OK plan from my
> perspective.  One of your short term goals should be moving infrastructure
> over to the ASF.  This includes moving your website over.  Redirecting your
> ASF webpage to your old webpage will not fly.
>
> While we can't give the same level of support as you would see on github
> pages (maybe we'll get there one day), setting up builds in Jenkins or
> Buildbot is pretty straight forward.  Even the incubator website runs in
> this model.
>
> It's perfectly acceptable to link to pre-Apache releases on your website.
> I'm not sure if any of the docs lead you to believe otherwise, but this is
> a fine thing to do.  They just need to be clearly marked as not Apache
> releases.
>
> The disclaimer that we request is meant to be shown on all pages of the
> podling's website.  Not just the landing page.  If these are user facing
> documents, then they must have the disclaimer on them.
>
> John
>
> On Fri, Apr 13, 2018 at 5:42 PM Gian Merlino  wrote:
>
> > Hi Otto,
> >
> > I am just another podling committer, so this isn't authoritative advice,
> > but for Druid's incubating page we are planning to put up a placeholder
> > page with a link to the current community site. It isn't up yet, but the
> > html we are planning to use is here:
> >
> https://github.com/apache/incubator-druid-website/blob/asf-site/index.html
> >
> > Our rationale was:
> >
> > 1) Before the site is migrated, it's better to have a placeholder than a
> > 404.
> > 2) A placeholder with a link can make it more clear that the releases on
> > druid.io are not Apache releases.
> > 3) A placeholder helps satisfy the requirement that podling web sites
> must
> > have an incubation disclaimer (
> > https://incubator.apache.org/guides/branding.html).
> >
> > When we migrate the community site to Apache infra then it would replace
> > the placeholder.
> >
> > Gian
> >
> > On Fri, Apr 13, 2018 at 2:09 PM, Otto van der Schaaf  >
> > wrote:
> >
> > > Hi all,
> > >
> > > Currently pagespeed.incubator.apache.org responds with a 404, which
> > isn't
> > > very nice.
> > >
> > > So now we are wondering if there are any concerns with issueing a
> > temporary
> > > redirect to
> > > modpagespeed.com.
> > >
> > > One concern could be that modpagespeed.com links to code / releases
> that
> > > have not yet been
> > > through the formal Apache release process. Would explicitly mentioning
> > that
> > > fact
> > > be sufficient to address it?
> > >
> > > I would be grateful for any input / guidance on this topic.
> > >
> > > Kind regards,
> > >
> > > Otto
> > >
> >
>

Re: Redirecting pagespeed.incubator.apache.org to modpagespeed.com

[John D. Ament]

Gian, Otto,

I can tell you that the proposed plan from Druid is not an OK plan from my
perspective.  One of your short term goals should be moving infrastructure
over to the ASF.  This includes moving your website over.  Redirecting your
ASF webpage to your old webpage will not fly.

While we can't give the same level of support as you would see on github
pages (maybe we'll get there one day), setting up builds in Jenkins or
Buildbot is pretty straight forward.  Even the incubator website runs in
this model.

It's perfectly acceptable to link to pre-Apache releases on your website.
I'm not sure if any of the docs lead you to believe otherwise, but this is
a fine thing to do.  They just need to be clearly marked as not Apache
releases.

The disclaimer that we request is meant to be shown on all pages of the
podling's website.  Not just the landing page.  If these are user facing
documents, then they must have the disclaimer on them.

John

On Fri, Apr 13, 2018 at 5:42 PM Gian Merlino  wrote:

> Hi Otto,
>
> I am just another podling committer, so this isn't authoritative advice,
> but for Druid's incubating page we are planning to put up a placeholder
> page with a link to the current community site. It isn't up yet, but the
> html we are planning to use is here:
> https://github.com/apache/incubator-druid-website/blob/asf-site/index.html
>
> Our rationale was:
>
> 1) Before the site is migrated, it's better to have a placeholder than a
> 404.
> 2) A placeholder with a link can make it more clear that the releases on
> druid.io are not Apache releases.
> 3) A placeholder helps satisfy the requirement that podling web sites must
> have an incubation disclaimer (
> https://incubator.apache.org/guides/branding.html).
>
> When we migrate the community site to Apache infra then it would replace
> the placeholder.
>
> Gian
>
> On Fri, Apr 13, 2018 at 2:09 PM, Otto van der Schaaf 
> wrote:
>
> > Hi all,
> >
> > Currently pagespeed.incubator.apache.org responds with a 404, which
> isn't
> > very nice.
> >
> > So now we are wondering if there are any concerns with issueing a
> temporary
> > redirect to
> > modpagespeed.com.
> >
> > One concern could be that modpagespeed.com links to code / releases that
> > have not yet been
> > through the formal Apache release process. Would explicitly mentioning
> that
> > fact
> > be sufficient to address it?
> >
> > I would be grateful for any input / guidance on this topic.
> >
> > Kind regards,
> >
> > Otto
> >
>

Re: [VOTE] Apache Toree 0.2.0-incubating (RC4)

[Matt Sicker]

I'm just running "make test" as well. I redownloaded it just now and am
still getting the same issue. Here's some more info:

[info] AddExternalJarMagicSpecForIntegration:
[info] ScalaInterpreter
[info]   #addJars
[info]   - should do something (1 second, 55 milliseconds)
[info]   - should be able to load Java jars *** FAILED *** (2 seconds, 378
milliseconds)
[info] "[]" was not equal to "[Hello, Chip
[info] ]" (AddExternalJarMagicSpecForIntegration.scala:84)
[info] org.scalatest.exceptions.TestFailedException:
[info] at
org.scalatest.MatchersHelper$.newTestFailedException(MatchersHelper.scala:160)
[info] at
org.scalatest.Matchers$ShouldMethodHelper$.shouldMatcher(Matchers.scala:6254)
[info] at
org.scalatest.Matchers$AnyShouldWrapper.should(Matchers.scala:6288)
[info] at
integration.interpreter.scala.AddExternalJarMagicSpecForIntegration$$anonfun$3$$anonfun$apply$mcV$sp$1$$anonfun$apply$mcV$sp$3.apply$mcV$sp(AddExternalJarMagicSpecForIntegration.scala:84)
[info] at
integration.interpreter.scala.AddExternalJarMagicSpecForIntegration$$anonfun$3$$anonfun$apply$mcV$sp$1$$anonfun$apply$mcV$sp$3.apply(AddExternalJarMagicSpecForIntegration.scala:65)
[info] at
integration.interpreter.scala.AddExternalJarMagicSpecForIntegration$$anonfun$3$$anonfun$apply$mcV$sp$1$$anonfun$apply$mcV$sp$3.apply(AddExternalJarMagicSpecForIntegration.scala:65)
[info] at
org.scalatest.Transformer$$anonfun$apply$1.apply$mcV$sp(Transformer.scala:22)
[info] at org.scalatest.OutcomeOf$class.outcomeOf(OutcomeOf.scala:85)
[info] at org.scalatest.OutcomeOf$.outcomeOf(OutcomeOf.scala:104)
[info] at org.scalatest.Transformer.apply(Transformer.scala:22)
[info] at org.scalatest.Transformer.apply(Transformer.scala:20)
[info] at org.scalatest.FunSpecLike$$anon$1.apply(FunSpecLike.scala:422)
[info] at org.scalatest.Suite$class.withFixture(Suite.scala:1122)
[info] at org.scalatest.FunSpec.withFixture(FunSpec.scala:1626)
[info] at
org.scalatest.FunSpecLike$class.invokeWithFixture$1(FunSpecLike.scala:419)
[info] at
org.scalatest.FunSpecLike$$anonfun$runTest$1.apply(FunSpecLike.scala:431)
[info] at
org.scalatest.FunSpecLike$$anonfun$runTest$1.apply(FunSpecLike.scala:431)
[info] at org.scalatest.SuperEngine.runTestImpl(Engine.scala:306)
[info] at org.scalatest.FunSpecLike$class.runTest(FunSpecLike.scala:431)
[info] at
integration.interpreter.scala.AddExternalJarMagicSpecForIntegration.org
$scalatest$BeforeAndAfter$$super$runTest(AddExternalJarMagicSpecForIntegration.scala:33)
[info] at
org.scalatest.BeforeAndAfter$class.runTest(BeforeAndAfter.scala:200)
[info] at
integration.interpreter.scala.AddExternalJarMagicSpecForIntegration.runTest(AddExternalJarMagicSpecForIntegration.scala:33)
[info] at
org.scalatest.FunSpecLike$$anonfun$runTests$1.apply(FunSpecLike.scala:464)
[info] at
org.scalatest.FunSpecLike$$anonfun$runTests$1.apply(FunSpecLike.scala:464)
[info] at
org.scalatest.SuperEngine$$anonfun$traverseSubNodes$1$1.apply(Engine.scala:413)
[info] at
org.scalatest.SuperEngine$$anonfun$traverseSubNodes$1$1.apply(Engine.scala:401)
[info] at scala.collection.immutable.List.foreach(List.scala:381)
[info] at org.scalatest.SuperEngine.traverseSubNodes$1(Engine.scala:401)
[info] at org.scalatest.SuperEngine.org
$scalatest$SuperEngine$$runTestsInBranch(Engine.scala:390)
[info] at
org.scalatest.SuperEngine$$anonfun$traverseSubNodes$1$1.apply(Engine.scala:427)
[info] at
org.scalatest.SuperEngine$$anonfun$traverseSubNodes$1$1.apply(Engine.scala:401)
[info] at scala.collection.immutable.List.foreach(List.scala:381)
[info] at org.scalatest.SuperEngine.traverseSubNodes$1(Engine.scala:401)
[info] at org.scalatest.SuperEngine.org
$scalatest$SuperEngine$$runTestsInBranch(Engine.scala:390)
[info] at
org.scalatest.SuperEngine$$anonfun$traverseSubNodes$1$1.apply(Engine.scala:427)
[info] at
org.scalatest.SuperEngine$$anonfun$traverseSubNodes$1$1.apply(Engine.scala:401)
[info] at scala.collection.immutable.List.foreach(List.scala:381)
[info] at org.scalatest.SuperEngine.traverseSubNodes$1(Engine.scala:401)
[info] at org.scalatest.SuperEngine.org
$scalatest$SuperEngine$$runTestsInBranch(Engine.scala:396)
[info] at org.scalatest.SuperEngine.runTestsImpl(Engine.scala:483)
[info] at
org.scalatest.FunSpecLike$class.runTests(FunSpecLike.scala:464)
[info] at org.scalatest.FunSpec.runTests(FunSpec.scala:1626)
[info] at org.scalatest.Suite$class.run(Suite.scala:1424)
[info] at org.scalatest.FunSpec.org
$scalatest$FunSpecLike$$super$run(FunSpec.scala:1626)
[info] at
org.scalatest.FunSpecLike$$anonfun$run$1.apply(FunSpecLike.scala:468)
[info] at
org.scalatest.FunSpecLike$$anonfun$run$1.apply(FunSpecLike.scala:468)
[info] at org.scalatest.SuperEngine.runImpl(Engine.scala:545)
[info] at org.scalatest.FunSpecLike$class.run(FunSpecLike.scala:468)
[info] at

Re: Milagro Rescue Roadmap

[Nick Kew]

On Thu, 12 Apr 2018 16:35:25 +0100
Nick Kew  wrote:

> Posting to both dev@milagro and general@incubator.

> Would folks be happy for me to set up a page for this purpose
> under wiki/incubator?  I would propose a skeleton (mainly a
> set of headings) and look to the community to flesh it out.
> 

OK, I've created a skeleton
https://wiki.apache.org/incubator/MilagroRescueRoadmap

With a list of headings based on my understanding of
the situation.  I hope others will review and improve
my list, clarify the issues listed, and fill in the
big blanks.  If this can grow to a credible roadmap by
the end of April, I think we have the basis of a rescue!

Direct edits to the wiki are great.  If unsure about an
idea, either add it there as tentative, or discuss on-list.
Or of course both!

-- 
Nick Kew

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

Re: Redirecting pagespeed.incubator.apache.org to modpagespeed.com

[Gian Merlino]

Hi Otto,

I am just another podling committer, so this isn't authoritative advice,
but for Druid's incubating page we are planning to put up a placeholder
page with a link to the current community site. It isn't up yet, but the
html we are planning to use is here:
https://github.com/apache/incubator-druid-website/blob/asf-site/index.html

Our rationale was:

1) Before the site is migrated, it's better to have a placeholder than a
404.
2) A placeholder with a link can make it more clear that the releases on
druid.io are not Apache releases.
3) A placeholder helps satisfy the requirement that podling web sites must
have an incubation disclaimer (
https://incubator.apache.org/guides/branding.html).

When we migrate the community site to Apache infra then it would replace
the placeholder.

Gian

On Fri, Apr 13, 2018 at 2:09 PM, Otto van der Schaaf 
wrote:

> Hi all,
>
> Currently pagespeed.incubator.apache.org responds with a 404, which isn't
> very nice.
>
> So now we are wondering if there are any concerns with issueing a temporary
> redirect to
> modpagespeed.com.
>
> One concern could be that modpagespeed.com links to code / releases that
> have not yet been
> through the formal Apache release process. Would explicitly mentioning that
> fact
> be sufficient to address it?
>
> I would be grateful for any input / guidance on this topic.
>
> Kind regards,
>
> Otto
>

Redirecting pagespeed.incubator.apache.org to modpagespeed.com

[Otto van der Schaaf]

Hi all,

Currently pagespeed.incubator.apache.org responds with a 404, which isn't
very nice.

So now we are wondering if there are any concerns with issueing a temporary
redirect to
modpagespeed.com.

One concern could be that modpagespeed.com links to code / releases that
have not yet been
through the formal Apache release process. Would explicitly mentioning that
fact
be sufficient to address it?

I would be grateful for any input / guidance on this topic.

Kind regards,

Otto

Re: [VOTE] Apache Toree 0.2.0-incubating (RC4)

[Ryan Blue]

How did you run tests? It worked fine from source for me with `make test`

On Fri, Apr 13, 2018 at 1:12 PM, Matt Sicker  wrote:

> I built it from the source tar.gz.
>
> On 13 April 2018 at 14:05, Luciano Resende  wrote:
>
> > On Wed, Apr 11, 2018 at 9:44 AM, Matt Sicker  wrote:
> >
> > > * Signatures ok
> > > * License and disclaimer are fine
> > > * Notice included, but the copyright year needs to be updated to
> > 2016-2018
> > > * Rat check ok 
> > > * I got a test failure locally for
> > > integration.interpreter.scala.AddExternalJarMagicSpecForIntegration
> > > "should
> > > be able to load Java jars".
> > >
> > >
> > Sory for the delay replying, I finally got time to give this a try, and I
> > build from a clean
> > source distribution a few times successfully. I am trying this on a mac
> os
> > environment,
> > could you please describe your env, and if it works on a second run (note
> > that this is
> > probably the one test that validates adding something from external
> source
> > so a download
> > is involved and internet connectivity might play a part here)
> >
> > Thanks
> >
> > --
> > Luciano Resende
> > http://twitter.com/lresende1975
> > http://lresende.blogspot.com/
> >
>
>
>
> --
> Matt Sicker 
>



-- 
Ryan Blue
Software Engineer
Netflix

Re: [VOTE] Apache Toree 0.2.0-incubating (RC4)

[Matt Sicker]

I built it from the source tar.gz.

On 13 April 2018 at 14:05, Luciano Resende  wrote:

> On Wed, Apr 11, 2018 at 9:44 AM, Matt Sicker  wrote:
>
> > * Signatures ok
> > * License and disclaimer are fine
> > * Notice included, but the copyright year needs to be updated to
> 2016-2018
> > * Rat check ok 
> > * I got a test failure locally for
> > integration.interpreter.scala.AddExternalJarMagicSpecForIntegration
> > "should
> > be able to load Java jars".
> >
> >
> Sory for the delay replying, I finally got time to give this a try, and I
> build from a clean
> source distribution a few times successfully. I am trying this on a mac os
> environment,
> could you please describe your env, and if it works on a second run (note
> that this is
> probably the one test that validates adding something from external source
> so a download
> is involved and internet connectivity might play a part here)
>
> Thanks
>
> --
> Luciano Resende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>



-- 
Matt Sicker 

Re: [VOTE] Apache Toree 0.2.0-incubating (RC4)

[Luciano Resende]

On Wed, Apr 11, 2018 at 9:44 AM, Matt Sicker  wrote:

> * Signatures ok
> * License and disclaimer are fine
> * Notice included, but the copyright year needs to be updated to 2016-2018
> * Rat check ok 
> * I got a test failure locally for
> integration.interpreter.scala.AddExternalJarMagicSpecForIntegration
> "should
> be able to load Java jars".
>
>
Sory for the delay replying, I finally got time to give this a try, and I
build from a clean
source distribution a few times successfully. I am trying this on a mac os
environment,
could you please describe your env, and if it works on a second run (note
that this is
probably the one test that validates adding something from external source
so a download
is involved and internet connectivity might play a part here)

Thanks

-- 
Luciano Resende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: [VOTE] Release of Apache Griffin-0.2.0-incubating [RC3]

[Matt Sicker]

On 13 April 2018 at 03:37, Willem Jiang  wrote:

> Hi Matt,
>
> I just have different idea about your your explanation.
>
> If my code has the compile dependency of the JSON library,  as the JSON
> library code is not bundled in the source code.
> I don't think we should add the License of JSON library into my License
> file.
>

Right. The source license file only applies to the source code that you
directly include in the distribution artifact. Hence why the binaries here
have a different license because they embed several 3rd party dependencies
with different licenses or notices to include. Some licenses have different
rules regarding source distribution versus binary distribution (these
generally revolve around where and how to attribute the copyright holders).


> If we use the LGPL license jar library in the test.
> As this LGPL jar is not bundled in our source or binary release. we don't
> need to update our License and Notice file for it.
>

That's my understanding. Essentially, any components that depend on LGPL
code or similar need to be optional.

As for license categories (which is relevant to this discussion in
general), category A are all good for source and binary distribution,
category B licenses can generally be used in binary distributions but not
source distributions, and category X licenses cannot be included in source
or binary distributions. Category X licensed software can be used in
limited cases, but it can't be required for using the software. For
example, maybe you have a component that integrates with some GPL component
upstream. Provided you were legally able to write your component under ALv2
in the first place, then said component could be distributed as an optional
component with instructions on installing the third party software. <
https://www.apache.org/legal/resolved.html#optional>


-- 
Matt Sicker 

Re: [VOTE] Release Apache Omid 0.9.0.0 (incubating)

[Matt Sicker]

The protobuf issue I was able to fix locally by installing protobuf@2.6
(homebrew) and modifying my PATH for the build command. I still had failing
tests, though.

On 12 April 2018 at 19:23, Justin Mclean  wrote:

> Hi,
>
> -1 binding as NOTICE is incorrect. The NOTICE file need to be keep as
> small as possible [1]
>
> I checked:
> - incubating in file name
> - signatures good although it would be best to sign with an apache.org
> email address
> - LICENSE is fine
> - NOTICE file contains wrong year (2016) and incorrectly lists files that
> have 3rd party ALv2 headers. Where did these files come from? It looks like
> here [4] which has a NOTICE file [4]
> - a couple of files are missing ASF headers [2][3]
> - no unexpected binary files
> - Can't compile from source. Looks like I have a newer version of
> protobuf. May be an issue for other people as well?
>
> Not 100% certain but I think that the NOTICE file [5] needs to be taken
> into account, however it may be that the version of the files you have were
> taken when no NOTICE files existed? (It was committed in 2014? and the
> copyright is 2010 on those files.)
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/dev/licensing-howto.html#mod-notice
> 2. apache-omid-incubating-0.9.0.0-src/tso-server/src/main/
> resources/default-omid-server-configuration.yml
> 3. apache-omid-incubating-0.9.0.0-src/benchmarks/src/main/
> resources/default-tso-server-benchmark-config.yml
> 4.https://github.com/linkedin/MTBT/
> 5. https://github.com/linkedin/MTBT/blob/master/NOTICE
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Matt Sicker 

[jira] [Commented] (INCUBATOR-211) ECharts todo list of next release

[Ovilia (JIRA)]

[ 
https://issues.apache.org/jira/browse/INCUBATOR-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437318#comment-16437318
 ] 

Ovilia commented on INCUBATOR-211:
--

[~njiang] Thanks Wilem, I will check it out.

> ECharts todo list of next release
> -
>
> Key: INCUBATOR-211
> URL: https://issues.apache.org/jira/browse/INCUBATOR-211
> Project: Incubator
>  Issue Type: Task
>Reporter: Ovilia
>Priority: Major
>
> We are about to release ECharts 4.1.0 next week, hopefully on Tuesday or 
> Wednesday.
> We will list new features or bugs to be fixed of next release everytime after 
> we issue a new release. But since we just joined ASF and our last release was 
> on 28th Feb, there are many issues we've already fixed since then. We are 
> sorry about it, and from next release, we will discuss todo list before we 
> actually get started to do them.
>  
>  # Enhance: optimize candlestick rendering and zooming in hundreds of 
> thousand of data.
>  # Enhance: enhance the category axis ticks and labels when there was no 
> enough space to display all labels.
>  ## Make the animation appropriate for label, ticks, splitLine, splitArea 
> when view window moving (by dataZoom) in category axis.
>  ## Category axis tick and label was not corresponding to each other.
>  ## Make the choose of ticks and labels stable when view window moving (by 
> dataZoom) in category axis.
>  # Enhance: order of nodes for sankey diagram. #3390 #3543 #6365 #4880 #4986
>  # Feature: Add zoom and drag interactions for tree diagram.
>  # Fix: SVG axisPointer text position bug #7947
>  # Enhance: performance of bar chart in hundreds of thousand of data. (done)
>  # Enhance: sampling performance in progressive mode. (done)
>  # Enhance: parallel performance in progressive mode. (done)
>  # Fix: large lines chart render bug in large mode. (done)
>  # Fix: The last day of a month was not displayed in calendar #8045. (done)
>  # Fix: dataSample caused incorrect extent when data is NaN. (done)
>  # Fix: data sample worked abnormally when using `series.encode`. #8017 (done)
>  # Fix: `legendHoverLink: false` did not work appropriately when multiple 
> series have the same name. #8010 (done)
>  # Fix: Some of the graph hover style did not work. (done)
>  # Enhance: currently do not filter empty data item in data zoom, which makes 
> line chart keeping broken. #7955 (done)
>  # Enhance: support toolbox.feature merge. (done)
>  # Fix: currently we fetch name from dateItem.name firstly in list. #7966 
> (done)
>  # Fix: typed array incorrect usage in WeChat app. (done)
>  # Fix: option in axis data item did not work. #7954 (done)
>  # Fix: markArea only displayed the last one. #7902 (done)
>  # Fix: rounding error in clip symbol for line chart. #7913 (done)
>  # Fix: bar chart start point was incorrect when multiple axes exist. #7412 
> (done)
>  # Fix: markArea did not display when using ordinal string. #7849 (done)
>  # Fix: dataZoom threw error when series was empty. #7666 (done)
>  # Enhance: add tree directions from right to left, from bottom to top for 
> tree series. #7351 #7154 (done)
>  ## The corresponding values of the configuration 'orient' are 'RL' and 'BT'.
>  # Fix: resolve browser become unresponsive when the data of sankey series 
> has cycle. #7495 #8117 #7583 #7325 #6555 (done)
>  # Fix: add compatibility of data exceptions for sankey series. #2867 (done)
>  # Fix: error when remove node or render again for the tree series. #8038 
> #8040 #7720 #7363 # 7315 (done)
>  # Fix: sunburst chart roll-up element is not removed when chart.setOption 
> called. #8132 (done)
>  ## A roll-up element is for going back from drilling down in sunburst charts.
>  # Feature: support keeping-aspect for legend path. #7831 (done)
>  ## Path defined in legend was not keeping aspect, but fitting the aspect of 
> default legend size, which is not ideal for most path shapes.
>  
> Please send some feedback about them. Thanks!
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: Are MySQL driver and MySQL protocol allowed in distribution?

[sebb]

On 13 April 2018 at 11:26, Karl Wright  wrote:
> You can't distribute the MySQL driver, but as long as you don't distribute
> the driver, you are free to solve the problem any way you like.  You can
> require that the user download the driver themselves, or you can develop
> your own driver -- all of those are fine.

This is the policy that I think applies here:

http://www.apache.org/legal/resolved.html#optional

Does the product work without MySQL?
It sounds like that this would be an optional storage method, so
depending on it would be fine.

The uses who want to use MySQL will have to download the driver (and
accept the terms of its license).
Those that don't wish to use MySQL aren't affected.

> Karl
>
>
> On Fri, Apr 13, 2018 at 6:20 AM, 吴晟 Sheng Wu  wrote:
>
>> Hi,
>> Someone asked whether could provide a mysql based storage implemention for
>> SKyWalking.
>> I am aware mysql driver is under GPL, so should not be allowed, right?
>> Then how about the mysql protocol? If they implement the codes by
>> themself, because the storage required a few features compared to the real
>> driver.
>>
>>
>> Thanks
>> Sheng Wu

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

[jira] [Closed] (INCUBATOR-211) ECharts todo list of next release

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/INCUBATOR-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament closed INCUBATOR-211.
---
Resolution: Fixed

Not for this project, working with podling on dev list.

> ECharts todo list of next release
> -
>
> Key: INCUBATOR-211
> URL: https://issues.apache.org/jira/browse/INCUBATOR-211
> Project: Incubator
>  Issue Type: Task
>Reporter: Ovilia
>Priority: Major
>
> We are about to release ECharts 4.1.0 next week, hopefully on Tuesday or 
> Wednesday.
> We will list new features or bugs to be fixed of next release everytime after 
> we issue a new release. But since we just joined ASF and our last release was 
> on 28th Feb, there are many issues we've already fixed since then. We are 
> sorry about it, and from next release, we will discuss todo list before we 
> actually get started to do them.
>  
>  # Enhance: optimize candlestick rendering and zooming in hundreds of 
> thousand of data.
>  # Enhance: enhance the category axis ticks and labels when there was no 
> enough space to display all labels.
>  ## Make the animation appropriate for label, ticks, splitLine, splitArea 
> when view window moving (by dataZoom) in category axis.
>  ## Category axis tick and label was not corresponding to each other.
>  ## Make the choose of ticks and labels stable when view window moving (by 
> dataZoom) in category axis.
>  # Enhance: order of nodes for sankey diagram. #3390 #3543 #6365 #4880 #4986
>  # Feature: Add zoom and drag interactions for tree diagram.
>  # Fix: SVG axisPointer text position bug #7947
>  # Enhance: performance of bar chart in hundreds of thousand of data. (done)
>  # Enhance: sampling performance in progressive mode. (done)
>  # Enhance: parallel performance in progressive mode. (done)
>  # Fix: large lines chart render bug in large mode. (done)
>  # Fix: The last day of a month was not displayed in calendar #8045. (done)
>  # Fix: dataSample caused incorrect extent when data is NaN. (done)
>  # Fix: data sample worked abnormally when using `series.encode`. #8017 (done)
>  # Fix: `legendHoverLink: false` did not work appropriately when multiple 
> series have the same name. #8010 (done)
>  # Fix: Some of the graph hover style did not work. (done)
>  # Enhance: currently do not filter empty data item in data zoom, which makes 
> line chart keeping broken. #7955 (done)
>  # Enhance: support toolbox.feature merge. (done)
>  # Fix: currently we fetch name from dateItem.name firstly in list. #7966 
> (done)
>  # Fix: typed array incorrect usage in WeChat app. (done)
>  # Fix: option in axis data item did not work. #7954 (done)
>  # Fix: markArea only displayed the last one. #7902 (done)
>  # Fix: rounding error in clip symbol for line chart. #7913 (done)
>  # Fix: bar chart start point was incorrect when multiple axes exist. #7412 
> (done)
>  # Fix: markArea did not display when using ordinal string. #7849 (done)
>  # Fix: dataZoom threw error when series was empty. #7666 (done)
>  # Enhance: add tree directions from right to left, from bottom to top for 
> tree series. #7351 #7154 (done)
>  ## The corresponding values of the configuration 'orient' are 'RL' and 'BT'.
>  # Fix: resolve browser become unresponsive when the data of sankey series 
> has cycle. #7495 #8117 #7583 #7325 #6555 (done)
>  # Fix: add compatibility of data exceptions for sankey series. #2867 (done)
>  # Fix: error when remove node or render again for the tree series. #8038 
> #8040 #7720 #7363 # 7315 (done)
>  # Fix: sunburst chart roll-up element is not removed when chart.setOption 
> called. #8132 (done)
>  ## A roll-up element is for going back from drilling down in sunburst charts.
>  # Feature: support keeping-aspect for legend path. #7831 (done)
>  ## Path defined in legend was not keeping aspect, but fitting the aspect of 
> default legend size, which is not ideal for most path shapes.
>  
> Please send some feedback about them. Thanks!
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: Are MySQL driver and MySQL protocol allowed in distribution?

[???? Sheng Wu]

Kark
Thanks for helps.


Sheng Wu


 
---Original---
From: "Karl Wright"
Date: Fri, Apr 13, 2018 18:26 PM
To: "general";
Subject: Re: Are MySQL driver and MySQL protocol allowed in distribution?


You can't distribute the MySQL driver, but as long as you don't distribute
the driver, you are free to solve the problem any way you like.  You can
require that the user download the driver themselves, or you can develop
your own driver -- all of those are fine.

Karl


On Fri, Apr 13, 2018 at 6:20 AM,  Sheng Wu  wrote:

> Hi,
> Someone asked whether could provide a mysql based storage implemention for
> SKyWalking.
> I am aware mysql driver is under GPL, so should not be allowed, right?
> Then how about the mysql protocol? If they implement the codes by
> themself, because the storage required a few features compared to the real
> driver.
>
>
> Thanks
> Sheng Wu

Re: Are MySQL driver and MySQL protocol allowed in distribution?

[Karl Wright]

You can't distribute the MySQL driver, but as long as you don't distribute
the driver, you are free to solve the problem any way you like.  You can
require that the user download the driver themselves, or you can develop
your own driver -- all of those are fine.

Karl


On Fri, Apr 13, 2018 at 6:20 AM, 吴晟 Sheng Wu  wrote:

> Hi,
> Someone asked whether could provide a mysql based storage implemention for
> SKyWalking.
> I am aware mysql driver is under GPL, so should not be allowed, right?
> Then how about the mysql protocol? If they implement the codes by
> themself, because the storage required a few features compared to the real
> driver.
>
>
> Thanks
> Sheng Wu

Are MySQL driver and MySQL protocol allowed in distribution?

[???? Sheng Wu]

Hi,
Someone asked whether could provide a mysql based storage implemention for 
SKyWalking.
I am aware mysql driver is under GPL, so should not be allowed, right?
Then how about the mysql protocol? If they implement the codes by themself, 
because the storage required a few features compared to the real driver.


Thanks
Sheng Wu

[jira] [Commented] (INCUBATOR-211) ECharts todo list of next release

[Willem Jiang (JIRA)]

[ 
https://issues.apache.org/jira/browse/INCUBATOR-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437042#comment-16437042
 ] 

Willem Jiang commented on INCUBATOR-211:


[~Ovilia], incubator Jira is not supposed to get release relate candidate 
feedback. 

 Normally we start the release propose in the project mailing list, and start 
the release vote there. Once the release vote is passed, you can start the vote 
in the IPMC mailing list.  Please read [incubator 
releases|https://incubator.apache.org/policy/incubation.html#releases] document 
for more information.

As the IPMC vote main check for the License and NOTICE issues,  my suggestion 
is please go through the discussion of other project release vote mail to make 
sure you don't make the same mistake.

> ECharts todo list of next release
> -
>
> Key: INCUBATOR-211
> URL: https://issues.apache.org/jira/browse/INCUBATOR-211
> Project: Incubator
>  Issue Type: Task
>Reporter: Ovilia
>Priority: Major
>
> We are about to release ECharts 4.1.0 next week, hopefully on Tuesday or 
> Wednesday.
> We will list new features or bugs to be fixed of next release everytime after 
> we issue a new release. But since we just joined ASF and our last release was 
> on 28th Feb, there are many issues we've already fixed since then. We are 
> sorry about it, and from next release, we will discuss todo list before we 
> actually get started to do them.
>  
>  # Enhance: optimize candlestick rendering and zooming in hundreds of 
> thousand of data.
>  # Enhance: enhance the category axis ticks and labels when there was no 
> enough space to display all labels.
>  ## Make the animation appropriate for label, ticks, splitLine, splitArea 
> when view window moving (by dataZoom) in category axis.
>  ## Category axis tick and label was not corresponding to each other.
>  ## Make the choose of ticks and labels stable when view window moving (by 
> dataZoom) in category axis.
>  # Enhance: order of nodes for sankey diagram. #3390 #3543 #6365 #4880 #4986
>  # Feature: Add zoom and drag interactions for tree diagram.
>  # Fix: SVG axisPointer text position bug #7947
>  # Enhance: performance of bar chart in hundreds of thousand of data. (done)
>  # Enhance: sampling performance in progressive mode. (done)
>  # Enhance: parallel performance in progressive mode. (done)
>  # Fix: large lines chart render bug in large mode. (done)
>  # Fix: The last day of a month was not displayed in calendar #8045. (done)
>  # Fix: dataSample caused incorrect extent when data is NaN. (done)
>  # Fix: data sample worked abnormally when using `series.encode`. #8017 (done)
>  # Fix: `legendHoverLink: false` did not work appropriately when multiple 
> series have the same name. #8010 (done)
>  # Fix: Some of the graph hover style did not work. (done)
>  # Enhance: currently do not filter empty data item in data zoom, which makes 
> line chart keeping broken. #7955 (done)
>  # Enhance: support toolbox.feature merge. (done)
>  # Fix: currently we fetch name from dateItem.name firstly in list. #7966 
> (done)
>  # Fix: typed array incorrect usage in WeChat app. (done)
>  # Fix: option in axis data item did not work. #7954 (done)
>  # Fix: markArea only displayed the last one. #7902 (done)
>  # Fix: rounding error in clip symbol for line chart. #7913 (done)
>  # Fix: bar chart start point was incorrect when multiple axes exist. #7412 
> (done)
>  # Fix: markArea did not display when using ordinal string. #7849 (done)
>  # Fix: dataZoom threw error when series was empty. #7666 (done)
>  # Enhance: add tree directions from right to left, from bottom to top for 
> tree series. #7351 #7154 (done)
>  ## The corresponding values of the configuration 'orient' are 'RL' and 'BT'.
>  # Fix: resolve browser become unresponsive when the data of sankey series 
> has cycle. #7495 #8117 #7583 #7325 #6555 (done)
>  # Fix: add compatibility of data exceptions for sankey series. #2867 (done)
>  # Fix: error when remove node or render again for the tree series. #8038 
> #8040 #7720 #7363 # 7315 (done)
>  # Fix: sunburst chart roll-up element is not removed when chart.setOption 
> called. #8132 (done)
>  ## A roll-up element is for going back from drilling down in sunburst charts.
>  # Feature: support keeping-aspect for legend path. #7831 (done)
>  ## Path defined in legend was not keeping aspect, but fitting the aspect of 
> default legend size, which is not ideal for most path shapes.
>  
> Please send some feedback about them. Thanks!
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: [VOTE] Release of Apache Griffin-0.2.0-incubating [RC3]

[Willem Jiang]

Hi Matt,

I just have different idea about your your explanation.

If my code has the compile dependency of the JSON library,  as the JSON
library code is not bundled in the source code.
I don't think we should add the License of JSON library into my License
file.

If we use the LGPL license jar library in the test.
As this LGPL jar is not bundled in our source or binary release. we don't
need to update our License and Notice file for it.

Please correct me if I'm wrong about it.



Willem Jiang

Blog: http://willemjiang.blogspot.com (English)
  http://jnn.iteye.com  (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Apr 13, 2018 at 1:09 PM, Matt Sicker  wrote:

> On 12 April 2018 at 22:43, Lionel Liu  wrote:
> >
> > 2. Only things that are actually bundled in the release should be
> mentioned
> > in LICENSE. [3][4]
> >
> > To my understanding, as a source release, all the dependencies are
> bundled
> > when it is built.
> > The dependencies are not bundled in the source code, so we don't need to
> > announce any dependencies' licenses in source release?
> >
>
> The idea here is that the LICENSE file only needs to include licenses for
> anything that is included in that archive file. So for instance, if you
> have source files that are all developed at Apache and have dependencies
> that aren't included in the source zip, then you have the most simple
> distribution possible here. If you have source files that are licensed
> differently (e.g., copied code from an MIT licensed library), then things
> start to get complicated. As it is, your source license and notice should
> be relatively minimal right now since you're not bundling external
> dependencies in said source distribution.
>
> As for the JSON licensing issue, just take a look at the license. It says
> it can't be used for evil. While amusing, that's a terrible restriction to
> place on end users because it's extremely vague and violates the tenants of
> free software.
>
> --
> Matt Sicker 
>

[jira] [Created] (INCUBATOR-211) ECharts todo list of next release

[Ovilia (JIRA)]

Ovilia created INCUBATOR-211:


 Summary: ECharts todo list of next release
 Key: INCUBATOR-211
 URL: https://issues.apache.org/jira/browse/INCUBATOR-211
 Project: Incubator
  Issue Type: Task
Reporter: Ovilia


We are about to release ECharts 4.1.0 next week, hopefully on Tuesday or 
Wednesday.

We will list new features or bugs to be fixed of next release everytime after 
we issue a new release. But since we just joined ASF and our last release was 
on 28th Feb, there are many issues we've already fixed since then. We are sorry 
about it, and from next release, we will discuss todo list before we actually 
get started to do them.

 
 # Enhance: optimize candlestick rendering and zooming in hundreds of thousand 
of data.
 # Enhance: enhance the category axis ticks and labels when there was no enough 
space to display all labels.
 ## Make the animation appropriate for label, ticks, splitLine, splitArea when 
view window moving (by dataZoom) in category axis.
 ## Category axis tick and label was not corresponding to each other.
 ## Make the choose of ticks and labels stable when view window moving (by 
dataZoom) in category axis.
 # Enhance: order of nodes for sankey diagram. #3390 #3543 #6365 #4880 #4986
 # Feature: Add zoom and drag interactions for tree diagram.
 # Fix: SVG axisPointer text position bug #7947
 # Enhance: performance of bar chart in hundreds of thousand of data. (done)
 # Enhance: sampling performance in progressive mode. (done)
 # Enhance: parallel performance in progressive mode. (done)
 # Fix: large lines chart render bug in large mode. (done)
 # Fix: The last day of a month was not displayed in calendar #8045. (done)
 # Fix: dataSample caused incorrect extent when data is NaN. (done)
 # Fix: data sample worked abnormally when using `series.encode`. #8017 (done)
 # Fix: `legendHoverLink: false` did not work appropriately when multiple 
series have the same name. #8010 (done)
 # Fix: Some of the graph hover style did not work. (done)
 # Enhance: currently do not filter empty data item in data zoom, which makes 
line chart keeping broken. #7955 (done)
 # Enhance: support toolbox.feature merge. (done)
 # Fix: currently we fetch name from dateItem.name firstly in list. #7966 (done)
 # Fix: typed array incorrect usage in WeChat app. (done)
 # Fix: option in axis data item did not work. #7954 (done)
 # Fix: markArea only displayed the last one. #7902 (done)
 # Fix: rounding error in clip symbol for line chart. #7913 (done)
 # Fix: bar chart start point was incorrect when multiple axes exist. #7412 
(done)
 # Fix: markArea did not display when using ordinal string. #7849 (done)
 # Fix: dataZoom threw error when series was empty. #7666 (done)
 # Enhance: add tree directions from right to left, from bottom to top for tree 
series. #7351 #7154 (done)
 ## The corresponding values of the configuration 'orient' are 'RL' and 'BT'.
 # Fix: resolve browser become unresponsive when the data of sankey series has 
cycle. #7495 #8117 #7583 #7325 #6555 (done)
 # Fix: add compatibility of data exceptions for sankey series. #2867 (done)
 # Fix: error when remove node or render again for the tree series. #8038 #8040 
#7720 #7363 # 7315 (done)
 # Fix: sunburst chart roll-up element is not removed when chart.setOption 
called. #8132 (done)
 ## A roll-up element is for going back from drilling down in sunburst charts.
 # Feature: support keeping-aspect for legend path. #7831 (done)
 ## Path defined in legend was not keeping aspect, but fitting the aspect of 
default legend size, which is not ideal for most path shapes.

 

Please send some feedback about them. Thanks!

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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