Re: Concerned about the LGPL dependency in Webkit

[York Shen]

Just some further information about what @ddy199726 said.

The relationship between weex and JavaScriptCore is similar to the relationship 
between any Java Project and JDK.

If one want to run a Java program, he/she must have a JDK/JRE to interpret Java 
byte code.
If one want to run a Weex program, he/she must have a JavaScript interpretator 
to interpret JavaScript. Here we choose JavaScriptCore.
Like any Java program must import some Java Class in the standard JDK/JRE, weex 
has to import the some API (.h file) in JavaScriptCore. All those API itself is 
under BSD License. @ddy199726 and I have doubled checked it.
The only problem I see here is that JavaScriptCore is inside the binary of 
Weex, which should not happen anymore. We plan to decouple it from Weex then 
users must include weex_sdk and JavaScriptCore together in their product.

Best Regards,
York Shen

申远

> 在 2019年7月17日，15:16，dyy199...@gmail.com 写道：
> 
> Hey I'm a developer of incubator-weex
> 
> Weex used to use JavaScriptCore's source code directly to execute JavaScript 
> like this way .
> 
> 
> JSValue returnValue = evaluate(globalObject->globalExec(), 
> makeSource(source, sourceOrigin, url), JSValue(),
> evaluationException);
> 
> in this case, globalObject is inner object of JavaScriptCore,
> And makeSource is inline api of JavaScriptCore. 
> 
> So Weex has to add all JavaScriptCore's source code to weex'
> s repo to make it work normally. There is an function call chain like 
> Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL.apiD is true at that 
> time.
> 
> But now, Weex has refactoring the way we use JavaScriptCore.
> Weex just use JavaScriptCore public api. And All JavaScriptCore source code 
> has been removed from weex's repo.
> 
> We just include JavaScriptCore's publish api only.
> 
> So this function chain 
> Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL.apiD is not existed 
> now.
> 
> Now Function chain is Weex.apiA -> JavaScriptCore.BSD.apiB -> 
> JavaScriptCore.so
> 
> So there is no webkit license and Webkit *.h in weex's repo now
> 
> you can checkout the source code from here 
> https://weex.apache.org/download/download.html#_0-26-0 
> 
> javaScriptCore's api directory is weex_core/Source/include/JavaScriptCore/API
> 
> Weex's logic that use JavaScriptCore's api is here weex_core/Source/js_runtime
> 
> FYI, JavaScriptCore itself is under dual License too, at least Weex include 
> files under BSD License from JavaScriptCore
> 
> 
> 
> 
>> 在 2019年7月16日，下午6:48，Myrle Krantz  写道：
>> 
>> Hey all,
>> 
>> First of all: congratulations on your recent release!
>> 
>> I wanted to circle back to this to make sure it gets resolved before the
>> next release.
>> 
>> First a summary of what has happened as I see it.  If my summary is
>> incorrect, please let me know:
>> * At some point in the past Weex introduced a run-time and a compile-time
>> dependency to Webkit.  When adding the Webkit *.h to the repo, the correct
>> license of those files was accidentally overwritten.
>> * More recently, this mistake was discovered and a license review of Webkit
>> as a dependency was made in which it was realized that Webkit:
>> "As Webkit is under dual license, and it's almost impossible for us to
>> figure out whether there is an function call chain like
>> Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL.apiD. I'd like to
>> know our proposed change is enough to fix the Category X dependency."
>> (
>> https://lists.apache.org/thread.html/babe010a7814d4cf3d3d92588bee9dd22277b610daf83733d2622c91@%3Cgeneral.incubator.apache.org%3E
>> )
>> * The question of whether Webkit could release like this was raised to the
>> incubator and then to legal.
>> * Despite the lack of resolution to this question, Weex was still allowed
>> to make it's most recent release, because Weex is still in incubation.
>> 
>> While reviewing the release, it became clear to me that Weex is including
>> WebKit for it's JavaScriptCore.  Within WebKit, JavaScriptCore is
>> LGPL-licensed.  So it is likely that your functional call chains will
>> include LGPL-licensed code (after all that's the code you're including
>> WebKit for).
>> 
>> Is there an alternative implementation of JavaScriptCore that a user could
>> use in place of the LGPL-licensed portions of WebKit?
>> 
>> Best Regards,
>> Myrle
> 

Re: App freezing with 0.26 sdk update

[Vipul Gupta]

Sure York shen.
Please find link to Github -
https://github.com/apache/incubator-weex/issues/2718


On Wed, Jul 17, 2019 at 2:43 PM York Shen  wrote:

> Well, please report bug using Github Issue with the default template[1]
> and provide a reproducible demo. As a developer, you might understand that
> there is nothing we can do before reproducing the potential problems.
>
> [1] https://github.com/apache/incubator-weex/issues/new/choose <
> https://github.com/apache/incubator-weex/issues/new/choose>
>
> Best Regards,
> York Shen
>
> 申远
>
> > 在 2019年7月17日，01:12，Vipul Gupta  写道：
> >
> > Hi Team,
> >
> > We have updated our app with 0.26 sdk update, post which the app is
> > responding slower to click events.
> > Also, the rendering is slower as compared to previous versions.
> > Request your support in this regard.
> >
> > --
> > Regards,
> > Vipul Gupta
> > Senior Technical Lead
> > 8802232975
>
>

-- 
Regards,
Vipul Gupta
Senior Technical Lead
8802232975

Re: [DISCUSS] How to handle Github Issue

[York Shen]

Thanks for the information you provide.

I’d like to combine the information you provide and the proposal of "planing 
work based on Github issues/PRs/milestone you mentioned last time” [1] together 
and write down a more formal solution that we can discuss and implement with 
little cost.

It might take me a little longer time than usual.

[1] 
https://lists.apache.org/thread.html/043250bc9589c947721bbd703d9ce535e67f7ed0e3a1bbee22aa1f18@%3Cdev.weex.apache.org%3E
 


Best Regards,
York Shen

申远

> 在 2019年7月16日，18:49，Jan Piotrowski  写道：
> 
> Issues definitely are like weeds - there are always more.
> 
> Some unstructured thoughts:
> 
> - Add a feature request template
> - Add a support template that moves questions and debugging stuff to
> Stack Overflow (if you have many of those)
> - Add some more space to type into the bug report template, currently
> it is very full already on start
> - Try to quickly respond to new issue and ask for clarification
> - For Apache Cordova asking for a new, plain project with reproduction
> was a good way to move a lot of the work from committers to users:
> https://github.com/apache/cordova-contribute/blob/master/create-reproduction.md
> - Close issues that delete the issue template and ask them to create a new one
> - Think about not supporting older versions (and debugging of problems in 
> them)
> - Use labels to "group" or categorize issues, that way it is much
> easier to just leave them open if they are for areas that are not in
> focus right now
> - Use milestones to "prioritize" issues. Something that is in "far
> future" doesn't have to be looked at vs. something that is in "next
> bugfix release" for example
> - For another bug OSS project I am working on I created a habit for
> myself to start every day with triaging and tagging all the new issues
> that came in over night. Issues without labels are "untriaged". That
> way it's 30 minutes per day to keep "up to date", and then the real
> work can start
> - Maybe try to communicate clearly which issues someone from the team
> will tackle, and which will need someone from the community to step up
> and in
> - Maybe tag your issues by language - could help non-bi-lingual users
> to look for issues they will understand (Currently quite frustrating
> for me to open all those issues I can't even read)
> 
> Good luck!
> 
> Am Di., 16. Juli 2019 um 12:31 Uhr schrieb 申远 :
>> 
>> As you might observe, the quantity of Weex's users is huge, and there are
>> around 15 to 20 new Github issues every week. It's a lot of work for me to
>> verify, response and fix the issues especially some of them are in low
>> quality. For example, it took me 3 hours to read all the new issues and
>> close the one without reproduce procedure and verify other issues existing.
>> 
>> I am really curious about how other Apache projects handle Github Issues.
>> Is Github Issues like grass that you must weed every week?
>> 
>> And how to encourage users to get more involved, like reading the code and
>> create PRs instead of simply asking questions on Github? If we could find
>> promising contributors or committers in our users continually, then we
>> shall build a more healthy community.
>> 
>> I know there are many projects around Weex, like EEUI[1], EMAS[2], etc..
>> And I even know there are books about how to write code using Weex. It's
>> totally fine if one want to create its own community or project based on
>> Weex, but it would be great if such projects could join the Weex community.
>> 
>> [1] https://eeui.app/
>> [2] https://cn.aliyun.com/solution/emas
>> 
>> Best Regards,
>> YorkShen
>> 
>> 申远

Re: [ANNOUNCEMENT] Separate weex_sdk and weex_playground for good

[York Shen]

Thanks.

I shall fix the documentation issues(pretty a lot) early in next week.

Best Regards,
York Shen

申远

> 在 2019年7月16日，16:44，Jan Piotrowski  写道：
> 
> Awesome, that was quick - thanks Katherine and RenminWang!
> 
> I will try to check out and play with
> https://github.com/apache/incubator-weex-playground soon.
> 
> A note: Now that playground is separate,
> https://github.com/apache/incubator-weex#use-weex could use some
> cleanup to make clear what Playground is and how it is integrated into
> the main repo - that is still confusing to me (Actually,
> https://github.com/apache/incubator-weex-playground could use an
> introduction paragraph what Playground is and how it uses Weex).
> https://weex.apache.org/tools/playground.html could also use a link to
> the repository.
> 
> -J
> 
> Am Di., 16. Juli 2019 um 05:00 Uhr schrieb 申远 :
>> 
>> Also, I'd really appreciate the contribution of @Katherine and @RenminWang,
>> as they are the ones who actually write code here for above purpose.
>> 
>> Best Regards,
>> YorkShen
>> 
>> 申远
>> 
>> 
>> 申远  于2019年7月16日周二 上午10:52写道：
>> 
>>> As it's discussed before[1] , we have successfully separated weex_sdk[2]
>>> and weex_playground[3] into two git repos without losing the users'
>>> convenience by making weex_playground a git submodule of weex_sdk.
>>> 
>>> Next, we shall decouple Webkit(Weex only uses JavaScriptCore inside
>>> Webkit) from the convenience binary of weex_sdk. We expect to finish the
>>> job in August, 2019 before next release.
>>> 
>>> Finally, we will fix the package name issue of Android [4]. The time
>>> schedule for issue is not settled yet.
>>> 
>>> The goal of the above changing is to make Weex clear in both dependencies
>>> and IP(package name) aspects, and we will be able to publish a Release
>>> without deleting files(Webkit.so) from git repo [5].
>>> 
>>> The issues above may not be a problem for a normal user of Weex, as they
>>> are time consuming and don't add new features or fix bugs for Weex. But if
>>> we consider Weex as a project that may be alive for more than ten years,
>>> it's sooner than later to make dependency and IP(package name) clear. I
>>> can't image how to fix these issues for a project with above ten-years
>>> history.
>>> 
>>> [1]
>>> https://lists.apache.org/thread.html/020895785263a3f5ee4dfa6c56167c01699227d9512f19f6635ef563@%3Cdev.weex.apache.org%3E
>>> [2] https://github.com/apache/incubator-weex
>>> [3] https://github.com/apache/incubator-weex-playground
>>> [4]
>>> https://lists.apache.org/thread.html/b3c4974a208f87e21c1f12b4ba5e5308cf20f7678cedd4523b5ddf25@%3Cdev.weex.apache.org%3E
>>> [5]
>>> https://github.com/apache/incubator-weex/blob/master/scripts/generate_apache_source.sh
>>> 
>>> Best Regards,
>>> YorkShen
>>> 
>>> 申远
>>> 

Re: App freezing with 0.26 sdk update

[York Shen]

Well, please report bug using Github Issue with the default template[1] and 
provide a reproducible demo. As a developer, you might understand that there is 
nothing we can do before reproducing the potential problems.

[1] https://github.com/apache/incubator-weex/issues/new/choose 


Best Regards,
York Shen

申远

> 在 2019年7月17日，01:12，Vipul Gupta  写道：
> 
> Hi Team,
> 
> We have updated our app with 0.26 sdk update, post which the app is
> responding slower to click events.
> Also, the rendering is slower as compared to previous versions.
> Request your support in this regard.
> 
> -- 
> Regards,
> Vipul Gupta
> Senior Technical Lead
> 8802232975

Re: Concerned about the LGPL dependency in Webkit

[dyy199726]

Hey I'm a developer of incubator-weex

Weex used to use JavaScriptCore's source code directly to execute JavaScript 
like this way .


JSValue returnValue = evaluate(globalObject->globalExec(), makeSource(source, 
sourceOrigin, url), JSValue(),
evaluationException);

in this case, globalObject is inner object of JavaScriptCore,
And makeSource is inline api of JavaScriptCore. 

So Weex has to add all JavaScriptCore's source code to weex'
s repo to make it work normally. There is an function call chain like 
Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL.apiD is true at that 
time.

But now, Weex has refactoring the way we use JavaScriptCore.
Weex just use JavaScriptCore public api. And All JavaScriptCore source code has 
been removed from weex's repo.

We just include JavaScriptCore's publish api only.

So this function chain 
Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL.apiD is not existed 
now.

Now Function chain is Weex.apiA -> JavaScriptCore.BSD.apiB -> JavaScriptCore.so

So there is no webkit license and Webkit *.h in weex's repo now

you can checkout the source code from here 
https://weex.apache.org/download/download.html#_0-26-0 

javaScriptCore's api directory is weex_core/Source/include/JavaScriptCore/API

Weex's logic that use JavaScriptCore's api is here weex_core/Source/js_runtime

FYI, JavaScriptCore itself is under dual License too, at least Weex include 
files under BSD License from JavaScriptCore




> 在 2019年7月16日，下午6:48，Myrle Krantz  写道：
> 
> Hey all,
> 
> First of all: congratulations on your recent release!
> 
> I wanted to circle back to this to make sure it gets resolved before the
> next release.
> 
> First a summary of what has happened as I see it.  If my summary is
> incorrect, please let me know:
> * At some point in the past Weex introduced a run-time and a compile-time
> dependency to Webkit.  When adding the Webkit *.h to the repo, the correct
> license of those files was accidentally overwritten.
> * More recently, this mistake was discovered and a license review of Webkit
> as a dependency was made in which it was realized that Webkit:
> "As Webkit is under dual license, and it's almost impossible for us to
> figure out whether there is an function call chain like
> Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL.apiD. I'd like to
> know our proposed change is enough to fix the Category X dependency."
> (
> https://lists.apache.org/thread.html/babe010a7814d4cf3d3d92588bee9dd22277b610daf83733d2622c91@%3Cgeneral.incubator.apache.org%3E
> )
> * The question of whether Webkit could release like this was raised to the
> incubator and then to legal.
> * Despite the lack of resolution to this question, Weex was still allowed
> to make it's most recent release, because Weex is still in incubation.
> 
> While reviewing the release, it became clear to me that Weex is including
> WebKit for it's JavaScriptCore.  Within WebKit, JavaScriptCore is
> LGPL-licensed.  So it is likely that your functional call chains will
> include LGPL-licensed code (after all that's the code you're including
> WebKit for).
> 
> Is there an alternative implementation of JavaScriptCore that a user could
> use in place of the LGPL-licensed portions of WebKit?
> 
> Best Regards,
> Myrle