[DISCUSS] Delete file of POSSIBLE-NOTICES-FOR-BIN-DIST

[York Shen]

Hi, community.

I found there is a file named POSSIBLE-NOTICES-FOR-BIN-DIST in Weex Git repo 
and I’d like to delete this file in next release.

As the LICENSE [2] file already gives a description of our License and 
dependency, I don’t think it’s necessary to remain 
POSSIBLE-NOTICES-FOR-BIN-DIST anymore, IMO. If this is no objection, I will 
delete it in next release.

FYI: The file may exists for a historical reason that I am not aware of, I’d 
like to get some opinion if someone in this mailing knows anything about this 
file.

[1] 
https://github.com/apache/incubator-weex/blob/master/POSSIBLE-NOTICES-FOR-BIN-DIST
 
<https://github.com/apache/incubator-weex/blob/master/POSSIBLE-NOTICES-FOR-BIN-DIST>
[2] https://github.com/apache/incubator-weex/blob/master/LICENSE 
<https://github.com/apache/incubator-weex/blob/master/LICENSE>


Best Regards,
York Shen

申远

[DISCUSS] Prepare to start release Weex 0.28

[York Shen]

Hi, community

I'd like to start a release for Weex 0.28 based on master branch after the PR 
[1] fixing LGPL problems merged. 

Does anyone have any reason to delay the release? Any other vital patches needs 
to be merged?

If not, I’d like to call a release vote later in this week.

FYI: The publishing script of convenience binary (publishing release.aar and 
legacy_release.aar together to maven centeral) is not finished, however this 
will not block the release as Apache release has nothing to do with convenience 
binary, IMO.

[1] https://github.com/apache/incubator-weex/pull/2940

Best Regards,
York Shen

申远

Re: [IP CLEARANCE] Apache Weex - Weex Loader

[York Shen]

The hyperlink in the previous mail is somehow wrong, please copy and paste the 
URL to your browser mannually if you are interested about the IP clearance.

Best Regards,
York Shen

申远

> 在 2019年9月30日，14:55，申远  写道：
> 
> Hi community,
> 
> Apache Weex received an another donation called Weex Loader soon after Weex 
> CLI[1] donated to ASF. 
> 
> Weex Loader is a loader of webpack that can transform *.vue file into a plain 
> javascript module for Android and iOS platform. In other words, it's a 
> compiler for compiling .vue file to .js file.
> 
> The IP clearance form can be found at: 
> https://incubator.apache.org/ip-clearance/weex_loader.html 
> <https://incubator.apache.org/ip-clearance/weex_cli.html> once the website 
> updates. 
> One can view the xml version at: 
> https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/weex_loader.xml
>  
> <https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/weex_cli.xml>
>  
> 
> The git commit containing the donation can be found 
> https://github.com/weexteam/weex-loader/commit/83d3767d419e8ba0d28f3e16cd22ad8543f2cfac
>  
> <https://github.com/weexteam/weex-loader/commit/83d3767d419e8ba0d28f3e16cd22ad8543f2cfac>
>  . The git repo will be transferred to ASF at the end of the process.
> 
> Please vote to approve this contribution. Lazy consensus applies: 
> If no -1, votes are being cast within the next 72 hours, the vote passes.
> 
> [1] 
> https://lists.apache.org/thread.html/97e18ae60f7ae10c8c3a6111bbc64ca9bcac34fc98be90ad0ac4aaf2@%3Cgeneral.incubator.apache.org%3E
>  
> <https://lists.apache.org/thread.html/97e18ae60f7ae10c8c3a6111bbc64ca9bcac34fc98be90ad0ac4aaf2@%3Cgeneral.incubator.apache.org%3E>
> 
> Best Regards,
> YorkShen
> 
> 申远

Re: [IP CLEARANCE] Apache Weex - Weex CLI

[York Shen]

We got +1 vote in dev@weex  and no -1 vote.

The vote has passed successfully, I will post another mail thread to announce 
the result.

Best Regards,
York Shen

申远

> 在 2019年9月27日，15:21，Jan Piotrowski  写道：
> 
> +1
> 
> Am Fr., 27. Sept. 2019 um 06:17 Uhr schrieb York Shen :
>> 
>> Hi community,
>> 
>> Apache Weex received a donation of a software called Weex CLI (i.e. Weex 
>> Toolkit) which is dedicated to standardizing the tool in  Weex ecosystem. It 
>> ensures that various build tools can be seamlessly connected based on smart 
>> default configuration, so users can focus on writing applications without 
>> having to spend days tangling configuration issues.
>> 
>> The IP clearance form can be found at: 
>> https://incubator.apache.org/ip-clearance/weex_cli.html 
>> <https://incubator.apache.org/ip-clearance/weex_cli.html> once the website 
>> updates. One can view the xml version at: 
>> https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/weex_cli.xml
>>  
>> <https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/weex_cli.xml>
>> 
>> 
>> The git commit containing the donation can be found 
>> https://github.com/weexteam/CLI-for-Apache-Weex/commit/7eadde0efa0982f36cf9b3915adad4b672dc5408
>>  
>> <https://github.com/weexteam/CLI-for-Apache-Weex/commit/7eadde0efa0982f36cf9b3915adad4b672dc5408>
>>  . The git repo will be transferred to ASF at the end of the process.
>> 
>> Please vote to approve this contribution. Lazy consensus applies:
>> If no -1, votes are being cast within the next 72 hours, the vote passes.
>> 
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远
>> 

Re: Is there any plan to use flutter as render?

[York Shen]

Thanks for your interesting.

First of all, I think Flutter is a great project with some limitation.(e.g. how 
to embed a pre-built native UI library into flutter, like videoView in live 
video streaming, imageView in image library) and I am also interested in 
Flutter similar approach. But at current stage, we are trying our best to solve 
graduation block issues [1] , which means Flutter related approach is not 
priority for now. But if you have more detail of your plan or MVP(minimum 
viable product), I’d like to have a look with you and see what we can do 
together to make things happen.

[1] https://cwiki.apache.org/confluence/x/NJNiBw

Best Regards,
York Shen

申远

> 在 2019年9月29日，09:45，chenzefeng  写道：
> 
> Hi all:
> I have use weex in production for 2 years, one of  the best things I love 
> about  weex is that it can build nice cross-platform ui.
> 
> 
> Weex sdk does a lot of works to unify the appearance and interactions between 
> different platforms, but always, components ui cannot be 100% identical , or 
> sometimes the adapting codes make a component unpredictable in an edge 
> situation.
> I think use flutter as render is a good solution.
> 1、Great promotion in UI consistency.This could promote weex developing 
> experience a lot.
> 2、Unify renders in Weex sdk of different platforms, so that  weex team can 
> focus on one render, not adapting two different ones.
> I think flutter as render is a trend that cannot be ignored, and some blogs 
> mention that there are tech teams(wechat、metuan etc.)  doing very similar 
> things.
> 
> 
> So, is flutter in our plan?
> 
> 
> Every discussion is welcomed, not just answer.

Re: Podling Report Reminder - October 2019

[York Shen]

Just moved the podlling report from Weex wiki[1] to Incubator’s

[1] https://cwiki.apache.org/confluence/x/PA-ABw

Best Regards,
York Shen

申远

> 在 2019年9月29日，08:45，jmcl...@apache.org 写道：
> 
> Dear podling,
> 
> This email was sent by an automated system on behalf of the Apache
> Incubator PMC. It is an initial reminder to give you plenty of time to
> prepare your quarterly board report.
> 
> The board meeting is scheduled for Wed, 16 October 2019, 10:30 am PDT.
> The report for your podling will form a part of the Incubator PMC
> report. The Incubator PMC requires your report to be submitted 2 weeks
> before the board meeting, to allow sufficient time for review and
> submission (Wed, October 02).
> 
> Please submit your report with sufficient time to allow the Incubator
> PMC, and subsequently board members to review and digest. Again, the
> very latest you should submit your report is 2 weeks prior to the board
> meeting.
> 
> Candidate names should not be made public before people are actually
> elected, so please do not include the names of potential committers or
> PPMC members in your report.
> 
> Thanks,
> 
> The Apache Incubator PMC
> 
> Submitting your Report
> 
> --
> 
> Your report should contain the following:
> 
> *   Your project name
> *   A brief description of your project, which assumes no knowledge of
>the project or necessarily of its field
> *   A list of the three most important issues to address in the move
>towards graduation.
> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
>aware of
> *   How has the community developed since the last report
> *   How has the project developed since the last report.
> *   How does the podling rate their own maturity.
> 
> This should be appended to the Incubator Wiki page at:
> 
> https://cwiki.apache.org/confluence/display/INCUBATOR/October2019
> 
> Note: This is manually populated. You may need to wait a little before
> this page is created from a template.
> 
> Note: The format of the report has changed to use markdown.
> 
> Mentors
> ---
> 
> Mentors should review reports for their project(s) and sign them off on
> the Incubator wiki page. Signing off reports shows that you are
> following the project - projects that are not signed may raise alarms
> for the Incubator PMC.
> 
> Incubator PMC

[DISCUSS] Graduate Weex from Apache Incubator

[York Shen]

Hi, community.

First of all, I sent this email to make consensus, not call an official vote. 
As always, everyone is welcomed to expressed their opinions.

Apache Weex(Incubating) joined the Incubator since Nov, 2016 and the community 
has grown diverse, moved to ASF infrastructure, learnt Apache way and its value 
behind. Some of achievements of Apache Weex is listed below:
Published 5 release by 5 release manager
Inviting 16 new committers
Migrated code repos to https://github.com/apache/incubator-weex/ 
<https://github.com/apache/incubator-weex/> 
Migrated website to https://weex.apache.org/ <https://weex.apache.org/>
Migrated conversation/decision to d...@weex.apache.org 
<mailto:d...@weex.apache.org> 

And there are some problems needed to be solved before graduation. Luckily for 
us, we have solutions for each one of the problems:
Third party IP: We will make those third part IP donated to ASF,  and we’re 
currently in IP clearance process.
LGPL runtime dependency: We got these problems solved by switching to 
BSD-Licensed jsc-android [1] in this PR [2].
Rename android package name to org.apache.weex: Resolved by this PR [3]
Some web pages [4] on our website relies on third-part server API: We will 
delete this page soon.

I shall call a vote for Apache release after problem 2 solved, and will call a 
formal vote for graduation in this mailing list when all of the problems above 
solved. According to my estimation, two or three weeks is needed for solving 
all the issues above. At last, I hope we could graduate from Apache Incubator 
before next Podlling report.

[1] https://www.npmjs.com/package/jsc-android 
<https://www.npmjs.com/package/jsc-android>
[2] https://github.com/apache/incubator-weex/pull/2940 
<https://github.com/apache/incubator-weex/pull/2940>
[3] https://github.com/apache/incubator-weex/pull/2925 
<https://github.com/apache/incubator-weex/pull/2925> 
[4] https://weex.apache.org/community/solutions.html 
<https://weex.apache.org/community/solutions.html>

Best Regards,
York Shen

申远

Re: Podling Report Reminder - October 2019

[York Shen]

I have just finished the draft of Podling report [1], and I shall copy it to 
Incubator-Wiki on next Monday (30th, Sep) if there is no other opinion.

FYI: As there is a national holiday in China, I will take a vacation from 1st, 
Oct to 7th, Oct.

[1] https://cwiki.apache.org/confluence/x/PA-ABw

Best Regards,
York Shen

申远

> 在 2019年9月24日，15:04，York Shen  写道：
> 
> https://cwiki.apache.org/confluence/display/WEEX/October%2C+2019 
> <https://cwiki.apache.org/confluence/display/WEEX/October%2C+2019>
> 
>> 在 2019年9月24日，15:03，York Shen  写道：
>> 
>> Thanks.
>> 
>> I have just created anempty template on confluence for Podding report - 
>> October 2019. I shall finish it after the Weex-CLI/ Weex-loader donated to 
>> ASF.
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远
>> 
>>> 在 2019年9月22日，18:46，jmcl...@apache.org <mailto:jmcl...@apache.org> 写道：
>>> 
>>> Dear podling,
>>> 
>>> This email was sent by an automated system on behalf of the Apache
>>> Incubator PMC. It is an initial reminder to give you plenty of time to
>>> prepare your quarterly board report.
>>> 
>>> The board meeting is scheduled for Wed, 16 October 2019, 10:30 am PDT.
>>> The report for your podling will form a part of the Incubator PMC
>>> report. The Incubator PMC requires your report to be submitted 2 weeks
>>> before the board meeting, to allow sufficient time for review and
>>> submission (Wed, October 02).
>>> 
>>> Please submit your report with sufficient time to allow the Incubator
>>> PMC, and subsequently board members to review and digest. Again, the
>>> very latest you should submit your report is 2 weeks prior to the board
>>> meeting.
>>> 
>>> Candidate names should not be made public before people are actually
>>> elected, so please do not include the names of potential committers or
>>> PPMC members in your report.
>>> 
>>> Thanks,
>>> 
>>> The Apache Incubator PMC
>>> 
>>> Submitting your Report
>>> 
>>> --
>>> 
>>> Your report should contain the following:
>>> 
>>> *   Your project name
>>> *   A brief description of your project, which assumes no knowledge of
>>>the project or necessarily of its field
>>> *   A list of the three most important issues to address in the move
>>>towards graduation.
>>> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
>>>aware of
>>> *   How has the community developed since the last report
>>> *   How has the project developed since the last report.
>>> *   How does the podling rate their own maturity.
>>> 
>>> This should be appended to the Incubator Wiki page at:
>>> 
>>> https://cwiki.apache.org/confluence/display/INCUBATOR/October2019 
>>> <https://cwiki.apache.org/confluence/display/INCUBATOR/October2019>
>>> 
>>> Note: This is manually populated. You may need to wait a little before
>>> this page is created from a template.
>>> 
>>> Note: The format of the report has changed to use markdown.
>>> 
>>> Mentors
>>> ---
>>> 
>>> Mentors should review reports for their project(s) and sign them off on
>>> the Incubator wiki page. Signing off reports shows that you are
>>> following the project - projects that are not signed may raise alarms
>>> for the Incubator PMC.
>>> 
>>> Incubator PMC
>> 
> 

Re: Concerned about the LGPL dependency in Webkit

[York Shen]

Related PR:  https://github.com/apache/incubator-weex/pull/2940 
<https://github.com/apache/incubator-weex/pull/2940>.

Developers could choose any JS interpretator they like by passing a URL [1] 
when compiling their products.

I shall write a documentation later about how to pass these parameters, but 
everything else looks fine to me.

[1] 
https://github.com/apache/incubator-weex/pull/2940/files#diff-312acf6d9ae67bf7d5e8c81da772df85R2

Best Regards,
York Shen

申远

> 在 2019年9月26日，14:55，York Shen  写道：
> 
> Rephrase myself.
> 
> I will create a feature which provides the ability of changing JavaScript 
> Interpretator at compiling time. Developers are totally free to choose 
> whichever JavaScript Interpretator they like as long as its interface is the 
> same as we currently using.
> 
> I shall write some documentation and scripts to give an introduction about 
> how to choose JavaScript Interpretator they like. And only in this 
> introduction I will use jsc-android [1] for demo purpose, but neither the 
> source code or binary of Weex would contain any JavaScript interpretator code.
> 
> I think this feature will not only solve the License and dependency problem 
> for good, but also gives developers the ability of choosing JS interpretator 
> they like.
> 
> [1] https://www.npmjs.com/package/jsc-android 
> <https://www.npmjs.com/package/jsc-android>
> 
> Best Regards,
> York Shen
> 
> 申远
> 
>> 在 2019年9月25日，14:56，York Shen > <mailto:shenyua...@gmail.com>> 写道：
>> 
>> As it’s a NPM plugin, I need some time to figure out how to integrate it 
>> into Android build process, but everything else should be fine.
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远
>> 
>>> 在 2019年9月25日，14:49，York Shen >> <mailto:shenyua...@gmail.com>> 写道：
>>> 
>>> Updated:
>>> 
>>> I just found a JavasScript Interpretator callled jsc-android[1] under 
>>> BSD-2-Clause License. As it’s provided the exactly same interface we are 
>>> currently using, I think we can solve this problem by switching to 
>>> jsc-android. 
>>> 
>>> Thanks for the help of @lucky-chen, I have successfully built and run Weex 
>>> on jsc-android.
>>> 
>>> No more platform dependency, no more LGPL runtime.
>>> 
>>> [1] https://www.npmjs.com/package/jsc-android 
>>> <https://www.npmjs.com/package/jsc-android>
>>> 
>>> Best Regards,
>>> York Shen
>>> 
>>> 申远
>>> 
>>>> 在 2019年7月23日，03:15，Myrle Krantz >>> <mailto:my...@apache.org>> 写道：
>>>> 
>>>> Thanks YorkShen,
>>>> 
>>>> This is an answer I can live with.  Let's see if legal can live with it
>>>> too.  I've pinged the ticket you made.  Let me see if I can get it
>>>> unblocked.
>>>> 
>>>> Best,
>>> 
>> 
> 

[IP CLEARANCE] Apache Weex - Weex CLI

[York Shen]

Hi community,

Apache Weex received a donation of a software called Weex CLI (i.e. Weex 
Toolkit) which is dedicated to standardizing the tool in  Weex ecosystem. It 
ensures that various build tools can be seamlessly connected based on smart 
default configuration, so users can focus on writing applications without 
having to spend days tangling configuration issues.

The IP clearance form can be found at: 
https://incubator.apache.org/ip-clearance/weex_cli.html 
<https://incubator.apache.org/ip-clearance/weex_cli.html> once the website 
updates. One can view the xml version at: 
https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/weex_cli.xml
 
<https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/weex_cli.xml>
 


The git commit containing the donation can be found 
https://github.com/weexteam/CLI-for-Apache-Weex/commit/7eadde0efa0982f36cf9b3915adad4b672dc5408
 
<https://github.com/weexteam/CLI-for-Apache-Weex/commit/7eadde0efa0982f36cf9b3915adad4b672dc5408>
 . The git repo will be transferred to ASF at the end of the process.

Please vote to approve this contribution. Lazy consensus applies: 
If no -1, votes are being cast within the next 72 hours, the vote passes.


Best Regards,
York Shen

申远

Re: Concerned about the LGPL dependency in Webkit

[York Shen]

Rephrase myself.

I will create a feature which provides the ability of changing JavaScript 
Interpretator at compiling time. Developers are totally free to choose 
whichever JavaScript Interpretator they like as long as its interface is the 
same as we currently using.

I shall write some documentation and scripts to give an introduction about how 
to choose JavaScript Interpretator they like. And only in this introduction I 
will use jsc-android [1] for demo purpose, but neither the source code or 
binary of Weex would contain any JavaScript interpretator code.

I think this feature will not only solve the License and dependency problem for 
good, but also gives developers the ability of choosing JS interpretator they 
like.

[1] https://www.npmjs.com/package/jsc-android

Best Regards,
York Shen

申远

> 在 2019年9月25日，14:56，York Shen  写道：
> 
> As it’s a NPM plugin, I need some time to figure out how to integrate it into 
> Android build process, but everything else should be fine.
> 
> Best Regards,
> York Shen
> 
> 申远
> 
>> 在 2019年9月25日，14:49，York Shen > <mailto:shenyua...@gmail.com>> 写道：
>> 
>> Updated:
>> 
>> I just found a JavasScript Interpretator callled jsc-android[1] under 
>> BSD-2-Clause License. As it’s provided the exactly same interface we are 
>> currently using, I think we can solve this problem by switching to 
>> jsc-android. 
>> 
>> Thanks for the help of @lucky-chen, I have successfully built and run Weex 
>> on jsc-android.
>> 
>> No more platform dependency, no more LGPL runtime.
>> 
>> [1] https://www.npmjs.com/package/jsc-android 
>> <https://www.npmjs.com/package/jsc-android>
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远
>> 
>>> 在 2019年7月23日，03:15，Myrle Krantz >> <mailto:my...@apache.org>> 写道：
>>> 
>>> Thanks YorkShen,
>>> 
>>> This is an answer I can live with.  Let's see if legal can live with it
>>> too.  I've pinged the ticket you made.  Let me see if I can get it
>>> unblocked.
>>> 
>>> Best,
>> 
> 

Re: Concerned about the LGPL dependency in Webkit

[York Shen]

As it’s a NPM plugin, I need some time to figure out how to integrate it into 
Android build process, but everything else should be fine.

Best Regards,
York Shen

申远

> 在 2019年9月25日，14:49，York Shen  写道：
> 
> Updated:
> 
> I just found a JavasScript Interpretator callled jsc-android[1] under 
> BSD-2-Clause License. As it’s provided the exactly same interface we are 
> currently using, I think we can solve this problem by switching to 
> jsc-android. 
> 
> Thanks for the help of @lucky-chen, I have successfully built and run Weex on 
> jsc-android.
> 
> No more platform dependency, no more LGPL runtime.
> 
> [1] https://www.npmjs.com/package/jsc-android 
> <https://www.npmjs.com/package/jsc-android>
> 
> Best Regards,
> York Shen
> 
> 申远
> 
>> 在 2019年7月23日，03:15，Myrle Krantz mailto:my...@apache.org>> 
>> 写道：
>> 
>> Thanks YorkShen,
>> 
>> This is an answer I can live with.  Let's see if legal can live with it
>> too.  I've pinged the ticket you made.  Let me see if I can get it
>> unblocked.
>> 
>> Best,
> 

Re: Concerned about the LGPL dependency in Webkit

[York Shen]

Updated:

I just found a JavasScript Interpretator callled jsc-android[1] under 
BSD-2-Clause License. As it’s provided the exactly same interface we are 
currently using, I think we can solve this problem by switching to jsc-android. 

Thanks for the help of @lucky-chen, I have successfully built and run Weex on 
jsc-android.

No more platform dependency, no more LGPL runtime.

[1] https://www.npmjs.com/package/jsc-android

Best Regards,
York Shen

申远

> 在 2019年7月23日，03:15，Myrle Krantz  写道：
> 
> Thanks YorkShen,
> 
> This is an answer I can live with.  Let's see if legal can live with it
> too.  I've pinged the ticket you made.  Let me see if I can get it
> unblocked.
> 
> Best,

Re: [DISCUSS] Package name in Java code

[York Shen]

README file updated.

I shall update the website after next Apache Release.

Best Regards,
York Shen

申远

> 在 2019年9月24日，14:56，York Shen  写道：
> 
> I shall update the README file and website later.
> 
>> 在 2019年9月23日，17:33，Willem Jiang  写道：
>> 
>> +1, I think it's a good way to go.
>> Please add some description in the binary release kit to specify the
>> difference between the weex_sdk and weex_sdk_legacy.
>> 
>> Willem Jiang
>> 
>> Twitter: willemjiang
>> Weibo: 姜宁willem
>> 
>> On Wed, Sep 18, 2019 at 3:25 PM Jan Piotrowski  wrote:
>>> 
>>> Exactly, that is the opposite of what your original email said ;)
>>> 
>>>> weex_sdk will be compiled using the gradle-plugin mentioned above, while 
>>>> weex_sdk_legacy will not.
>>> 
>>> But I understand now and agree with your suggestion.
>>> 
>>> J
>>> 
>>> Am Mi., 18. Sept. 2019 um 04:40 Uhr schrieb York Shen 
>>> :
>>>> 
>>>> Nope.
>>>> 
>>>> The class name in source code(.java) will be ‘org.apache.weex’, as this is 
>>>> the right thing to do, IMO. The apache source code release will be under 
>>>> ‘org.apache.weex’ as well.
>>>> The weex_sdk will be built without the plugin therefore its package name 
>>>> shall also be 'org.apache.weex'.
>>>> The weex_sdk_legacy will be built with the plugin therefore its package 
>>>> name shall be ‘com.taobao.weex'.
>>>> Users can choose whichever the above connivence library they’d like.
>>>> 
>>>> 
>>>>> 在 2019年9月18日，02:56，Jan Piotrowski  写道：
>>>>> 
>>>>> Sounds good.
>>>>> 
>>>>>> weex_sdk will be compiled using the gradle-plugin mentioned above, while 
>>>>>> weex_sdk_legacy will not.
>>>>> 
>>>>> Don't you mean the other one around? The legacy one should be built
>>>>> using the plugin, leading to the class names being replaced with the
>>>>> old ones.
>>>>> 
>>>>> -J
>>>>> 
>>>>> Am Di., 17. Sept. 2019 um 13:56 Uhr schrieb York Shen 
>>>>> mailto:shenyua...@gmail.com>>:
>>>>>> 
>>>>>> Hi, community
>>>>>> 
>>>>>> Due to the restriction of Java language in method overriding [1], the 
>>>>>> solution I proposed months ago will not provide backwards-compatibility 
>>>>>> as expected but produce compiling error for users.
>>>>>> 
>>>>>> Therefore, I’d like to proposal a new solution to fix the problem.
>>>>>> 
>>>>>> Package name will be renamed from 'com.taobao.weex' to 'org.apache.weex' 
>>>>>> in source code and Apache Source Release as the previous plan.
>>>>>> Create a custom gradle-plugin which could rename package back to 
>>>>>> ‘com.taobao.weex’ at compiling time.
>>>>>> Publish two build variants (weex_sdk and weex_sdk_legacy) each time 
>>>>>> building connivence library. weex_sdk will be compiled using the 
>>>>>> gradle-plugin mentioned above, while weex_sdk_legacy will not.
>>>>>> Therefore, classes in weex_sdk will be under ‘org.apache.weex' package, 
>>>>>> and classes in weex_sdk_legacy will be under ‘com.taobao.weex’.
>>>>>> New users of weex should choose weex_sdk and new API, while current 
>>>>>> users could continue using weex_sdk_legacy which provide the same API 
>>>>>> behavior as now.
>>>>>> Finally, we would stop publishing weex_sdk_legacy sometime later.
>>>>>> 
>>>>>> The community could benefit from the above solution in following aspects:
>>>>>> For me, there is much less work to do in current plan than the old one. 
>>>>>> Less bug to write, less time to use. One or two weeks will be enough.
>>>>>> For users, There is a guarantee that the API behavior of weex_sdk_legacy 
>>>>>> is the same as before because the source code after processing of 
>>>>>> gradle-plugin is the same as before. The old plan won’t give this 
>>>>>> guarantee.
>>>>>> We make our position very clear by naming the connivence binary to 
>>>>>> weex_sdk_legacy .
>>>>>> 
>>>>>> [1] "When overriding a method, the signatures (name and argument types) 
>>>>>> have to be the same after type erasure." Ref 
>>>>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2 
>>>>>> <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2> 
>>>>>> <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2 
>>>>>> <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2>>
>>>>>>  for detail.
>>>>>> 
>>>>>> Best Regards,
>>>>>> York Shen
>>>>>> 
>>>>>> 申远
>>>>>> 
>>>>>>> 在 2019年7月1日，16:26，Jan Piotrowski >>>>>> <mailto:piotrow...@gmail.com>> 写道：
>>>>>>> 
>>>>>>> Sounds pretty neat and was pretty much what I was thinking of.
>>>>>>> 
>>>>>>> Th
>>>> 
> 

Re: Podling Report Reminder - October 2019

[York Shen]

https://cwiki.apache.org/confluence/display/WEEX/October%2C+2019

> 在 2019年9月24日，15:03，York Shen  写道：
> 
> Thanks.
> 
> I have just created anempty template on confluence for Podding report - 
> October 2019. I shall finish it after the Weex-CLI/ Weex-loader donated to 
> ASF.
> 
> Best Regards,
> York Shen
> 
> 申远
> 
>> 在 2019年9月22日，18:46，jmcl...@apache.org <mailto:jmcl...@apache.org> 写道：
>> 
>> Dear podling,
>> 
>> This email was sent by an automated system on behalf of the Apache
>> Incubator PMC. It is an initial reminder to give you plenty of time to
>> prepare your quarterly board report.
>> 
>> The board meeting is scheduled for Wed, 16 October 2019, 10:30 am PDT.
>> The report for your podling will form a part of the Incubator PMC
>> report. The Incubator PMC requires your report to be submitted 2 weeks
>> before the board meeting, to allow sufficient time for review and
>> submission (Wed, October 02).
>> 
>> Please submit your report with sufficient time to allow the Incubator
>> PMC, and subsequently board members to review and digest. Again, the
>> very latest you should submit your report is 2 weeks prior to the board
>> meeting.
>> 
>> Candidate names should not be made public before people are actually
>> elected, so please do not include the names of potential committers or
>> PPMC members in your report.
>> 
>> Thanks,
>> 
>> The Apache Incubator PMC
>> 
>> Submitting your Report
>> 
>> --
>> 
>> Your report should contain the following:
>> 
>> *   Your project name
>> *   A brief description of your project, which assumes no knowledge of
>>the project or necessarily of its field
>> *   A list of the three most important issues to address in the move
>>towards graduation.
>> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
>>aware of
>> *   How has the community developed since the last report
>> *   How has the project developed since the last report.
>> *   How does the podling rate their own maturity.
>> 
>> This should be appended to the Incubator Wiki page at:
>> 
>> https://cwiki.apache.org/confluence/display/INCUBATOR/October2019 
>> <https://cwiki.apache.org/confluence/display/INCUBATOR/October2019>
>> 
>> Note: This is manually populated. You may need to wait a little before
>> this page is created from a template.
>> 
>> Note: The format of the report has changed to use markdown.
>> 
>> Mentors
>> ---
>> 
>> Mentors should review reports for their project(s) and sign them off on
>> the Incubator wiki page. Signing off reports shows that you are
>> following the project - projects that are not signed may raise alarms
>> for the Incubator PMC.
>> 
>> Incubator PMC
> 

Re: [DISCUSS] Package name in Java code

[York Shen]

I shall update the README file and website later.

> 在 2019年9月23日，17:33，Willem Jiang  写道：
> 
> +1, I think it's a good way to go.
> Please add some description in the binary release kit to specify the
> difference between the weex_sdk and weex_sdk_legacy.
> 
> Willem Jiang
> 
> Twitter: willemjiang
> Weibo: 姜宁willem
> 
> On Wed, Sep 18, 2019 at 3:25 PM Jan Piotrowski  wrote:
>> 
>> Exactly, that is the opposite of what your original email said ;)
>> 
>>> weex_sdk will be compiled using the gradle-plugin mentioned above, while 
>>> weex_sdk_legacy will not.
>> 
>> But I understand now and agree with your suggestion.
>> 
>> J
>> 
>> Am Mi., 18. Sept. 2019 um 04:40 Uhr schrieb York Shen :
>>> 
>>> Nope.
>>> 
>>> The class name in source code(.java) will be ‘org.apache.weex’, as this is 
>>> the right thing to do, IMO. The apache source code release will be under 
>>> ‘org.apache.weex’ as well.
>>> The weex_sdk will be built without the plugin therefore its package name 
>>> shall also be 'org.apache.weex'.
>>> The weex_sdk_legacy will be built with the plugin therefore its package 
>>> name shall be ‘com.taobao.weex'.
>>> Users can choose whichever the above connivence library they’d like.
>>> 
>>> 
>>>> 在 2019年9月18日，02:56，Jan Piotrowski  写道：
>>>> 
>>>> Sounds good.
>>>> 
>>>>> weex_sdk will be compiled using the gradle-plugin mentioned above, while 
>>>>> weex_sdk_legacy will not.
>>>> 
>>>> Don't you mean the other one around? The legacy one should be built
>>>> using the plugin, leading to the class names being replaced with the
>>>> old ones.
>>>> 
>>>> -J
>>>> 
>>>> Am Di., 17. Sept. 2019 um 13:56 Uhr schrieb York Shen 
>>>> mailto:shenyua...@gmail.com>>:
>>>>> 
>>>>> Hi, community
>>>>> 
>>>>> Due to the restriction of Java language in method overriding [1], the 
>>>>> solution I proposed months ago will not provide backwards-compatibility 
>>>>> as expected but produce compiling error for users.
>>>>> 
>>>>> Therefore, I’d like to proposal a new solution to fix the problem.
>>>>> 
>>>>> Package name will be renamed from 'com.taobao.weex' to 'org.apache.weex' 
>>>>> in source code and Apache Source Release as the previous plan.
>>>>> Create a custom gradle-plugin which could rename package back to 
>>>>> ‘com.taobao.weex’ at compiling time.
>>>>> Publish two build variants (weex_sdk and weex_sdk_legacy) each time 
>>>>> building connivence library. weex_sdk will be compiled using the 
>>>>> gradle-plugin mentioned above, while weex_sdk_legacy will not.
>>>>> Therefore, classes in weex_sdk will be under ‘org.apache.weex' package, 
>>>>> and classes in weex_sdk_legacy will be under ‘com.taobao.weex’.
>>>>> New users of weex should choose weex_sdk and new API, while current users 
>>>>> could continue using weex_sdk_legacy which provide the same API behavior 
>>>>> as now.
>>>>> Finally, we would stop publishing weex_sdk_legacy sometime later.
>>>>> 
>>>>> The community could benefit from the above solution in following aspects:
>>>>> For me, there is much less work to do in current plan than the old one. 
>>>>> Less bug to write, less time to use. One or two weeks will be enough.
>>>>> For users, There is a guarantee that the API behavior of weex_sdk_legacy 
>>>>> is the same as before because the source code after processing of 
>>>>> gradle-plugin is the same as before. The old plan won’t give this 
>>>>> guarantee.
>>>>> We make our position very clear by naming the connivence binary to 
>>>>> weex_sdk_legacy .
>>>>> 
>>>>> [1] "When overriding a method, the signatures (name and argument types) 
>>>>> have to be the same after type erasure." Ref 
>>>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2 
>>>>> <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2> 
>>>>> <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2 
>>>>> <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2>> 
>>>>> for detail.
>>>>> 
>>>>> Best Regards,
>>>>> York Shen
>>>>> 
>>>>> 申远
>>>>> 
>>>>>> 在 2019年7月1日，16:26，Jan Piotrowski >>>>> <mailto:piotrow...@gmail.com>> 写道：
>>>>>> 
>>>>>> Sounds pretty neat and was pretty much what I was thinking of.
>>>>>> 
>>>>>> Th
>>> 

Re: [DISCUSS] Package name in Java code

[York Shen]

Finally, every Java source code is under org.apache.weex [1].

I shall rewrite script related to publishing connivence binary later to enable 
legacy connivence binary, but that’s another story. For Apache release part, we 
are good after the PR is merged.

[1] https://github.com/apache/incubator-weex/pull/2885 
<https://github.com/apache/incubator-weex/pull/2885>

Best Regards,
York Shen

申远

> 在 2019年9月18日，15:25，Jan Piotrowski  写道：
> 
> Exactly, that is the opposite of what your original email said ;)
> 
>> weex_sdk will be compiled using the gradle-plugin mentioned above, while 
>> weex_sdk_legacy will not.
> 
> But I understand now and agree with your suggestion.
> 
> J
> 
> Am Mi., 18. Sept. 2019 um 04:40 Uhr schrieb York Shen  <mailto:shenyua...@gmail.com>>:
>> 
>> Nope.
>> 
>> The class name in source code(.java) will be ‘org.apache.weex’, as this is 
>> the right thing to do, IMO. The apache source code release will be under 
>> ‘org.apache.weex’ as well.
>> The weex_sdk will be built without the plugin therefore its package name 
>> shall also be 'org.apache.weex'.
>> The weex_sdk_legacy will be built with the plugin therefore its package name 
>> shall be ‘com.taobao.weex'.
>> Users can choose whichever the above connivence library they’d like.
>> 
>> 
>>> 在 2019年9月18日，02:56，Jan Piotrowski  写道：
>>> 
>>> Sounds good.
>>> 
>>>> weex_sdk will be compiled using the gradle-plugin mentioned above, while 
>>>> weex_sdk_legacy will not.
>>> 
>>> Don't you mean the other one around? The legacy one should be built
>>> using the plugin, leading to the class names being replaced with the
>>> old ones.
>>> 
>>> -J
>>> 
>>> Am Di., 17. Sept. 2019 um 13:56 Uhr schrieb York Shen >> <mailto:shenyua...@gmail.com> <mailto:shenyua...@gmail.com 
>>> <mailto:shenyua...@gmail.com>>>:
>>>> 
>>>> Hi, community
>>>> 
>>>> Due to the restriction of Java language in method overriding [1], the 
>>>> solution I proposed months ago will not provide backwards-compatibility as 
>>>> expected but produce compiling error for users.
>>>> 
>>>> Therefore, I’d like to proposal a new solution to fix the problem.
>>>> 
>>>> Package name will be renamed from 'com.taobao.weex' to 'org.apache.weex' 
>>>> in source code and Apache Source Release as the previous plan.
>>>> Create a custom gradle-plugin which could rename package back to 
>>>> ‘com.taobao.weex’ at compiling time.
>>>> Publish two build variants (weex_sdk and weex_sdk_legacy) each time 
>>>> building connivence library. weex_sdk will be compiled using the 
>>>> gradle-plugin mentioned above, while weex_sdk_legacy will not.
>>>> Therefore, classes in weex_sdk will be under ‘org.apache.weex' package, 
>>>> and classes in weex_sdk_legacy will be under ‘com.taobao.weex’.
>>>> New users of weex should choose weex_sdk and new API, while current users 
>>>> could continue using weex_sdk_legacy which provide the same API behavior 
>>>> as now.
>>>> Finally, we would stop publishing weex_sdk_legacy sometime later.
>>>> 
>>>> The community could benefit from the above solution in following aspects:
>>>> For me, there is much less work to do in current plan than the old one. 
>>>> Less bug to write, less time to use. One or two weeks will be enough.
>>>> For users, There is a guarantee that the API behavior of weex_sdk_legacy 
>>>> is the same as before because the source code after processing of 
>>>> gradle-plugin is the same as before. The old plan won’t give this 
>>>> guarantee.
>>>> We make our position very clear by naming the connivence binary to 
>>>> weex_sdk_legacy .
>>>> 
>>>> [1] "When overriding a method, the signatures (name and argument types) 
>>>> have to be the same after type erasure." Ref 
>>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2 
>>>> <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2> 
>>>> <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2 
>>>> <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2>> 
>>>> <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2 
>>>> <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2> 
>>>> <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2 
>>>> <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2>>> 
>>>> for detail.
>>>> 
>>>> Best Regards,
>>>> York Shen
>>>> 
>>>> 申远
>>>> 
>>>>> 在 2019年7月1日，16:26，Jan Piotrowski >>>> <mailto:piotrow...@gmail.com> <mailto:piotrow...@gmail.com 
>>>>> <mailto:piotrow...@gmail.com>>> 写道：
>>>>> 
>>>>> Sounds pretty neat and was pretty much what I was thinking of.
>>>>> 
>>>>> Th

Re: [DISCUSS] [iOS] Apple Announcement of HTML5 Apps

[York Shen]

Agreed, this post is much clear. I’d like to summarize it in a similar way, 
"This update has nothing to do with Weex Apps, but Apps that people try to load 
from a remote server. Try not to load code from a server if your App(s) falls 
into the case mentioned above”.

Best Regards,
York Shen

申远

> 在 2019年9月19日，05:41，Jan Piotrowski  写道：
> 
> I like Ionic's take on this:
> https://ionicframework.com/blog/making-sense-of-apples-tos/
> 
> Am Mi., 18. Sept. 2019 um 16:23 Uhr schrieb York Shen :
>> 
>> Hi, there.
>> 
>> I noticed Apple announced new policy [1] on HTML5 Apps weeks ago. Through 
>> which Apple makes it position very clear:
>> 
>> "Apps may contain or run code that is not embedded in the binary (e.g. 
>> HTML5-based games, bots, etc.), as long as code distribution isn’t the main 
>> purpose of the app, the code is not offered in a store or store-like 
>> interface, and provided that the software….
>> (4) does not provide access to real money gaming, lotteries, or charitable 
>> donations; (5) adheres to the terms of these App Review Guidelines (e.g. 
>> does not include objectionable content); and (6) does not support digital 
>> commerce."  [2]
>> 
>> Though Weex provides the ability of downloading JavaScriptCode from a 
>> server, you might consider not doing this and embeding the JavaScript code 
>> in your binary of the software if your App falls into any of the above 
>> category.
>> 
>> Please read the following links carefully and the due day to implement the 
>> above guideline provided by Apple for existing Apps provided is March 3, 
>> 2020.
>> 
>> [1] https://developer.apple.com/news/?id=09062019b 
>> <https://developer.apple.com/news/?id=09062019b>
>> [2] 
>> https://developer.apple.com/app-store/review/guidelines/#third-party-software
>>  
>> <https://developer.apple.com/app-store/review/guidelines/#third-party-software>
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远
>> 

[DISCUSS] [iOS] Apple Announcement of HTML5 Apps

[York Shen]

Hi, there.

I noticed Apple announced new policy [1] on HTML5 Apps weeks ago. Through which 
Apple makes it position very clear:

"Apps may contain or run code that is not embedded in the binary (e.g. 
HTML5-based games, bots, etc.), as long as code distribution isn’t the main 
purpose of the app, the code is not offered in a store or store-like interface, 
and provided that the software….
(4) does not provide access to real money gaming, lotteries, or charitable 
donations; (5) adheres to the terms of these App Review Guidelines (e.g. does 
not include objectionable content); and (6) does not support digital commerce." 
 [2]

Though Weex provides the ability of downloading JavaScriptCode from a server, 
you might consider not doing this and embeding the JavaScript code in your 
binary of the software if your App falls into any of the above category.

Please read the following links carefully and the due day to implement the 
above guideline provided by Apple for existing Apps provided is March 3, 2020.

[1] https://developer.apple.com/news/?id=09062019b 
<https://developer.apple.com/news/?id=09062019b>
[2] 
https://developer.apple.com/app-store/review/guidelines/#third-party-software 
<https://developer.apple.com/app-store/review/guidelines/#third-party-software>

Best Regards,
York Shen

申远

Re: [DISCUSS] Package name in Java code

[York Shen]

Nope.

The class name in source code(.java) will be ‘org.apache.weex’, as this is the 
right thing to do, IMO. The apache source code release will be under 
‘org.apache.weex’ as well.
The weex_sdk will be built without the plugin therefore its package name shall 
also be 'org.apache.weex'.
The weex_sdk_legacy will be built with the plugin therefore its package name 
shall be ‘com.taobao.weex'.
Users can choose whichever the above connivence library they’d like.


> 在 2019年9月18日，02:56，Jan Piotrowski  写道：
> 
> Sounds good.
> 
>> weex_sdk will be compiled using the gradle-plugin mentioned above, while 
>> weex_sdk_legacy will not.
> 
> Don't you mean the other one around? The legacy one should be built
> using the plugin, leading to the class names being replaced with the
> old ones.
> 
> -J
> 
> Am Di., 17. Sept. 2019 um 13:56 Uhr schrieb York Shen  <mailto:shenyua...@gmail.com>>:
>> 
>> Hi, community
>> 
>> Due to the restriction of Java language in method overriding [1], the 
>> solution I proposed months ago will not provide backwards-compatibility as 
>> expected but produce compiling error for users.
>> 
>> Therefore, I’d like to proposal a new solution to fix the problem.
>> 
>> Package name will be renamed from 'com.taobao.weex' to 'org.apache.weex' in 
>> source code and Apache Source Release as the previous plan.
>> Create a custom gradle-plugin which could rename package back to 
>> ‘com.taobao.weex’ at compiling time.
>> Publish two build variants (weex_sdk and weex_sdk_legacy) each time building 
>> connivence library. weex_sdk will be compiled using the gradle-plugin 
>> mentioned above, while weex_sdk_legacy will not.
>> Therefore, classes in weex_sdk will be under ‘org.apache.weex' package, and 
>> classes in weex_sdk_legacy will be under ‘com.taobao.weex’.
>> New users of weex should choose weex_sdk and new API, while current users 
>> could continue using weex_sdk_legacy which provide the same API behavior as 
>> now.
>> Finally, we would stop publishing weex_sdk_legacy sometime later.
>> 
>> The community could benefit from the above solution in following aspects:
>> For me, there is much less work to do in current plan than the old one. Less 
>> bug to write, less time to use. One or two weeks will be enough.
>> For users, There is a guarantee that the API behavior of weex_sdk_legacy is 
>> the same as before because the source code after processing of gradle-plugin 
>> is the same as before. The old plan won’t give this guarantee.
>> We make our position very clear by naming the connivence binary to 
>> weex_sdk_legacy .
>> 
>> [1] "When overriding a method, the signatures (name and argument types) have 
>> to be the same after type erasure." Ref 
>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2 
>> <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2> 
>> <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2 
>> <https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2>> 
>> for detail.
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远
>> 
>>> 在 2019年7月1日，16:26，Jan Piotrowski >> <mailto:piotrow...@gmail.com>> 写道：
>>> 
>>> Sounds pretty neat and was pretty much what I was thinking of.
>>> 
>>> Th

Re: [DISCUSS] Package name in Java code

[York Shen]

Hi, community

Due to the restriction of Java language in method overriding [1], the solution 
I proposed months ago will not provide backwards-compatibility as expected but 
produce compiling error for users. 

Therefore, I’d like to proposal a new solution to fix the problem.

Package name will be renamed from 'com.taobao.weex' to 'org.apache.weex' in 
source code and Apache Source Release as the previous plan.
Create a custom gradle-plugin which could rename package back to 
‘com.taobao.weex’ at compiling time.
Publish two build variants (weex_sdk and weex_sdk_legacy) each time building 
connivence library. weex_sdk will be compiled using the gradle-plugin mentioned 
above, while weex_sdk_legacy will not.
Therefore, classes in weex_sdk will be under ‘org.apache.weex' package, and 
classes in weex_sdk_legacy will be under ‘com.taobao.weex’.
New users of weex should choose weex_sdk and new API, while current users could 
continue using weex_sdk_legacy which provide the same API behavior as now.
Finally, we would stop publishing weex_sdk_legacy sometime later.

The community could benefit from the above solution in following aspects:
For me, there is much less work to do in current plan than the old one. Less 
bug to write, less time to use. One or two weeks will be enough.
For users, There is a guarantee that the API behavior of weex_sdk_legacy is the 
same as before because the source code after processing of gradle-plugin is the 
same as before. The old plan won’t give this guarantee.
We make our position very clear by naming the connivence binary to 
weex_sdk_legacy .

[1] "When overriding a method, the signatures (name and argument types) have to 
be the same after type erasure." Ref 
https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2 
<https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2> for 
detail.

Best Regards,
York Shen

申远

> 在 2019年7月1日，16:26，Jan Piotrowski  写道：
> 
> Sounds pretty neat and was pretty much what I was thinking of.
> 
> Th

Re: Errored: apache/incubator-weex-playground#41 (master - 1f536fa)

[York Shen]

It seems like there is some network error in Travis server. Anyway, the build 
is good now.

> 在 2019年9月17日，11:38，Travis CI  写道：
> 
> Build Update for apache/incubator-weex-playground
> -
> 
> Build: #41
> Status: Errored
> 
> Duration: 6 mins and 52 secs
> Commit: 1f536fa (master)
> Author: chen
> Message: [Android]build fix (#18)
> 
> View the changeset: 
> https://github.com/apache/incubator-weex-playground/compare/84b82365466c...1f536fa83893
> 
> View the full build log and details: 
> https://travis-ci.org/apache/incubator-weex-playground/builds/585876851?utm_medium=notification_source=email
> 
> --
> 
> You can unsubscribe from build emails from the 
> apache/incubator-weex-playground repository going to 
> https://travis-ci.org/account/preferences/unsubscribe?repository=25215058_medium=notification_source=email.
> Or unsubscribe from *all* email updating your settings at 
> https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email.
> Or configure specific recipients for build notifications in your .travis.yml 
> file. See https://docs.travis-ci.com/user/notifications.
> 

Re: Errored: apache/incubator-weex#6621 (feature/master_ab_new - e9680b9)

[York Shen]

The related feature branch and PR is deleted for good, no need to worry about 
it.

> 在 2019年9月16日，18:06，Travis CI  写道：
> 
> Build Update for apache/incubator-weex
> -
> 
> Build: #6621
> Status: Errored
> 
> Duration: 2 mins and 51 secs
> Commit: e9680b9 (feature/master_ab_new)
> Author: chen
> Message: [Android] tmp
> 
> View the changeset: 
> https://github.com/apache/incubator-weex/compare/24085a2139d0...e9680b9c7313
> 
> View the full build log and details: 
> https://travis-ci.org/apache/incubator-weex/builds/585500528?utm_medium=notification_source=email
> 
> --
> 
> You can unsubscribe from build emails from the apache/incubator-weex 
> repository going to 
> https://travis-ci.org/account/preferences/unsubscribe?repository=11562877_medium=notification_source=email.
> Or unsubscribe from *all* email updating your settings at 
> https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email.
> Or configure specific recipients for build notifications in your .travis.yml 
> file. See https://docs.travis-ci.com/user/notifications.
> 

[Result][Vote] Accepting donation of weex-loader

[York Shen]

Hi, all

The vote for accepting donation of weex-loader has now closed. The results are 
listed below:

Vote Result:
1 (+1 binding) (From Jan Piotrowski)
0 (0 binding)
0 (-1 binding)

And no non-binding votes.

IP clearance is based on lazy-consensus, therefore the vote is successful.

Voting thread: 
https://mail-archives.apache.org/mod_mbox/weex-dev/201909.mbox/%3C310836C0-10DE-4A0E-8C7B-989055D8A603%40gmail.com%3E
 
<https://mail-archives.apache.org/mod_mbox/weex-dev/201909.mbox/%3c310836c0-10de-4a0e-8c7b-989055d8a...@gmail.com%3E>

Best Regards,
York Shen

申远

Re: [Vote] [IP Clearance] Accepting donation of Weex-loader

[York Shen]

The vote is closed now, I shall post the result in another thread.

FYI: I am currently trying to get SGA singed from corresponding cooperation, 
which may take several days. After that, weex-loader could be part of Apache 
Weex formally.

Best Regards,
York Shen

申远

> 在 2019年9月12日，03:43，Jan Piotrowski  写道：
> 
> +1
> 
> Am Mi., 11. Sept. 2019 um 10:37 Uhr schrieb York Shen  <mailto:shenyua...@gmail.com>>:
>> 
>> Hi, community
>> 
>> The community of weex-loader [1], some of whose contributors are also 
>> committers of Apache Weex recently proposed to make their code donated to 
>> ASF with Incubator-Weex as receiving PPMC.
>> 
>> "weex-loader is a loader of webpack that can transform *.vue file into a 
>> plain javascript module for Android and iOS platform."
>> 
>> According to my knowledge, with “weex-loader” and "CLI-for-Apache-Weex” 
>> donated to Weex PPMC, we will resolve the branding/outside-code issues for 
>> good [3] . All the essential tools for compiling and running Weex will be 
>> under ASF and they will be able to call themself Apache-Weex-.
>> 
>> As the donation is exactly what Weex Community needs, I am calling this vote 
>> for IP Clearance purpose.Again, it’s not necessary to go through IP 
>> Clearance process for Incubating projects, there is no harm to do so.
>> 
>> Voting ends three days from today, i.e. Sep, 14th, 2019 at 9:0:0 AM (UTC 
>> time) [4].
>> 
>> +1 for Yes I agree
>> 0 for I have no strong opinion
>> -1 for I object on the a specific grounds
>> 
>> FYI: IP Clearance is based on lazy consensus, but everyone is welcomed to 
>> vote on this thread.
>> 
>> [1] https://github.com/weexteam/weex-loader 
>> <https://github.com/weexteam/weex-loader> 
>> <https://github.com/weexteam/weex-loader 
>> <https://github.com/weexteam/weex-loader>>
>> [2] https://github.com/weexteam/CLI-for-Apache-Weex 
>> <https://github.com/weexteam/CLI-for-Apache-Weex> 
>> <https://github.com/weexteam/CLI-for-Apache-Weex 
>> <https://github.com/weexteam/CLI-for-Apache-Weex>>
>> [3] 
>> https://mail-archives.apache.org/mod_mbox/weex-dev/201901.mbox/%3C91448AB4-A929-4BE1-9541-BD7A7DEA5A1A%40gmail.com%3E
>>  
>> <https://mail-archives.apache.org/mod_mbox/weex-dev/201901.mbox/%3C91448AB4-A929-4BE1-9541-BD7A7DEA5A1A%40gmail.com%3E>
>>  
>> <https://mail-archives.apache.org/mod_mbox/weex-dev/201901.mbox/%3c91448ab4-a929-4be1-9541-bd7a7dea5...@gmail.com%3E
>>  
>> <https://mail-archives.apache.org/mod_mbox/weex-dev/201901.mbox/%3c91448ab4-a929-4be1-9541-bd7a7dea5...@gmail.com%3E>>
>> [4] 
>> https://www.timeanddate.com/countdown/generic?iso=20190914T09=1440=Countdown+=cursive
>>  
>> <https://www.timeanddate.com/countdown/generic?iso=20190914T09=1440=Countdown+=cursive>
>>  
>> <https://www.timeanddate.com/countdown/generic?iso=20190914T09=1440=Countdown+=cursive
>>  
>> <https://www.timeanddate.com/countdown/generic?iso=20190914T09=1440=Countdown+=cursive>>
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远

[Vote] [IP Clearance] Accepting donation of Weex-loader

[York Shen]

Hi, community

The community of weex-loader [1], some of whose contributors are also 
committers of Apache Weex recently proposed to make their code donated to ASF 
with Incubator-Weex as receiving PPMC. 

"weex-loader is a loader of webpack that can transform *.vue file into a plain 
javascript module for Android and iOS platform."

According to my knowledge, with “weex-loader” and "CLI-for-Apache-Weex” donated 
to Weex PPMC, we will resolve the branding/outside-code issues for good [3] . 
All the essential tools for compiling and running Weex will be under ASF and 
they will be able to call themself Apache-Weex-.

As the donation is exactly what Weex Community needs, I am calling this vote 
for IP Clearance purpose.Again, it’s not necessary to go through IP Clearance 
process for Incubating projects, there is no harm to do so.

Voting ends three days from today, i.e. Sep, 14th, 2019 at 9:0:0 AM (UTC time) 
[4].

+1 for Yes I agree
0 for I have no strong opinion 
-1 for I object on the a specific grounds

FYI: IP Clearance is based on lazy consensus, but everyone is welcomed to vote 
on this thread.

[1] https://github.com/weexteam/weex-loader 
<https://github.com/weexteam/weex-loader>
[2] https://github.com/weexteam/CLI-for-Apache-Weex 
<https://github.com/weexteam/CLI-for-Apache-Weex>
[3] 
https://mail-archives.apache.org/mod_mbox/weex-dev/201901.mbox/%3C91448AB4-A929-4BE1-9541-BD7A7DEA5A1A%40gmail.com%3E
 
<https://mail-archives.apache.org/mod_mbox/weex-dev/201901.mbox/%3c91448ab4-a929-4be1-9541-bd7a7dea5...@gmail.com%3E>
[4] 
https://www.timeanddate.com/countdown/generic?iso=20190914T09=1440=Countdown+=cursive
 
<https://www.timeanddate.com/countdown/generic?iso=20190914T09=1440=Countdown+=cursive>

Best Regards,
York Shen

申远

Re: [Announcement] New committer: Renmin Wang

[York Shen]

Your apache ID is created successfully, you could bind [1]  your Apache ID and 
Github ID now, which will give you write privilege in Github.

Feel free to ask if you have any other questions.

[1] https://servicecomb.apache.org/developers/setup-committer-rights/ 
<https://servicecomb.apache.org/developers/setup-committer-rights/>

Best Regards,
York Shen

申远

> 在 2019年8月27日，14:26，申远  写道：
> 
> Last step, visit Gitbox [1] to link your Github account and Apache ID, so 
> that you will have write privilege to the git repo of  Weex.
> 
> PS: You probably need to wait several hours after you submitted linking 
> application in gitbox..
> 
> [1] https://gitbox.apache.org/ <https://gitbox.apache.org/>
> Best Regards,
> YorkShen
> 
> 申远
> 
> 
> 王仁敏 mailto:wrmwindm...@gmail.com>> 于2019年8月27日周二 
> 下午12:46写道：
> I am very happy to be a weex commiter, and wish weex gets better and better 
> with the efforts of the community. 王仁敏 邮箱：wrmwindm...@gmail.com 
> <mailto:wrmwindm...@gmail.com> 签名由 网易邮箱大师 定制 On 08/27/2019 12:14, 申远 wrote: 
> The Podling Project Management Committee (PPMC) for Apache Weex has invited 
> Peihan Chen to become a committer and we are pleased to announce that he has 
> accepted. Renming Wang has passions and ability in mobile developing and 
> participated deeply into the Weex community. He has helped us decoupled 
> weex_sdk and playground to two repos and build a static check mechanism on 
> Travis. Currently he is focusing on developing end to end test framework for 
> Weex. Below is parts of his commit:   1. 
> https://github.com/apache/incubator-weex/pull/2709 
> <https://github.com/apache/incubator-weex/pull/2709> Decoupling   weex_sdk 
> and playground   2. https://github.com/apache/incubator-weex/pull/2731 
> <https://github.com/apache/incubator-weex/pull/2731> Adding OCLint and   
> Android Lint, there is over a hundred commit as pushing a commit is the   
> only way to debugging TravisCI   3. 
> https://github.com/apache/incubator-weex/pull/2676 
> <https://github.com/apache/incubator-weex/pull/2676> Enable danger. Best 
> Regards, YorkShen 申远

[Result][Vote] Accept donation of CLI-for-Apache-Weex

[York Shen]

Hi, all

The vote for accepting donation of CLI-for-Apache-Weex has now closed. The 
results are listed below:

Vote Result:
1 (+1 binding) (From Jan Piotrowski)
0 (0 binding)
0 (-1 binding)

And no non-binding votes.

IP clearance is based on lazy-consensus, therefore the vote is successful.

Voting thread: 
https://mail-archives.apache.org/mod_mbox/weex-dev/201909.mbox/%3CE5242742-462B-48D1-8B3F-749A33C4ED3A%40gmail.com%3E
 
<https://mail-archives.apache.org/mod_mbox/weex-dev/201909.mbox/%3ce5242742-462b-48d1-8b3f-749a33c4e...@gmail.com%3E>

Best Regards,
York Shen

申远

Re: [IP Clearance] [Vote] Accept donation of CLI-for-Apache-Weex

[York Shen]

The vote is closed now, I shall post the result in another thread.

> 在 2019年9月4日，15:38，Jan Piotrowski  写道：
> 
> +1!
> 
> Am Mi., 4. Sept. 2019 um 09:15 Uhr schrieb York Shen  <mailto:shenyua...@gmail.com>>:
>> 
>> Hi, all
>> 
>> The community of CLI-for-Apache-Weex [1], which is known as weex-cli or 
>> weex-toolkit recently proposed to make their code donated to ASF with 
>> Incubator-Weex as receiving PPMC.
>> 
>> "CLI-for-Apache-Weex is dedicated to standardizing the tool base in the Weex 
>> ecosystem. It ensures that various build tools can be seamlessly connected 
>> based on smart default configuration, so you can focus on writing 
>> applications without having to spend days tangling configuration issues. "
>> 
>> From what I knew, they intended to make the donation to ASF months ago but 
>> finally gave up due to the uncertainty about who actually owns the code, 
>> their company or individuals. So they changed their name to avoid branding 
>> issue. While this time, they are going to provide ICLA from individuals and 
>> SGA from their employee to solve the uncertainty. Considering their employee 
>> also signed a CCLA [3] with ASF years before for Weex project, I think this 
>> is enough for solving the problem as all possible code owner agreed to make 
>> the donation. In return, CLI-for-Apache-Weex could be named to Weex-CLI back 
>> after the donation.
>> 
>> As the donation will benefit Weex community for good, I am calling this vote 
>> for IP Clearance purpose. Though it’s not necessary to go through IP 
>> Clearance process for Incubating projects [2], there is no harm to do so.
>> 
>> Voting ends three days from today, i.e. Sep, 7th, 2019 at 0:0:0 AM (UTC 
>> time) [4].
>> 
>> +1 for Yes I agree
>> 0 for I have no strong opinion
>> -1 for I object on the a specific grounds
>> 
>> FYI: IP Clearance is typically based on lazy consensus, but everyone is 
>> welcomed to vote on this thread.
>> 
>> [1] https://github.com/weexteam/CLI-for-Apache-Weex 
>> <https://github.com/weexteam/CLI-for-Apache-Weex> 
>> <https://github.com/weexteam/CLI-for-Apache-Weex 
>> <https://github.com/weexteam/CLI-for-Apache-Weex>>
>> [2] 
>> https://lists.apache.org/thread.html/f5e1f82e67e5e5cbc6a7b7fbbb9a1d07e27c4373547d9961c4cd5730@%3Cgeneral.incubator.apache.org%3E
>>  
>> <https://lists.apache.org/thread.html/f5e1f82e67e5e5cbc6a7b7fbbb9a1d07e27c4373547d9961c4cd5730@%3Cgeneral.incubator.apache.org%3E><https://lists.apache.org/thread.html/f5e1f82e67e5e5cbc6a7b7fbbb9a1d07e27c4373547d9961c4cd5730@%3Cgeneral.incubator.apache.org%3E
>>  
>> <https://lists.apache.org/thread.html/f5e1f82e67e5e5cbc6a7b7fbbb9a1d07e27c4373547d9961c4cd5730@%3Cgeneral.incubator.apache.org%3E>>
>> [3] 
>> https://lists.apache.org/thread.html/5fb8b88ccce1edbb66382f739a4138d9583c09327c302e915b1b2b20@%3Cprivate.weex.apache.org%3E
>>  
>> <https://lists.apache.org/thread.html/5fb8b88ccce1edbb66382f739a4138d9583c09327c302e915b1b2b20@%3Cprivate.weex.apache.org%3E><https://lists.apache.org/thread.html/5fb8b88ccce1edbb66382f739a4138d9583c09327c302e915b1b2b20@%3Cprivate.weex.apache.org%3E
>>  
>> <https://lists.apache.org/thread.html/5fb8b88ccce1edbb66382f739a4138d9583c09327c302e915b1b2b20@%3Cprivate.weex.apache.org%3E>>
>> [4] 
>> https://www.timeanddate.com/countdown/generic?iso=20190907T00=283=Countdown+Timer=cursive
>>  
>> <https://www.timeanddate.com/countdown/generic?iso=20190907T00=283=Countdown+Timer=cursive>
>>  
>> <https://www.timeanddate.com/countdown/generic?iso=20190907T00=283=Countdown+Timer=cursive
>>  
>> <https://www.timeanddate.com/countdown/generic?iso=20190907T00=283=Countdown+Timer=cursive>>
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远

Re: [DISCUSS] Maven account to publish connivence binary

[York Shen]

Just found the answer. It seems like Apache Cordova has an individual JCenter 
account [1], we just need to follow the pattern of Cordova.

[1] https://bintray.com/cordova/maven/cordova-android 
<https://bintray.com/cordova/maven/cordova-android>

Best Regards,
York Shen

申远

> 在 2019年9月6日，11:56，York Shen  写道：
> 
> Hi, Community
> 
> While I am trying to rename Android package name to ‘org.apache', I found 
> Weex used to publish its Android connivence binary to JCenter with the 
> groupID of com.taobao [1] under an individual account [2].  I’d like to know 
> whether there is an Apache-wide JCenter account for publishing connivence 
> binary or it’s OK to use an individual account for publishing as long as it’s 
> controlled by PPMC. Besides, I’d like to know whether there is a restriction 
> in choice Maven repo by ASF as I’d like to use JCenter instead of Maven 
> Central to publish connivence binary as JCenter is basically the standard 
> maven repo for Android developers.
> 
> Of course I will rename the groupId of the binary to ‘org.apache’ after 
> finishing my refactoring.
> 
> [1] https://bintray.com/alibabaweex/maven/weex_sdk 
> <https://bintray.com/alibabaweex/maven/weex_sdk>
> [2] https://svn.apache.org/repos/private/pmc/incubator/weex/JCenter_key 
> <https://svn.apache.org/repos/private/pmc/incubator/weex/JCenter_key>
> 
> 
> Best Regards,
> York Shen
> 
> 申远
> 

[DISCUSS] Maven account to publish connivence binary

[York Shen]

Hi, Community

While I am trying to rename Android package name to ‘org.apache', I found Weex 
used to publish its Android connivence binary to JCenter with the groupID of 
com.taobao [1] under an individual account [2].  I’d like to know whether there 
is an Apache-wide JCenter account for publishing connivence binary or it’s OK 
to use an individual account for publishing as long as it’s controlled by PPMC. 
Besides, I’d like to know whether there is a restriction in choice Maven repo 
by ASF as I’d like to use JCenter instead of Maven Central to publish 
connivence binary as JCenter is basically the standard maven repo for Android 
developers.

Of course I will rename the groupId of the binary to ‘org.apache’ after 
finishing my refactoring.

[1] https://bintray.com/alibabaweex/maven/weex_sdk 
<https://bintray.com/alibabaweex/maven/weex_sdk>
[2] https://svn.apache.org/repos/private/pmc/incubator/weex/JCenter_key 
<https://svn.apache.org/repos/private/pmc/incubator/weex/JCenter_key>


Best Regards,
York Shen

申远

[IP Clearance] [Vote] Accept donation of CLI-for-Apache-Weex

[York Shen]

Hi, all

The community of CLI-for-Apache-Weex [1], which is known as weex-cli or 
weex-toolkit recently proposed to make their code donated to ASF with 
Incubator-Weex as receiving PPMC. 

"CLI-for-Apache-Weex is dedicated to standardizing the tool base in the Weex 
ecosystem. It ensures that various build tools can be seamlessly connected 
based on smart default configuration, so you can focus on writing applications 
without having to spend days tangling configuration issues. "

From what I knew, they intended to make the donation to ASF months ago but 
finally gave up due to the uncertainty about who actually owns the code, their 
company or individuals. So they changed their name to avoid branding issue. 
While this time, they are going to provide ICLA from individuals and SGA from 
their employee to solve the uncertainty. Considering their employee also signed 
a CCLA [3] with ASF years before for Weex project, I think this is enough for 
solving the problem as all possible code owner agreed to make the donation. In 
return, CLI-for-Apache-Weex could be named to Weex-CLI back after the donation. 

As the donation will benefit Weex community for good, I am calling this vote 
for IP Clearance purpose. Though it’s not necessary to go through IP Clearance 
process for Incubating projects [2], there is no harm to do so.

Voting ends three days from today, i.e. Sep, 7th, 2019 at 0:0:0 AM (UTC time) 
[4].

+1 for Yes I agree
0 for I have no strong opinion 
-1 for I object on the a specific grounds

FYI: IP Clearance is typically based on lazy consensus, but everyone is 
welcomed to vote on this thread.

[1] https://github.com/weexteam/CLI-for-Apache-Weex 
<https://github.com/weexteam/CLI-for-Apache-Weex>
[2] 
https://lists.apache.org/thread.html/f5e1f82e67e5e5cbc6a7b7fbbb9a1d07e27c4373547d9961c4cd5730@%3Cgeneral.incubator.apache.org%3E
 
<https://lists.apache.org/thread.html/f5e1f82e67e5e5cbc6a7b7fbbb9a1d07e27c4373547d9961c4cd5730@%3Cgeneral.incubator.apache.org%3E>
[3] 
https://lists.apache.org/thread.html/5fb8b88ccce1edbb66382f739a4138d9583c09327c302e915b1b2b20@%3Cprivate.weex.apache.org%3E
 
<https://lists.apache.org/thread.html/5fb8b88ccce1edbb66382f739a4138d9583c09327c302e915b1b2b20@%3Cprivate.weex.apache.org%3E>
[4] 
https://www.timeanddate.com/countdown/generic?iso=20190907T00=283=Countdown+Timer=cursive
 
<https://www.timeanddate.com/countdown/generic?iso=20190907T00=283=Countdown+Timer=cursive>

Best Regards,
York Shen

申远

Re: we found a crash bug in weex-0.26.0, please release 0.27 as soon as possible, please.

[York Shen]

See your emails in lots of places, let us discuss it here, shall we?

First of all, you can always compile from source, not using a release version. 
Our Github page is clear about this [1].

If you don’t like this idea, do it yourself and make a formal release on behalf 
of Weex community, I am happy to review your release. The procedure is also on 
the website [2].

If you don’t like the above ideas,  be patient and wait for next release. 

Please remember, you don’t pay me or other committers money (or do you?), and 
we are not working for you.

[1] https://github.com/apache/incubator-weex#android 
<https://github.com/apache/incubator-weex#android>
[2] 
https://weex.apache.org/guide/contribute/how-to-contribute.html#development-process
 
<https://weex.apache.org/guide/contribute/how-to-contribute.html#development-process>

Best Regards
York Shen

申远

> 在 2019年9月2日，10:34，HeChangPeng <571772...@qq.com> 写道：
> 
> we found a crash bug in weex-0.26.0, please release 0.27 as soon as possible, 
> thanks very much.

Re: Books about Weex

[York Shen]

Good Question.

If this is a joke, it’s a good one.

Well, translating a book with hundreds of pages into English is beyond my 
ability. I am afraid that I can’t help solving this problem.

Best Regards
York Shen

申远

> 在 2019年8月30日，15:29，Jan Piotrowski  写道：
> 
> Awesome, that is really quite an achievement!
> 
> So, who is going to translate it into English? ;)
> 
> J
> 
> Am Do., 29. Aug. 2019 um 09:37 Uhr schrieb York Shen :
>> 
>> Hi, community
>> 
>> I am happy to share some information with you guys. I just found a book [1] 
>> introducing Weex written in Chinese while I was searching some other stuff. 
>> I won’t comment on this book here, after all I didn’t know it existing until 
>> today. I think this is kind of proof that Weex is widely using in mobile 
>> development.
>> 
>> We just need to spend more time fixing graduation blocker issues [2]. We are 
>> really nearing graduating from the Incubator.
>> 
>> [1] https://item.jd.com/12677530.html <https://item.jd.com/12677530.html>
>> [2] https://cwiki.apache.org/confluence/display/WEEX/CheckList 
>> <https://cwiki.apache.org/confluence/display/WEEX/CheckList>
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远

Re: [ANNOUNCEMENT] Sauce Lab Enable

[York Shen]

Done

Best Regards,
York Shen

申远

> 在 2019年8月29日，15:21，Jan Piotrowski  写道：
> 
> haha, that's totally fine - as long as the account exists that way.
> added security :)
> 
> you might want to add a note to that file though that the gmail
> account actually has that misspelling, otherwise people might try to
> log in with it fixed.
> 
> J
> 
> Am Do., 29. Aug. 2019 um 08:50 Uhr schrieb York Shen :
>> 
>> Well, it’s actually my mis-spelling.
>> 
>> As I didn’t find a way to change the email address and the Sauce Lab team 
>> had promoted the account to 5 VMs before I found my mistake, I have no way 
>> but live with it.
>> 
>> 
>>> 在 2019年8月29日，14:44，Jan Piotrowski  写道：
>>> 
>>> Off list:
>>> The login emails seems to have a typo at
>>> https://svn.apache.org/repos/private/pmc/incubator/weex/SauceLab - is
>>> this intentional?
>>> 
>>> J
>>> 
>>> Am Do., 29. Aug. 2019 um 05:01 Uhr schrieb York Shen :
>>>> 
>>>> Hi, community
>>>> 
>>>> The Open Source account of Sauce Lab is enabled, one can access the 
>>>> corresponding user name and password [1] if he/she is a PPMC member. If 
>>>> any committer is interested in Test Framework running on Sauce Lab, please 
>>>> contact me personally to request the user name and password. As I didn’t 
>>>> find a way to create a page visible to both committers and PPMC members 
>>>> within ASF’s infrastructure, this is the best I can do now. Please let me 
>>>> know if there is a way to create a page visible to committers members 
>>>> together.
>>>> 
>>>> FYI: Weex Thanks page is online[2] now.
>>>> 
>>>> [1] https://svn.apache.org/repos/private/pmc/incubator/weex/SauceLab 
>>>> <https://svn.apache.org/repos/private/pmc/incubator/weex/SauceLab>
>>>> [2] https://weex.apache.org/thanks.html 
>>>> <https://weex.apache.org/thanks.html>
>>>> 
>>>> Best Regards,
>>>> York Shen
>>>> 
>>>> 申远
>> 

Books about Weex

[York Shen]

Hi, community

I am happy to share some information with you guys. I just found a book [1] 
introducing Weex written in Chinese while I was searching some other stuff. I 
won’t comment on this book here, after all I didn’t know it existing until 
today. I think this is kind of proof that Weex is widely using in mobile 
development. 

We just need to spend more time fixing graduation blocker issues [2]. We are 
really nearing graduating from the Incubator.

[1] https://item.jd.com/12677530.html <https://item.jd.com/12677530.html>
[2] https://cwiki.apache.org/confluence/display/WEEX/CheckList 
<https://cwiki.apache.org/confluence/display/WEEX/CheckList>

Best Regards,
York Shen

申远

Re: [ANNOUNCEMENT] Sauce Lab Enable

[York Shen]

Well, it’s actually my mis-spelling.

As I didn’t find a way to change the email address and the Sauce Lab team had 
promoted the account to 5 VMs before I found my mistake, I have no way but live 
with it.


> 在 2019年8月29日，14:44，Jan Piotrowski  写道：
> 
> Off list:
> The login emails seems to have a typo at
> https://svn.apache.org/repos/private/pmc/incubator/weex/SauceLab - is
> this intentional?
> 
> J
> 
> Am Do., 29. Aug. 2019 um 05:01 Uhr schrieb York Shen :
>> 
>> Hi, community
>> 
>> The Open Source account of Sauce Lab is enabled, one can access the 
>> corresponding user name and password [1] if he/she is a PPMC member. If any 
>> committer is interested in Test Framework running on Sauce Lab, please 
>> contact me personally to request the user name and password. As I didn’t 
>> find a way to create a page visible to both committers and PPMC members 
>> within ASF’s infrastructure, this is the best I can do now. Please let me 
>> know if there is a way to create a page visible to committers members 
>> together.
>> 
>> FYI: Weex Thanks page is online[2] now.
>> 
>> [1] https://svn.apache.org/repos/private/pmc/incubator/weex/SauceLab 
>> <https://svn.apache.org/repos/private/pmc/incubator/weex/SauceLab>
>> [2] https://weex.apache.org/thanks.html <https://weex.apache.org/thanks.html>
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远

Re: [DISCUSS] Prepare IP Clearance

[York Shen]

As I didn’t receive response from Legal JIRA so far, I shall move this to the 
mailing list of legal-discuss@apache

FYI: I’d really like to know which approach is the preferred when I have 
legal-related problems, legal mailing list or Legal JIRA.

> 在 2019年8月23日，15:29，Jan Piotrowski  写道：
> 
> Thanks for the quick response - I should have double checked that.
> 
> Then your email and plan make total sense. Let's hope it all works out!
> 
> Am Fr., 23. Aug. 2019 um 09:28 Uhr schrieb York Shen  <mailto:shenyua...@gmail.com>>:
>> 
>> My mistake. Let me rephrase myself.
>> 
>> First of all, code repos under essential tool may violate IP of ASF by using 
>> misleading names, and other names are fine.
>> 
>> However, other tools providing debugging and analyzer functions are very 
>> useful for the users of Weex, I’d like to persuade them to make a donation 
>> to ASF. If the owner of those tools don’t like the idea of donating, they 
>> can remain their status without any problem. Actually, weex_playground have 
>> a dependency for those tools, it would be great if they are part of ASF. Of 
>> course, that depends on the choice of owners of those tools.
>> 
>>> 在 2019年8月23日，15:11，Jan Piotrowski  写道：
>>> 
>>> Note from me as a private person, not an Apache Incubator mentor:
>>> I really don't understand why and how the names of "Useful, but not
>>> essential" are "violating the IP of ASF". I really dislike this
>>> position.
>>> "Apache Weex Android Devtools" would be problematic, but "Android
>>> Devtools for Apache Weex" is exactly what _I_ would rename my project
>>> into to avoid this problem.
>>> 
>>> :shrug:
>>> 
>>> J
>>> 
>>> Am Do., 22. Aug. 2019 um 13:03 Uhr schrieb York Shen >> <mailto:shenyua...@gmail.com> <mailto:shenyua...@gmail.com 
>>> <mailto:shenyua...@gmail.com>>>:
>>>> 
>>>> Hi, all
>>>> 
>>>> I spent some time these days figuring out essential tools around Weex 
>>>> Project as we talked before [1][2], and I am going to contact the owners 
>>>> of these tools to donate their IP to ASF in the following weeks. Here is 
>>>> what I found out, and you can also find this list on confluence [3] .
>>>> 
>>>> As there are around ten tools, I am going to start with essential tools. 
>>>> However, there are little chance that the owner of the related project 
>>>> refuse to donate their IP to Apache-Weex. If so, we shall persuade them to 
>>>> change the name of their repo as they are violating the IP of ASF. (I hope 
>>>> this would never happen).
>>>> 
>>>> Essential Tool
>>>> Essential tool for compiling source code.
>>>> weex-toolkit: a CLI tool including compiling function.
>>>> weex-loader: tools for compiling .vue files on Android/iOS platform
>>>> weex-vue-loader: tools for compiling .vue files on Android/iOS platform
>>>> 
>>>> Useful, but not essential
>>>> Some useful tools, for debugging, analyzing purpose.
>>>> Android
>>>> analyzer-of-android-for-Apache-Weex: a performance analyzer tool for Weex 
>>>> Android
>>>> android-devtools-for-Apache-Weex: a debugger tool for Weex Android
>>>> iOS
>>>> devtool-iOS-for-Apache-Weex: a performance analyzer tool for Weex iOS
>>>> analyzer-of-iOS-for-Apache-Weex: a debugger tool for Weex iOS
>>>> Node
>>>> weex-vue-render: tools for compiling .vue files on optional 
>>>> platform(Browser)
>>>> downgrade: tools for deciding whether enabling fallback to optional 
>>>> platform when rendering.
>>>> 
>>>> [1] 
>>>> https://lists.apache.org/thread.html/735b18910026c4597c3d3d9f44ad046d89fc2965fc993c82e5f956c7@%3Cdev.weex.apache.org%3E
>>>>  
>>>> <https://lists.apache.org/thread.html/735b18910026c4597c3d3d9f44ad046d89fc2965fc993c82e5f956c7@%3Cdev.weex.apache.org%3E><https://lists.apache.org/thread.html/735b18910026c4597c3d3d9f44ad046d89fc2965fc993c82e5f956c7@%3Cdev.weex.apache.org%3E
>>>>  
>>>> <https://lists.apache.org/thread.html/735b18910026c4597c3d3d9f44ad046d89fc2965fc993c82e5f956c7@%3Cdev.weex.apache.org%3E>><https://lists.apache.org/thread.html/735b18910026c4597c3d3d9f44ad046d89fc2965fc993c82e5f956c7@%3Cdev.weex.apache.org%3E
>>>>  
>>>> <https://lists.apache.org/thread.html/735b18910026c4597c3d3d9f44ad0

[ANNOUNCEMENT] Sauce Lab Enable

[York Shen]

Hi, community

The Open Source account of Sauce Lab is enabled, one can access the 
corresponding user name and password [1] if he/she is a PPMC member. If any 
committer is interested in Test Framework running on Sauce Lab, please contact 
me personally to request the user name and password. As I didn’t find a way to 
create a page visible to both committers and PPMC members within ASF’s 
infrastructure, this is the best I can do now. Please let me know if there is a 
way to create a page visible to committers members together.

FYI: Weex Thanks page is online[2] now.

[1] https://svn.apache.org/repos/private/pmc/incubator/weex/SauceLab 
<https://svn.apache.org/repos/private/pmc/incubator/weex/SauceLab>
[2] https://weex.apache.org/thanks.html <https://weex.apache.org/thanks.html>

Best Regards,
York Shen

申远

Re: [DISCUSS] Prepare IP Clearance

[York Shen]

My mistake. Let me rephrase myself.

First of all, code repos under essential tool may violate IP of ASF by using 
misleading names, and other names are fine. 

However, other tools providing debugging and analyzer functions are very useful 
for the users of Weex, I’d like to persuade them to make a donation to ASF. If 
the owner of those tools don’t like the idea of donating, they can remain their 
status without any problem. Actually, weex_playground have a dependency for 
those tools, it would be great if they are part of ASF. Of course, that depends 
on the choice of owners of those tools.

> 在 2019年8月23日，15:11，Jan Piotrowski  写道：
> 
> Note from me as a private person, not an Apache Incubator mentor:
> I really don't understand why and how the names of "Useful, but not
> essential" are "violating the IP of ASF". I really dislike this
> position.
> "Apache Weex Android Devtools" would be problematic, but "Android
> Devtools for Apache Weex" is exactly what _I_ would rename my project
> into to avoid this problem.
> 
> :shrug:
> 
> J
> 
> Am Do., 22. Aug. 2019 um 13:03 Uhr schrieb York Shen  <mailto:shenyua...@gmail.com>>:
>> 
>> Hi, all
>> 
>> I spent some time these days figuring out essential tools around Weex 
>> Project as we talked before [1][2], and I am going to contact the owners of 
>> these tools to donate their IP to ASF in the following weeks. Here is what I 
>> found out, and you can also find this list on confluence [3] .
>> 
>> As there are around ten tools, I am going to start with essential tools. 
>> However, there are little chance that the owner of the related project 
>> refuse to donate their IP to Apache-Weex. If so, we shall persuade them to 
>> change the name of their repo as they are violating the IP of ASF. (I hope 
>> this would never happen).
>> 
>> Essential Tool
>> Essential tool for compiling source code.
>> weex-toolkit: a CLI tool including compiling function.
>> weex-loader: tools for compiling .vue files on Android/iOS platform
>> weex-vue-loader: tools for compiling .vue files on Android/iOS platform
>> 
>> Useful, but not essential
>> Some useful tools, for debugging, analyzing purpose.
>> Android
>> analyzer-of-android-for-Apache-Weex: a performance analyzer tool for Weex 
>> Android
>> android-devtools-for-Apache-Weex: a debugger tool for Weex Android
>> iOS
>> devtool-iOS-for-Apache-Weex: a performance analyzer tool for Weex iOS
>> analyzer-of-iOS-for-Apache-Weex: a debugger tool for Weex iOS
>> Node
>> weex-vue-render: tools for compiling .vue files on optional platform(Browser)
>> downgrade: tools for deciding whether enabling fallback to optional platform 
>> when rendering.
>> 
>> [1] 
>> https://lists.apache.org/thread.html/735b18910026c4597c3d3d9f44ad046d89fc2965fc993c82e5f956c7@%3Cdev.weex.apache.org%3E
>>  
>> <https://lists.apache.org/thread.html/735b18910026c4597c3d3d9f44ad046d89fc2965fc993c82e5f956c7@%3Cdev.weex.apache.org%3E><https://lists.apache.org/thread.html/735b18910026c4597c3d3d9f44ad046d89fc2965fc993c82e5f956c7@%3Cdev.weex.apache.org%3E
>>  
>> <https://lists.apache.org/thread.html/735b18910026c4597c3d3d9f44ad046d89fc2965fc993c82e5f956c7@%3Cdev.weex.apache.org%3E>>
>> [2] 
>> https://lists.apache.org/thread.html/f83c5e806e2da97082102363db03f5b34b07242a336e20e982a26a2a@%3Cdev.weex.apache.org%3E
>>  
>> <https://lists.apache.org/thread.html/f83c5e806e2da97082102363db03f5b34b07242a336e20e982a26a2a@%3Cdev.weex.apache.org%3E><https://lists.apache.org/thread.html/f83c5e806e2da97082102363db03f5b34b07242a336e20e982a26a2a@%3Cdev.weex.apache.org%3E
>>  
>> <https://lists.apache.org/thread.html/f83c5e806e2da97082102363db03f5b34b07242a336e20e982a26a2a@%3Cdev.weex.apache.org%3E>>
>> [3] 
>> https://cwiki.apache.org/confluence/display/WEEX/CheckList#third-party-ip 
>> <https://cwiki.apache.org/confluence/display/WEEX/CheckList#third-party-ip> 
>> <https://cwiki.apache.org/confluence/display/WEEX/CheckList#third-party-ip 
>> <https://cwiki.apache.org/confluence/display/WEEX/CheckList#third-party-ip>>

Re: [DISCUSS] Prepare IP Clearance

[York Shen]

See https://issues.apache.org/jira/browse/LEGAL-474 
<https://issues.apache.org/jira/browse/LEGAL-474> for legal discussion.

FYI: weex-vue-loader may be not needed anymore, as it can be replaced by 
weex-loader. I will have a double check later.

> 在 2019年8月22日，19:03，York Shen  写道：
> 
> Hi, all
> 
> I spent some time these days figuring out essential tools around Weex Project 
> as we talked before [1][2], and I am going to contact the owners of these 
> tools to donate their IP to ASF in the following weeks. Here is what I found 
> out, and you can also find this list on confluence [3] .
> 
> As there are around ten tools, I am going to start with essential tools. 
> However, there are little chance that the owner of the related project refuse 
> to donate their IP to Apache-Weex. If so, we shall persuade them to change 
> the name of their repo as they are violating the IP of ASF. (I hope this 
> would never happen).
> 
> Essential Tool
> Essential tool for compiling source code.
> weex-toolkit: a CLI tool including compiling function.
> weex-loader: tools for compiling .vue files on Android/iOS platform
> weex-vue-loader: tools for compiling .vue files on Android/iOS platform
> 
> Useful, but not essential
> Some useful tools, for debugging, analyzing purpose.
> Android
> analyzer-of-android-for-Apache-Weex: a performance analyzer tool for Weex 
> Android
> android-devtools-for-Apache-Weex: a debugger tool for Weex Android
> iOS
> devtool-iOS-for-Apache-Weex: a performance analyzer tool for Weex iOS
> analyzer-of-iOS-for-Apache-Weex: a debugger tool for Weex iOS
> Node
> weex-vue-render: tools for compiling .vue files on optional platform(Browser)
> downgrade: tools for deciding whether enabling fallback to optional platform 
> when rendering.
> 
> [1] 
> https://lists.apache.org/thread.html/735b18910026c4597c3d3d9f44ad046d89fc2965fc993c82e5f956c7@%3Cdev.weex.apache.org%3E
>  
> <https://lists.apache.org/thread.html/735b18910026c4597c3d3d9f44ad046d89fc2965fc993c82e5f956c7@%3Cdev.weex.apache.org%3E>
> [2] 
> https://lists.apache.org/thread.html/f83c5e806e2da97082102363db03f5b34b07242a336e20e982a26a2a@%3Cdev.weex.apache.org%3E
>  
> <https://lists.apache.org/thread.html/f83c5e806e2da97082102363db03f5b34b07242a336e20e982a26a2a@%3Cdev.weex.apache.org%3E>
> [3] https://cwiki.apache.org/confluence/display/WEEX/CheckList#third-party-ip 
> <https://cwiki.apache.org/confluence/display/WEEX/CheckList#third-party-ip>

[DISCUSS] Prepare IP Clearance

[York Shen]

Hi, all

I spent some time these days figuring out essential tools around Weex Project 
as we talked before [1][2], and I am going to contact the owners of these tools 
to donate their IP to ASF in the following weeks. Here is what I found out, and 
you can also find this list on confluence [3] .

As there are around ten tools, I am going to start with essential tools. 
However, there are little chance that the owner of the related project refuse 
to donate their IP to Apache-Weex. If so, we shall persuade them to change the 
name of their repo as they are violating the IP of ASF. (I hope this would 
never happen).

Essential Tool
Essential tool for compiling source code.
weex-toolkit: a CLI tool including compiling function.
weex-loader: tools for compiling .vue files on Android/iOS platform
weex-vue-loader: tools for compiling .vue files on Android/iOS platform

Useful, but not essential
Some useful tools, for debugging, analyzing purpose.
Android
analyzer-of-android-for-Apache-Weex: a performance analyzer tool for Weex 
Android
android-devtools-for-Apache-Weex: a debugger tool for Weex Android
iOS
devtool-iOS-for-Apache-Weex: a performance analyzer tool for Weex iOS
analyzer-of-iOS-for-Apache-Weex: a debugger tool for Weex iOS
Node
weex-vue-render: tools for compiling .vue files on optional platform(Browser)
downgrade: tools for deciding whether enabling fallback to optional platform 
when rendering.

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

[2] 
https://lists.apache.org/thread.html/f83c5e806e2da97082102363db03f5b34b07242a336e20e982a26a2a@%3Cdev.weex.apache.org%3E
 

[3] https://cwiki.apache.org/confluence/display/WEEX/CheckList#third-party-ip 

Re: [DISCUSS] Add SauceLab to thanks page of Weex

[York Shen]

I have just created Thanks page[1], which lists Sauce Lab and other possible 
sponsor in the future.

[1] https://weex.apache.org/guide/contribute/thanks.html 
<https://weex.apache.org/guide/contribute/thanks.html>

> 在 2019年8月21日，00:12，王仁敏  写道：
> 
> That's great, I fully support adding SauceLab to Weex.
> 
> York Shen  于2019年8月20日周二 下午3:54写道：
> 
>> Hi, community.
>> 
>> I’d like to run Weex test case with emulator on SauceLab [1] as they
>> provide stable and fast emulator than TravisCI. When I am applying the open
>> source account of SauceLab, I am notified that I must list Sauce in Thanks
>> Page. According to what I know, ASF is OK with this thanks page if we
>> follow some rules [2].
>> 
>> So, I am going to list SauceLab in the thank page of Weex formally this
>> week if there is no objections.
>> 
>> [1]
>> https://mail-archives.apache.org/mod_mbox/weex-dev/201908.mbox/%3Cbae100d.5c0c.16ca3d9d9fd.Coremail.hnhtwrm%40163.com%3E
>> <https://mail-archives.apache.org/mod_mbox/weex-dev/201908.mbox/%3cbae100d.5c0c.16ca3d9d9fd.coremail.hnht...@163.com%3E>
>> [2] http://www.apache.org/foundation/marks/linking#projectthanks
>> 
>> 
>> 
>> 
>> 下面是被转发的邮件：
>> 
>> *发件人: *Bill McGee 
>> *主题: **Your Sauce Labs Open Sauce Account Request Has Been Approved*
>> *日期: *2019年8月20日 GMT+8 01:27:01
>> *收件人: *shenyua...@gmail.com
>> 
>> 
>> Hi Alex,
>> 
>> Thanks for your request - I have reviewed your repository and would like
>> to invite you to create an Open Sauce account ... to begin, you will need
>> to open a Free Trial account <https://saucelabs.com/signup/trial> and
>> send the email address and username you used to create this account to me
>> (or, if you already have an existing Free Trial or older account, please
>> send the email address and user name associated with this account).
>> 
>> We would also ask that you give credit to Sauce Labs, via a text link
>> and/or logo and link on your repo. I've attached logo artwork and a MD file
>> with text, please let me know if you need a different size or file format.
>> 
>> Once we receive your Sauce account information and a link showing the
>> attribution on your README we will upgrade your account to Open Sauce,
>> providing you with access to 5 concurrent sessions for parallel testing,
>> and unlimited minutes. Per our service plan, using Open Sauce means your
>> tests and results are open to the public, and usage is subject to
>> verification. Once you have activated your account we may also add your
>> project logo on our Open Sauce page.
>> 
>> Would you (and/or your other project contributors) be open to writing a
>> blog post on using automated testing as part of your project? Our audience
>> is always hungry to learn more about how others have approached automation
>> and cross-browser testing, and we'd be happy to share your story with the
>> world - please let me know.
>> 
>> On behalf of all of us at Sauce Labs, thank you for contributing to the
>> open source community - happy testing!
>> 
>> Bill
>> 
>> --
>> 
>> Bill McGee
>> Sr. Director, Corporate Marketing | Sauce Labs
>> 
>> 116 New Montgomery Street, Suite 300
>> San Francisco, CA 94105
>> 
>> Sauce Labs <http://saucelabs.com/> | Sauce blog
>> <http://saucelabs.com/blog>
>> 
>> 
>> 
>> 

[DISCUSS] Add SauceLab to thanks page of Weex

[York Shen]

Hi, community.I’d like to run Weex test case with emulator on SauceLab [1] as they provide stable and fast emulator than TravisCI. When I am applying the open source account of SauceLab, I am notified that I must list Sauce in Thanks Page. According to what I know, ASF is OK with this thanks page if we follow some rules [2].So, I am going to list SauceLab in the thank page of Weex formally this week if there is no objections.[1] https://mail-archives.apache.org/mod_mbox/weex-dev/201908.mbox/%3Cbae100d.5c0c.16ca3d9d9fd.Coremail.hnhtwrm%40163.com%3E[2] http://www.apache.org/foundation/marks/linking#projectthanks下面是被转发的邮件：发件人: Bill McGee 主题: Your Sauce Labs Open Sauce Account Request Has Been Approved日期: 2019年8月20日 GMT+8 01:27:01收件人: shenyua...@gmail.comHi Alex,Thanks for your request - I have reviewed your repository and would like to invite you to create an Open Sauce account ... to begin, you will need to open a Free Trial account and send the email address and username you used to create this account to me (or, if you already have an existing Free Trial or older account, please send the email address and user name associated with this account).We would also ask that you give credit to Sauce Labs, via a text link and/or logo and link on your repo. I've attached logo artwork and a MD file with text, please let me know if you need a different size or file format. Once we receive your Sauce account information and a link showing the attribution on your README we will upgrade your account to Open Sauce, providing you with access to 5 concurrent sessions for parallel testing, and unlimited minutes. Per our service plan, using Open Sauce means your tests and results are open to the public, and usage is subject to verification. Once you have activated your account we may also add your project logo on our Open Sauce page.Would you (and/or your other project contributors) be open to writing a blog post on using automated testing as part of your project? Our audience is always hungry to learn more about how others have approached automation and cross-browser testing, and we'd be happy to share your story with the world - please let me know.On behalf of all of us at Sauce Labs, thank you for contributing to the open source community - happy testing!Bill-- Bill McGeeSr. Director, Corporate Marketing | Sauce Labs116 New Montgomery Street, Suite 300San Francisco, CA 94105Sauce Labs | Sauce blog
### Big Thanks

Cross-browser Testing Platform and Open Source <3 Provided by [Sauce Labs][homepage]

[homepage]: https://saucelabs.com

Re: Some questions about testing framework(Need Help!)

[York Shen]

I think we need to answer the following two question before we do the real 
coding.
What kinds of test do we need? Unit Test or End-to-end test(Integrate test)?
How do we trigger the test? Automation or manual?

For the first problems, I think the answer is clear based on this mailing list. 
We need end-to-end(E2E) test. It would be better if we can run E2E test without 
emulator, which will make the test real fast. However, we have to mock all the 
Android API on a normal JVM if there is not Android emulator. Although there 
are some framework for this purpose(Robolectric and Mockito), I am afraid it’s 
almost impossible to mock all Android API and load C++ shared library of which 
we don’t even have source code in a normal JVM. So we have to run the E2E test 
on an emulator. Based on the poor behavior of Android emulator on TravisCI, I 
think SauceLab is the places where we host the mobile emulator.

For for problems, I think running test before PR is merged would be great. 
There is even SauceLab plugin for TravisCI [1].

FYI: I have submitted the application for requesting an open source account in 
SauceLab in the name of ASF. I expect to receive response from SauceLab in 5 
business day.

[1] https://docs.travis-ci.com/user/sauce-connect/ 
<https://docs.travis-ci.com/user/sauce-connect/>

> 在 2019年8月18日，16:30，王仁敏  写道：
> 
> I spent some time building an app for end2end testing, and I build a simple 
> iOS and Android Demo.the details as shown below:
> 
> 
> ## Description
> 1. I build a demo app whose home page is a TableView, and each Cell is a test 
> case.
> 2. Each Cell will be bound to a URL link. Clicking on Cell will use a URL 
> link to build the ViewController and pass it to the ViewController with an 
> identifier.
> 3. At the end of the ViewController's viewdidLoad() function, start an 
> asynchronous detection task with delay.
> 4. After the delay, the asynchronous detection task will be executed. Taking 
> the UI test as an example, the View property will be compared with the View 
> property when the test is correct to determine whether to pass the detection 
> task. Since this operation is on the Native side, It's very easy.
> 5. Pass the message that the test is correct or failed to the front-end test 
> framework.
> 
> 
> Because all of the Cells are ViewControllers built using URLs, we can share 
> all of the test cases with a ViewController, which can perform different 
> asynchronous detection tasks depending on the incoming identifier.
> 
> 
> ## How To Run
> The test will run as follows:
> 1. Appium framework controls JS click on Cell to enter test case
> 2. Once the Cell clicks, the ViewController will initialize and trigger an 
> asynchronous detection task.
> 3. The Appium framework test case waits for a while and checks if the 
> received message is "Success" or "Fail" to determine if the test is correct.
> 4. Take the next test.
> In the above scheme, the Appium framework is equivalent to controlling the 
> entry into the test case, and the specific detection task is placed on the 
> Native side.
> 
> 
> 
> 
> ## About Simulator
> And after investigation, SauceLab is in line with our requirements. First of 
> all, they can provide free real machines, although the real iPhone only 
> provides iPhone6, Android provide Samsung Galaxy S6(Android7.0),but in our 
> case, it's enough! By the way, Android provides ARM simulator.
> 
> 
> 
> 
> ## TravisCI And SauceLab:
> 1. Configure the environment variables required by SauceLab in TravisCI
> 2. In Travis CI, we first build the project and then upload the app (iOS) or 
> apk (Android) to the SauceLab server.
> 3. In Travis CI, start the Appium test and run the E2E test with the remote 
> SauceLab simulator and app/apk.
> 
> 
> If you have any suggestions, please let me know. your suggestions are very 
> helpful to me!
> 
> 
> 
> Best Wishes
> Renmin
> 
> 
> Links：
> 1. How To Upload 
> App/Apk:https://wiki.saucelabs.com/display/DOCS/Uploading+Your+App+to+Real+Device+Storage+with+the+REST+API
> 2. SauceLab Mobile Test Document: 
> https://wiki.saucelabs.com/display/DOCS/Mobile+Application+Testing
> 3. Config the Appium Test With SauceLab:  
> https://wiki.saucelabs.com/display/DOCS/Platform+Configurator#/
> 4. Appium SauceLab Python Example: 
> https://wiki.saucelabs.com/display/DOCS/Python+Example+Script+for+iOS+Mobile+Application+Tests
> 
> 5. Supported Simulators:https://app.saucelabs.com/live/web-testing
> 
> 
> | |
> 王仁敏
> |
> |
> hnht...@163.com
> |
> 签名由网易邮箱大师定制
> 
> 
> On 08/16/2019 17:04，York Shen wrote：
> Some thoughts about End to End test on Weex Android. I spent some time this 
> week coding for Android End to End test 

Re: Some Suggestions about incubator-weex

[York Shen]

Actually, I never the number of Travis concurrent build in Weex is larger than 
1, however, I do notice the maximum concurrent jobs in one build is five [1].

Anyway, I think we have no choice but live with limited Travis CI resource we 
have.

[1] 
https://docs.travis-ci.com/user/for-beginners/#builds-jobs-stages-and-phases 


> 在 2019年8月19日，09:39，王仁敏  写道：
> 
> 

Re: Some Suggestions about incubator-weex

[York Shen]

Any information you can share with us?

> 在 2019年8月8日，19:11，王仁敏  写道：
> 
> Thanks for both of you.
> 
> in Weex, we have tried to use Travis CI  resources  as less as possible. in
> Weex the Travis CI job will early stop if it don't need to run continue.
> for example, if there are not android file changed, the android lint check
> job and android check job will stop once it enter script pharse (the
> pharses before script pharse are forced to execute by Travis CI )
> 
> of course I will create a JIRA issue to INFRA to find out  how ASF
> Infra manage Travis resource.
> 
> 
> 申远  于2019年8月8日周四 下午6:26写道：
> 
>> I totally agreed your first point and I shall create a JIRA ticket to INFRA
>> to let it happen.
>> 
>> As for your second point, I found a JIRA issue about this. I am pretty Weex
>> doesn’t use Travis resource as Apache Flink did [1]. (No offense)
>> 
>> Our rough metrics shows that Flink used over 5800 hours of build time last
>>> month. That is equal to EIGHT servers running 24/7 for the ENTIRE MONTH.
>>> EIGHT. nonstop.
>>> 
>> 
>> Maybe we could ask INFRA to find the rules about how ASF INFRA share the CI
>> resource. Is it guarantee an equal share for every Apache projects ? And is
>> there a rule about the maximum Travis jobs/builds. It seems like we can
>> have as many jobs as possible in each build, and all the jobs
>> runs concurrently. But we are only allowed to run 1 Travis Build at
>> any given time, other builds must wait. These rules is a little strange to
>> me.
>> 
>> @Renmin Could you please help to find out about the rules of how ASF Infra
>> manage Travis resource? Just create a JIRA issue to INFRA [2], thanks.
>> 
>> 
>> [1] https://issues.apache.org/jira/browse/INFRA-18533
>> [2] https://issues.apache.org/jira/projects/INFRA/issues
>> 
>> 在 2019年8月8日，17:46，Jan Piotrowski  写道：
>> 
>> Unfortunately there is no way to fix your second point when working in
>> the apache/* repositories as far as I know.
>> This is the account of Apache Software Foundation, which is shared
>> between all projects.
>> If you fork the repo and work in your own namespace, you can use your
>> own Travis account and have much quicker build times.
>> 
>> J
>> 
>> Am Do., 8. Aug. 2019 um 11:34 Uhr schrieb 王仁敏 :
>> 
>> 
>> Those day I spend some time updating Travis CI of incubator-weex, during
>> the development process, I found some problems and the below is my
>> suggestion,
>> 
>> # FIrst I recommend prohibiting merging the PR that Travis CI builds failed
>> 
>> Travis CI build failed means that there is something wrong. If we force to
>> merge the PR, it will lead to bugs even crash. We should Prohibited force
>> merge PR that Travis CI builds failed into the main branch. (but the
>> committer now has permission to merge the PRs that failed Travis CI build
>> failed, and there have been some cases where PR builds failed but were
>> merged into the main branch.)
>> 
>> # Second, I recommend increasing Travis CI's resources
>> 
>> Now Weex's Travis CI does not allow parallel builds, which means that new
>> Travis CI job must wait until the existing Travis CI job complete.
>> 
>> But It takes about 20 minutes to build a Travis CI once now, with more and
>> more checks will be added to Travis CI, the wait time will get longer and
>> longer, even unbearable.
>> 
>> Best regards.
>> Renmin Wang
>> 

Re: Some Suggestions about incubator-weex

[York Shen]

Status check to pass before merge is enabled now.

> 在 2019年8月8日，19:11，王仁敏  写道：
> 
> Thanks for both of you.
> 
> in Weex, we have tried to use Travis CI  resources  as less as possible. in
> Weex the Travis CI job will early stop if it don't need to run continue.
> for example, if there are not android file changed, the android lint check
> job and android check job will stop once it enter script pharse (the
> pharses before script pharse are forced to execute by Travis CI )
> 
> of course I will create a JIRA issue to INFRA to find out  how ASF
> Infra manage Travis resource.
> 
> 
> 申远  于2019年8月8日周四 下午6:26写道：
> 
>> I totally agreed your first point and I shall create a JIRA ticket to INFRA
>> to let it happen.
>> 
>> As for your second point, I found a JIRA issue about this. I am pretty Weex
>> doesn’t use Travis resource as Apache Flink did [1]. (No offense)
>> 
>> Our rough metrics shows that Flink used over 5800 hours of build time last
>>> month. That is equal to EIGHT servers running 24/7 for the ENTIRE MONTH.
>>> EIGHT. nonstop.
>>> 
>> 
>> Maybe we could ask INFRA to find the rules about how ASF INFRA share the CI
>> resource. Is it guarantee an equal share for every Apache projects ? And is
>> there a rule about the maximum Travis jobs/builds. It seems like we can
>> have as many jobs as possible in each build, and all the jobs
>> runs concurrently. But we are only allowed to run 1 Travis Build at
>> any given time, other builds must wait. These rules is a little strange to
>> me.
>> 
>> @Renmin Could you please help to find out about the rules of how ASF Infra
>> manage Travis resource? Just create a JIRA issue to INFRA [2], thanks.
>> 
>> 
>> [1] https://issues.apache.org/jira/browse/INFRA-18533
>> [2] https://issues.apache.org/jira/projects/INFRA/issues
>> 
>> 在 2019年8月8日，17:46，Jan Piotrowski  写道：
>> 
>> Unfortunately there is no way to fix your second point when working in
>> the apache/* repositories as far as I know.
>> This is the account of Apache Software Foundation, which is shared
>> between all projects.
>> If you fork the repo and work in your own namespace, you can use your
>> own Travis account and have much quicker build times.
>> 
>> J
>> 
>> Am Do., 8. Aug. 2019 um 11:34 Uhr schrieb 王仁敏 :
>> 
>> 
>> Those day I spend some time updating Travis CI of incubator-weex, during
>> the development process, I found some problems and the below is my
>> suggestion,
>> 
>> # FIrst I recommend prohibiting merging the PR that Travis CI builds failed
>> 
>> Travis CI build failed means that there is something wrong. If we force to
>> merge the PR, it will lead to bugs even crash. We should Prohibited force
>> merge PR that Travis CI builds failed into the main branch. (but the
>> committer now has permission to merge the PRs that failed Travis CI build
>> failed, and there have been some cases where PR builds failed but were
>> merged into the main branch.)
>> 
>> # Second, I recommend increasing Travis CI's resources
>> 
>> Now Weex's Travis CI does not allow parallel builds, which means that new
>> Travis CI job must wait until the existing Travis CI job complete.
>> 
>> But It takes about 20 minutes to build a Travis CI once now, with more and
>> more checks will be added to Travis CI, the wait time will get longer and
>> longer, even unbearable.
>> 
>> Best regards.
>> Renmin Wang
>> 

Re: [Discuss] Recent works about CI

[York Shen]

Correct me if I am wrong.

It looks like you are relying on third-party code only for code_format task in 
TravisCI. If this is the case, I suggest you remove code_format task in your PR 
first, as everything else looks good to me, I could just merge your PR at that 
time. Then we can still discuss how to solve the third party dependencies, as 
it’s a time consuming task according to my knowledge.

> 在 2019年8月6日，16:10，申远  写道：
> 
> First of all, thanks for your effort of improving Weex CI. I know debugging 
> TravisCI is a painful experience and you have wrote over one hundred commits 
> [1] to make TravisCI right.
> 
> If this is about dependencies in source code, you should definitely copy 
> those code into weex_sdk and change the LICENSE file to make third-party IP 
> clear.  As this is about dependencies in CI environment, and the 
> corresponding code will never be bundled into the release of weex_sdk, I 
> think forking others' repo is acceptable. Even so, I don't think it's ok that 
> you relies on a certain branch of the forking repo [2]. At least you should 
> publish a release version for your forking repo and relies on that version in 
> weex_sdk.
> 
> Maybe mentors here could give some advice on this issue as it's not the same 
> source code dependencies issue that I am familiar with.
> 
> @Jan @Myrle @Willem
> 
> [1] https://github.com/apache/incubator-weex/pull/2731 
> 
> [2] 
> https://github.com/apache/incubator-weex/blob/79494d2027760d9d6ba6d8ae807c6e155896df08/Gemfile#L11
>  
> 
> 
> Best Regards,
> YorkShen
> 
> 申远
> 
> 
> 王仁敏 mailto:wrmwindm...@gmail.com>> 于2019年8月6日周二 
> 下午3:04写道：
> Recently I spent some time on Travis CI, the below is the progress：
> 
> 1. Added Android Lint check and OCLint check in Travis CI.
> 
>-
> 
>[Android Lint]
> 
> If the files in the android folder are modified, new-created, or deleted,
> the AndroidLint check will be triggered. Once any rules of AndroidLint are
> triggered, Travis CI will build failed and the result of AndroidLint will
> be displayed at the PR. (We have solved all the problems reported by
> AndroidLint)
> 
>-
> 
>[OCLint]
> 
> If the C++ or Objective-C files are modified, new-created, or deleted, the
> OCLint check will be triggered. OCLint is the same as Android Lint, Once
> any rules of OCLint are triggered, Travis CI will build failed and the
> result of OCLint will be displayed at the PR. (We are solving all the
> problems reported by OCLint and will complete soon.)
> 
> But there are too many rules of OCLint and many of them have a little
> effect on our project. So we disable some of the rules, as the is shown.
> 
> 2. Add Check of the iOS project.
> 
> Only ios-sdk project build successful and all the test cases of the
> ios-playground pass, the check will succeed. otherwise, The Travis CI will
> build failed.
> 
> 3. Add code-format validation check.
> 
> use Clang-Format to validate the code format, as Clang-Format supports code
> format of the llvm languages, such as c++, objective-c, java, etc.
> 
> I found a danger plugin named danger-code_style_validation
>  > almost
> satisfied our needs. it uses 'clang-format' to look for code style
> violations in added lines on the current PR and offers inline patches.
> 
> To meet our needs, I fork that repo and I did some change based on it :
> 
>1.
> 
>change message level from error to warn(because I think the code format
>is recommended and not necessary.)
>2.
> 
>modify the message hint and make it more readable.
> 
> In Travis CI, the Weex project will download this plugin through a GitHub
> link and use it to validate code-format. here is the configuration
>   
> >
> .
> 
> but I am not sure whether this behavior meets the requirements of AFS, If
> not, what should I do?
> 
> 
> Links:
> 
> OCLint diable rule:
> https://github.com/apache/incubator-weex/blob/79494d2027760d9d6ba6d8ae807c6e155896df08/.travis.yml#L167
>  
> 

Re: [ANNOUNCEMENT] Separate weex_sdk and weex_playground for good

[York Shen]

I have update the website [1], which takes a little than expected.

[1] https://weex.apache.org/guide/playground.html 
<https://weex.apache.org/guide/playground.html>

> 在 2019年7月17日，17:19，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 > <mailto:piotrow...@gmail.com>> 写道：
>> 
>> Awesome, that was quick - thanks Katherine and RenminWang!
>> 
>> I will try to check out and play with
>> https://github.com/apache/incubator-weex-playground 
>> <https://github.com/apache/incubator-weex-playground> soon.
>> 
>> A note: Now that playground is separate,
>> https://github.com/apache/incubator-weex#use-weex 
>> <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 
>> <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 
>> <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 申远 > <mailto:shenyua...@gmail.com>>:
>>> 
>>> 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
>>> 
>>> 申远
>>> 
>>> 
>>> 申远 mailto:shenyua...@gmail.com>> 于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
>>>>  
>>>> <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
>>>> 
>>>> 申远
>>>> 
> 

[DISCUSS][Documentation] How Weex Community Works

[York Shen]

Hi, there

I just wrote a page [1] to give a brief introduction about how weex community 
works. If you are familiar with other ASF’s community, you may already know 
most of the contents.

Normally, I write documentation on Github without bothering individuals in this 
mailing list. But this documentation gives an introduction of some essential 
elements of community including how to be a committer/PPMC and voting 
procedure. I’d like to discuss the documentation first and then have a formal 
vote. I have attached some essential parts of the documentation below.

Roles
The meritocracy usually has various roles in Weex community.
User <https://www.apache.org/foundation/how-it-works.html#users>, someone who 
uses Weex
Contributor <https://www.apache.org/foundation/how-it-works.html#developers>, 
also named developer, who contributes to Weex in the form of code, 
documentation, etc..
Committer <https://www.apache.org/foundation/how-it-works.html#committers>, who 
is given write access to the code repository.
PPMC Member, <https://www.apache.org/foundation/how-it-works.html#pmc-members> 
who not only has the privilege of committer, but is also given the right to 
vote for the community-related decisions and propose an active contributor for 
committership.

Once selected, the membership of PPMC or committer is lifetime except for the 
following conditions:
A committer or PPMC member resigns <https://www.apache.org/dev/pmc.html#resign> 
the his/her membership.
A committer or PPMC member passed away 
<https://www.apache.org/dev/pmc.html#deceased>, which is a tragic.
The PPMC and ASF Board both agree to remove someone's membership 
<https://www.apache.org/dev/pmc.html#pmc-removal>  in which case the PPMC 
should send an email to the board@ mailing list detailing the request for 
removal and the justification the PPMC has for that removal, and cc: 
priv...@weex.apache.org 

How to be a Committer
It's PPMC's job to find active committers in active contributors. There is no 
formal rules about prerequisite of a committer, but generally a committer shall 
fulfill the following requirement:
Sustained contribution, including but not limited to code, documentation, etc..
Community involvement, including but not limited to participate in discussion 
through mailing list, interacting with users who has questions.
Passion and interest in mobile or Front-End engineering.

Normally, a PPMC member is elected due to merit for the community, not just 
technical skill, which is also important, of course.

Read ASF’s policy 
<https://incubator.apache.org/guides/ppmc.html#voting_in_a_new_ppmc_member> for 
detail.


[1] https://cwiki.apache.org/confluence/x/-45TBw

Best Regards,
York Shen

申远

List members of current committers, PPMCs and mentor

[York Shen]

Hi, community

I just wrote a documentation [1] to list all committers, PPMCs and mentors 
currently, which was only accessible through whimsy by PPMCs.

So far, I don’t find any ASF’s policy states that the email and Github account 
of committers is privacy and only visible to PPMC. If anyone feel uncomfortable 
with his or her name listed on the documentation, please let me know. 

[1] https://cwiki.apache.org/confluence/x/z45TBw 
<https://cwiki.apache.org/confluence/display/WEEX/Mentor,+PPMCs+and+Committers>

Best Regards,
York Shen

申远

Re: How to easy debug runtime source code?

[York Shen]

Maybe you could Google about how to debug iOS. 

Best Regards,
York Shen

申远

> 在 2019年7月22日，15:51，SenPng  写道：
> 
> Hello, I need to debug runtime source code in iOS Env. How to easy debug 
> runtime source code?

[DISCUSS] Documentation for contributors and committers.

[York Shen]

Hi, community

Recently, I spent some time on wring documentation for Weex. From a normal 
user’s perspective, one can find what and how he/she could within the help of 
Weex despite the misspelling and missing API. But from a contributor, committer 
or PPMC’s perspective, I found the documentation is frustrating. For example, I 
can’t even find the governance model, podding report of Weex or how to be a 
committer of Weex. For an experienced ASF committer, this documentation may be 
not necessary, but for a potential contributor or committer, he/she may be 
confused about it (Someone might even thinks Weex still belongs to Alibaba, 
which is not true of course). Let’s make it clear how the community works and 
how to be a guy(PPMC) who has a binding vote on decision of Weex. IMO, 
governance model is at least as important as code.

I’d like to have following documentation created:

Confluence
The main users of Confluence [1] should be contributors, committers, PMCs of 
Weex, though everyone else could read it without limitation. Normally, only 
core-contributors, committers and PPMCs should care about these document.
Podding reports
Governance model
How to be a committer
Minute of offline meetup
Release procedure

We are missing all other documentation except for release procedure and podding 
reports.

Github
Except for the users of Confluence, the Github of Weex [2] also serves the 
users of Weex. Github is used to hold code-related documentation like the 
following:
Contributing guideline which includes PR format, issue format and commit 
message format
Short term release plan, which is based on Github milestone
Long term feature, which is based on Github Project
API design and Roadmap, which is based on Github Wiki Page.

[1] https://cwiki.apache.org/confluence/display/WEEX/ 
<https://cwiki.apache.org/confluence/display/WEEX/>
[2] https://github.com/apache/incubator-weex 
<https://github.com/apache/incubator-weex>

Best Regards,
York Shen

申远

Re: [Discuss] Lint rules should be kept or removed

[York Shen]

I’d like the idea of code lint(C++/OC/Java/etc…) in Travis CI. What’s more, you 
could improve your PR [1] in the following aspect:

Fix the lint issues especially lint errors in before enabling the Lint in Travis
Output the code lint result in Danger and make the Danger failed if there is an 
error lint. I think people rarely read the log of Travis if the build successes.

I think the default Android lint is good enough, as for OCLint, maybe someone 
with iOS experienced could give some suggestion.

[1] https://github.com/apache/incubator-weex/pull/2731 
<https://github.com/apache/incubator-weex/pull/2731>

Best Regards,
York Shen

申远

> 在 2019年7月19日，10:11，王仁敏  写道：
> 
> I think in OCLint, the following rules should be disabled.
> 
> 
>   - Size <http://docs.oclint.org/en/stable/rules/size.html>
>  - HighCyclomaticComplexity
>  
> <http://docs.oclint.org/en/stable/rules/size.html#highcyclomaticcomplexity>
>  - LongClass
>  <http://docs.oclint.org/en/stable/rules/size.html#longclass>
>  - LongLine <http://docs.oclint.org/en/stable/rules/size.html#longline>
>  - LongMethod
>  <http://docs.oclint.org/en/stable/rules/size.html#longmethod>
>  - HighNcssMethod
>  <http://docs.oclint.org/en/stable/rules/size.html#highncssmethod>
>  - DeepNestedBlock
>  <http://docs.oclint.org/en/stable/rules/size.html#deepnestedblock>
>  - HighNPathComplexity
>  <http://docs.oclint.org/en/stable/rules/size.html#highnpathcomplexity>
>  - TooManyFields
>  <http://docs.oclint.org/en/stable/rules/size.html#toomanyfields>
>  - TooManyMethods
>  <http://docs.oclint.org/en/stable/rules/size.html#toomanymethods>
>  - TooManyParameters
>  <http://docs.oclint.org/en/stable/rules/size.html#toomanyparameters>
>   - Naming <http://docs.oclint.org/en/stable/rules/naming.html>
>  - LongVariableName
>  <http://docs.oclint.org/en/stable/rules/naming.html#longvariablename>
>  - ShortVariableName
>  <http://docs.oclint.org/en/stable/rules/naming.html#shortvariablename>
> 
> 
> 王仁敏  于2019年7月19日周五 上午9:50写道：
> 
>> Hi there,
>> 
>> 
>> I'm trying to add some static lint checks to CI, now OCLint(for c, c++
>> and objective-c) and AndroidLint already get ready in CI.
>> 
>> But OCLint and AndroidLint have too many rules, many of which have little
>> impact. so maybe should we discuss about which rules to keep or which rules
>> to remove.
>> 
>> 
>> OCLint Rule List: http://docs.oclint.org/en/stable/rules/index.html
>> 
>> AndroidLint Rule List: http://tools.android.com/tips/lint-checks
>> 
>> AndroidLint Help: http://www.androiddocs.com/tools/help/lint.html
>> 
>> 
>> The below is the doctest
>> <https://github.com/onqtam/doctest/blob/master/.travis.yml> reference for
>> OCLint：
>> 
>> ```
>> 
>> -disable-rule=ShortVariableName \
>> 
>>  -disable-rule=LongLine \
>> 
>>  -disable-rule=LongMethod \
>> 
>>  -disable-rule=HighNcssMethod \
>> 
>>  -disable-rule=LongVariableName \
>> 
>>  -disable-rule=HighCyclomaticComplexity \
>> 
>>  -disable-rule=HighNPathComplexity \
>> 
>>  -disable-rule=UnusedLocalVariable \
>> 
>>  -disable-rule=DoubleNegative \
>> 
>>  -disable-rule=MultipleUnaryOperator \
>> 
>>  -disable-rule=DeepNestedBlock \
>> 
>> ```
>> 
>> 
>> Best Wishes.
>> 
>> RenMin Wang
>> 
>> 
>> 

Re: App freezing with 0.26 sdk update

[York Shen]

I think @lucky-then is helping you in this problems. Please give as much 
information as possible as he suggested. And we shall move the conversation to 
Github[1] if we are going to talk about detail of code.

[1] https://github.com/apache/incubator-weex/issues/2718#issuecomment-512654624 
<https://github.com/apache/incubator-weex/issues/2718#issuecomment-512654624>

Best Regards,
York Shen

申远

> 在 2019年7月17日，18:26，Vipul Gupta  写道：
> 
> Sure York shen.
> Please find link to Github -
> https://github.com/apache/incubator-weex/issues/2718 
> <https://github.com/apache/incubator-weex/issues/2718>
> 
> 
> On Wed, Jul 17, 2019 at 2:43 PM York Shen  <mailto:shenyua...@gmail.com>> 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> <
>> 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: 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 
> <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: [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
 
<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 
<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: [GitHub] [incubator-weex-playground] katherine95s opened a new pull request #2: [Android]add flag to configure weex_sdk source

[York Shen]

Of course, I have just created a JIRA issue[1] to INFRA for this problem.

[1] https://issues.apache.org/jira/browse/INFRA-18735 
<https://issues.apache.org/jira/browse/INFRA-18735>

Best Regards,
York Shen

申远

> 在 2019年7月11日，19:46，Jan Piotrowski  写道：
> 
> These emails should probably not go to this email address, but
> comm...@weex.incubator.apache.org or similar. Was probably not
> configured when creating the playground repository, and the default is
> the dev list if I remember correctly.
> 
> Not sure if this can be done in self service or an INFRA issue has to
> be created.
> 
> J
> 
> Am Do., 11. Juli 2019 um 13:13 Uhr schrieb GitBox :
>> 
>> katherine95s opened a new pull request #2: [Android]add flag to configure 
>> weex_sdk source
>> URL: https://github.com/apache/incubator-weex-playground/pull/2
>> 
>> 
>> 
>> 
>> 
>> This is an automated message from the Apache Git Service.
>> To respond to the message, please log on to GitHub and use the
>> URL above to go to the specific comment.
>> 
>> For queries about this service, please contact Infrastructure at:
>> us...@infra.apache.org
>> 
>> 
>> With regards,
>> Apache Git Services

Re: [DISCUSS][LICENSE] Include downloaded dependencies in LICENSE file for Playground?

[York Shen]

FYI： It seems like Katherine does a great job for Playground [1] in Android 
side. After deleting corresponding code in weex_sdk, we will finished the job 
of Android part for good.

[1] https://github.com/apache/incubator-weex-playground/pull/1 
<https://github.com/apache/incubator-weex-playground/pull/1>

Best Regards,
York Shen

申远

> 在 2019年7月11日，16:28，York Shen  写道：
> 
> Thanks, I will change it to 
> 
>   Copyright 2019 Apache Incubator-Weex
> 
> Best Regards,
> York Shen
> 
> 申远
> 
>> 在 2019年7月11日，16:09，Jan Piotrowski > <mailto:piotrow...@gmail.com>> 写道：
>> 
>> You should adapt "Copyright [] [name of copyright owner]", but otherwise 
>> +1
>> 
>> Am Do., 11. Juli 2019 um 04:33 Uhr schrieb 申远 > <mailto:shenyua...@gmail.com>>:
>>> 
>>> After some research, I don't find any source code file containing
>>> third-party work in weex playground, only separately downloaded
>>> dependencies in its build.gradle [1]. I think those dependencies falls into
>>> the description where *materials which are not bundled in the package *[2].
>>> 
>>> If there is no other opinion, I will remain LICENSE of new weex_playground
>>> as it is [3].
>>> 
>>> [1]
>>> https://github.com/apache/incubator-weex/blob/master/android/playground/app/build.gradle#L104-L127
>>>  
>>> <https://github.com/apache/incubator-weex/blob/master/android/playground/app/build.gradle#L104-L127>
>>> [2] http://www.apache.org/legal/release-policy.html#licensing-documentation
>>> [3] https://github.com/apache/incubator-weex-playground/blob/master/LICENSE
>>> 
>>> Best Regards,
>>> YorkShen
>>> 
>>> 申远
>>> 
>>> 
>>> 申远  于2019年7月10日周三 下午5:59写道：
>>> 
>>>> According to my knowledge, the binary of weex_playground was distributed
>>>> through Android App store in China several times before, but the source
>>>> code of weex_playground was never released in Apache Way.
>>>> 
>>>> The separated Weex Playground [1] will be used for demo purpose as before
>>>> and it's common for developers copy some code from demo into their own App.
>>>> There is possibility that playground would be distributed through App Store
>>>> of Apple in the future. But even if we would publish source release and
>>>> Binary App of Playground together, this wouldn't change the fact that 
>>>> those dependencies[2]
>>>> are separately downloaded dependencies, IMO.
>>>> 
>>>> Also the word "MUST NOT" in ASF's policy is a very strong word from my
>>>> understanding, I don't think it's a good idea that we list these 
>>>> dependencies
>>>> in LICENSE file.
>>>> 
>>>> [1] https://github.com/apache/incubator-weex-playground
>>>> [2]
>>>> https://github.com/apache/incubator-weex/blob/master/android/playground/app/build.gradle#L104-L127
>>>> 
>>>> Best Regards,
>>>> YorkShen
>>>> 
>>>> 申远
>>>> 
>>>> 
>>>> Jan Piotrowski  于2019年7月10日周三 下午5:21写道：
>>>> 
>>>>> From my understanding
>>>>> http://www.apache.org/legal/release-policy.html#licensing-documentation
>>>>> doesn't apply at all if there are no releases (archive, vote process,
>>>>> publishing) planned for this repository. (Which of course does not
>>>>> mean that you _can't_ create these files as a service for potential
>>>>> users - they are not just useless process but actually useful and
>>>>> contain important information for the user.)
>>>>> 
>>>>> Which of course raises another question: What kind of repository will
>>>>> weex playground be?
>>>>> You mentioned "only for demo purpose", I also know that it will
>>>>> probably be published on Apache App Store accounts and be used by
>>>>> developers to play with weex. But will it make sense for users of weex
>>>>> to use the source code of the app for something, as a base for a
>>>>> project for example?
>>>>> 
>>>>> -J
>>>>> 
>>>>> 
>>>>> Am Mi., 10. Juli 2019 um 11:09 Uhr schrieb 申远 :
>>>>>> 
>>>>>> Hi, community.
>>>>>> 
>>>>>> As you might already knew, we are separating playground from weex_sdk
>>>>> [1].
&

Re: [DISCUSS][LICENSE] Include downloaded dependencies in LICENSE file for Playground?

[York Shen]

Thanks, I will change it to 

Copyright 2019 Apache Incubator-Weex

Best Regards,
York Shen

申远

> 在 2019年7月11日，16:09，Jan Piotrowski  写道：
> 
> You should adapt "Copyright [] [name of copyright owner]", but otherwise 
> +1
> 
> Am Do., 11. Juli 2019 um 04:33 Uhr schrieb 申远 :
>> 
>> After some research, I don't find any source code file containing
>> third-party work in weex playground, only separately downloaded
>> dependencies in its build.gradle [1]. I think those dependencies falls into
>> the description where *materials which are not bundled in the package *[2].
>> 
>> If there is no other opinion, I will remain LICENSE of new weex_playground
>> as it is [3].
>> 
>> [1]
>> https://github.com/apache/incubator-weex/blob/master/android/playground/app/build.gradle#L104-L127
>> [2] http://www.apache.org/legal/release-policy.html#licensing-documentation
>> [3] https://github.com/apache/incubator-weex-playground/blob/master/LICENSE
>> 
>> Best Regards,
>> YorkShen
>> 
>> 申远
>> 
>> 
>> 申远  于2019年7月10日周三 下午5:59写道：
>> 
>>> According to my knowledge, the binary of weex_playground was distributed
>>> through Android App store in China several times before, but the source
>>> code of weex_playground was never released in Apache Way.
>>> 
>>> The separated Weex Playground [1] will be used for demo purpose as before
>>> and it's common for developers copy some code from demo into their own App.
>>> There is possibility that playground would be distributed through App Store
>>> of Apple in the future. But even if we would publish source release and
>>> Binary App of Playground together, this wouldn't change the fact that those 
>>> dependencies[2]
>>> are separately downloaded dependencies, IMO.
>>> 
>>> Also the word "MUST NOT" in ASF's policy is a very strong word from my
>>> understanding, I don't think it's a good idea that we list these 
>>> dependencies
>>> in LICENSE file.
>>> 
>>> [1] https://github.com/apache/incubator-weex-playground
>>> [2]
>>> https://github.com/apache/incubator-weex/blob/master/android/playground/app/build.gradle#L104-L127
>>> 
>>> Best Regards,
>>> YorkShen
>>> 
>>> 申远
>>> 
>>> 
>>> Jan Piotrowski  于2019年7月10日周三 下午5:21写道：
>>> 
>>>> From my understanding
>>>> http://www.apache.org/legal/release-policy.html#licensing-documentation
>>>> doesn't apply at all if there are no releases (archive, vote process,
>>>> publishing) planned for this repository. (Which of course does not
>>>> mean that you _can't_ create these files as a service for potential
>>>> users - they are not just useless process but actually useful and
>>>> contain important information for the user.)
>>>> 
>>>> Which of course raises another question: What kind of repository will
>>>> weex playground be?
>>>> You mentioned "only for demo purpose", I also know that it will
>>>> probably be published on Apache App Store accounts and be used by
>>>> developers to play with weex. But will it make sense for users of weex
>>>> to use the source code of the app for something, as a base for a
>>>> project for example?
>>>> 
>>>> -J
>>>> 
>>>> 
>>>> Am Mi., 10. Juli 2019 um 11:09 Uhr schrieb 申远 :
>>>>> 
>>>>> Hi, community.
>>>>> 
>>>>> As you might already knew, we are separating playground from weex_sdk
>>>> [1].
>>>>> As playground is only for demo purpose and never released in Apache
>>>> Way, I
>>>>> am a little concerned about the LICENSE issue around playground.
>>>>> 
>>>>> There are many runtime/download dependencies(image library, network
>>>>> library, json library, etc..) in weex playground [2] as any other Apps
>>>> do.
>>>>> Do we need to list them in LICENSE file? Or are they separately
>>>> downloaded
>>>>> dependencies[3] and we can ignore them in LICENSE file?
>>>>> 
>>>>> LICENSE and NOTICE MUST NOT provide unnecessary information about
>>>> materials
>>>>>> which are not bundled in the package, such as separately downloaded
>>>>>> dependencies.
>>>>> 
>>>>> 
>>>>> These dependencies would not be bundled in source release nor binary
>>>>> convenience library of Weex Playground.
>>>>> 
>>>>> [1]
>>>>> 
>>>> https://lists.apache.org/thread.html/020895785263a3f5ee4dfa6c56167c01699227d9512f19f6635ef563@%3Cdev.weex.apache.org%3E
>>>>> [2]
>>>>> 
>>>> https://github.com/apache/incubator-weex/blob/master/android/playground/app/build.gradle#L104-L127
>>>>> [3]
>>>> http://www.apache.org/legal/release-policy.html#licensing-documentation
>>>>> 
>>>>> Best Regards,
>>>>> YorkShen
>>>>> 
>>>>> 申远
>>>> 
>>> 

Re: [RESULT][VOTE] Release Apache Weex (Incubating) 0.26.0-RC2

[York Shen]

The source release is published yet, as for connivence binary, you shall 
receive the update by the end of this week.

Best Regards,
York Shen

申远

> 在 2019年7月11日，14:25，Vipul Gupta  写道：
> 
> Hi,
> 
> By when can we expect the release ?
> ETA would help.
> 
> On Thu, Jul 11, 2019 at 8:23 AM 王乾元  wrote:
> 
>> Hi, community
>> 
>> The vote of release Apache Weex (Incubating) 0.26.0-RC2 has passed with
>> three +1 votes
>> 
>> binding vote:
>> 
>>   - Myrle Krantz
>>   - Greg Stein
>>   - Justin Mclean
>> 
>> Vote thread:
>> 
>> https://lists.apache.org/thread.html/afde0ced9b4441e59cb582e99187ed56d4cb5c8f2c228e002418af21@%3Cgeneral.incubator.apache.org%3E
>> 
>> Thank you to the above IPMC members for taking time to review and
>> provide feedback of this release. Thanks again.
>> 
>> Next, I will proceed with the official release of 0.26.0.
>> 
>> Best Regards.
>> 
> 
> 
> -- 
> Regards,
> Vipul Gupta
> Senior Technical Lead
> 8802232975

Re: [DISCUSS] Separate Weex into two repos

[York Shen]

Ref release/0.26, for which the vote is not passed yet.

Best Regards,
York Shen

申远

> 在 2019年7月10日，10:32，δμδμΘχΘχ <3322054...@qq.com> 写道：
> 
> How does android reference the SDK to support 64-bit
> 
> 
> 
> 
> -- 原始邮件 --
> 发件人: "York Shen";
> 发送时间: 2019年7月9日(星期二) 晚上8:50
> 收件人: "dev";
> 
> 主题: Re: [DISCUSS] Separate Weex into two repos
> 
> 
> 
> Thanks for both of you.
> 
> But I have following concerns for your iOS plan:
> In weex_sdk repo, playground will be added as a Git submodule. It looks like 
> you are reversing the dependency between weex_sdk and playground. I am afraid 
> this will cause developers confusion.
> In weex playground repo, Android Weex Playground relies on a snapshot version 
> of weex_sdk. This SNAPSHOT version shall only be shared among 
> core-contributor of weex. I am not sure whether this can be achieved  through 
> CocoaPods
> 
> Correct me if I am wrong as I am not an iOS developer.
> 
> Best Regards,
> York Shen
> 
> 申远
> 
>> 在 2019年7月9日，20:35，王仁敏  写道：
>> 
>> That's a great idea! It's a good solution to separate weex_sdk and 
>> playground into two repos by using Git Submodule.
>> 
>> 
>> In iOS, instead of using git  submodule directly, this can be achieved by 
>> change the CocoaPods dependence, which we use in weex_sdk project now, from 
>> relative path to git-link.
>> 
>> 
>> If we seperate them to two repos, we can solved our problm only by modifing 
>> the Podfile as below:
>> pod 'WeexSDK', :git => 'https://github.com/apache/incubator-weex.git’
>> 
>> 
>> Besides, we can the specific branch, tag or even a commit in the git-link.
>> 
>> 
>> Reference Link: https://guides.cocoapods.org/using/the-podfile.html
>> 
>> 
>> Best Regards,
>> Renmin Wang
>> | |
>> 王仁敏
>> |
>> |
>> hnht...@163.com
>> |
>> 签名由网易邮箱大师定制
>> 
>> 
>> On 07/9/2019 15:15，York Shen wrote：
>> Sounds like a good plan, but there are some issues you need to be careful 
>> with:
>> Write a document about how to configure the submodule for weex_sdk and 
>> update playground version when a new weex_sdk is released, maybe a README is 
>> enough
>> I am not sure about SNAPSHOT version, will this be conflicted with ASF’s 
>> policy? Or is it ok if we don’t provide the SNAPSHOT of weex_sdk beyond our 
>> core-developers?
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远
>> 
>> 在 2019年7月9日，15:04，Huiying Jiang  写道：
>> 
>> Hi there,
>> I am trying to separate weex_sdk and playground into two repos.After moving 
>> the playground to a new repository, here comes a question about dealing with 
>> the repos’ relationship.And I am considering adding ‘weex_playground’ into 
>> ‘incubator-weex’ as a submodule.Here are some details:
>> 1.The playground submodule will be cloned and updated automatically when 
>> developers clone the ‘incubator-weex’ repo and build it.In this case, 
>> playground project will implement the source code of weex-sdk.
>> 2.When developer directly clone the 'weex-playground' repo and run it 
>> separately, the playground project will implement a corresponding aar 
>> version of weex-sdk. That means some weex-sdk snapshots will be needed to 
>> support playground since some commits of playground may rely on unreleased 
>> features of weex-sdk.
>> Does this solution sounds reasonable?
>> 
>> Regards,
>> Katherine
>> 
>> 
>> On 2019/07/04 07:35:53, Huiying Jiang  wrote:
>> Hi,>
>> I would like to do the separating of android.>
>> Regards,>
>> Katherine.>
>> 
>> On 2019/07/04 07:20:37, 申远  wrote: >
>> As discussed before [1], Weex repo should be separated into two repos:> >
>> 
>> - weex_sdk> >
>> - weex playground> >
>> 
>> I have just create a new repo for Weex Playground[2].> >
>> 
>> As I am a little overloaded these days, it's really helpful if someone in> >
>> this mailing list could help me do the separating.> >
>> 
>> [1]> >
>> https://lists.apache.org/thread.html/6a08422bc28743e132ae23e002bf5713eb464447a9ef35236dd1b957@%3Cdev.weex.apache.org%3E>
>>  >
>> [2] https://github.com/apache/incubator-weex-playground> >
>> 
>> Best Regards,> >
>> YorkShen> >
>> 
>> 申远> >
>> 
>> 

Re: [DISCUSS] Separate Weex into two repos

[York Shen]

Thanks for both of you.

But I have following concerns for your iOS plan:
In weex_sdk repo, playground will be added as a Git submodule. It looks like 
you are reversing the dependency between weex_sdk and playground. I am afraid 
this will cause developers confusion.
In weex playground repo, Android Weex Playground relies on a snapshot version 
of weex_sdk. This SNAPSHOT version shall only be shared among core-contributor 
of weex. I am not sure whether this can be achieved  through CocoaPods

Correct me if I am wrong as I am not an iOS developer.

Best Regards,
York Shen

申远

> 在 2019年7月9日，20:35，王仁敏  写道：
> 
> That's a great idea! It's a good solution to separate weex_sdk and playground 
> into two repos by using Git Submodule.
> 
> 
> In iOS, instead of using git  submodule directly, this can be achieved by 
> change the CocoaPods dependence, which we use in weex_sdk project now, from 
> relative path to git-link.
> 
> 
> If we seperate them to two repos, we can solved our problm only by modifing 
> the Podfile as below:
> pod 'WeexSDK', :git => 'https://github.com/apache/incubator-weex.git’
> 
> 
> Besides, we can the specific branch, tag or even a commit in the git-link.
> 
> 
> Reference Link: https://guides.cocoapods.org/using/the-podfile.html
> 
> 
> Best Regards,
> Renmin Wang
> | |
> 王仁敏
> |
> |
> hnht...@163.com
> |
> 签名由网易邮箱大师定制
> 
> 
> On 07/9/2019 15:15，York Shen wrote：
> Sounds like a good plan, but there are some issues you need to be careful 
> with:
> Write a document about how to configure the submodule for weex_sdk and update 
> playground version when a new weex_sdk is released, maybe a README is enough
> I am not sure about SNAPSHOT version, will this be conflicted with ASF’s 
> policy? Or is it ok if we don’t provide the SNAPSHOT of weex_sdk beyond our 
> core-developers?
> 
> Best Regards,
> York Shen
> 
> 申远
> 
> 在 2019年7月9日，15:04，Huiying Jiang  写道：
> 
> Hi there,
> I am trying to separate weex_sdk and playground into two repos.After moving 
> the playground to a new repository, here comes a question about dealing with 
> the repos’ relationship.And I am considering adding ‘weex_playground’ into 
> ‘incubator-weex’ as a submodule.Here are some details:
> 1.The playground submodule will be cloned and updated automatically when 
> developers clone the ‘incubator-weex’ repo and build it.In this case, 
> playground project will implement the source code of weex-sdk.
> 2.When developer directly clone the 'weex-playground' repo and run it 
> separately, the playground project will implement a corresponding aar version 
> of weex-sdk. That means some weex-sdk snapshots will be needed to support 
> playground since some commits of playground may rely on unreleased features 
> of weex-sdk.
> Does this solution sounds reasonable?
> 
> Regards,
> Katherine
> 
> 
> On 2019/07/04 07:35:53, Huiying Jiang  wrote:
> Hi,>
> I would like to do the separating of android.>
> Regards,>
> Katherine.>
> 
> On 2019/07/04 07:20:37, 申远  wrote: >
> As discussed before [1], Weex repo should be separated into two repos:> >
> 
> - weex_sdk> >
> - weex playground> >
> 
> I have just create a new repo for Weex Playground[2].> >
> 
> As I am a little overloaded these days, it's really helpful if someone in> >
> this mailing list could help me do the separating.> >
> 
> [1]> >
> https://lists.apache.org/thread.html/6a08422bc28743e132ae23e002bf5713eb464447a9ef35236dd1b957@%3Cdev.weex.apache.org%3E>
>  >
> [2] https://github.com/apache/incubator-weex-playground> >
> 
> Best Regards,> >
> YorkShen> >
> 
> 申远> >
> 
> 
> 

Re: [DISCUSS] Separate Weex into two repos

[York Shen]

Sounds like a good plan, but there are some issues you need to be careful with:
Write a document about how to configure the submodule for weex_sdk and update 
playground version when a new weex_sdk is released, maybe a README is enough
I am not sure about SNAPSHOT version, will this be conflicted with ASF’s 
policy? Or is it ok if we don’t provide the SNAPSHOT of weex_sdk beyond our 
core-developers?

Best Regards,
York Shen

申远

> 在 2019年7月9日，15:04，Huiying Jiang  写道：
> 
> Hi there,
> I am trying to separate weex_sdk and playground into two repos.After moving 
> the playground to a new repository, here comes a question about dealing with 
> the repos’ relationship.And I am considering adding ‘weex_playground’ into 
> ‘incubator-weex’ as a submodule.Here are some details:
> 1.The playground submodule will be cloned and updated automatically when 
> developers clone the ‘incubator-weex’ repo and build it.In this case, 
> playground project will implement the source code of weex-sdk.
> 2.When developer directly clone the 'weex-playground' repo and run it 
> separately, the playground project will implement a corresponding aar version 
> of weex-sdk. That means some weex-sdk snapshots will be needed to support 
> playground since some commits of playground may rely on unreleased features 
> of weex-sdk.
> Does this solution sounds reasonable?
> 
> Regards,
> Katherine
> 
> 
> On 2019/07/04 07:35:53, Huiying Jiang  wrote: 
>> Hi,> 
>> I would like to do the separating of android.> 
>> Regards,> 
>> Katherine.> 
>> 
>> On 2019/07/04 07:20:37, 申远  wrote: > 
>>> As discussed before [1], Weex repo should be separated into two repos:> > 
>>>> 
>>>   - weex_sdk> > 
>>>   - weex playground> > 
>>>> 
>>> I have just create a new repo for Weex Playground[2].> > 
>>>> 
>>> As I am a little overloaded these days, it's really helpful if someone in> 
>>> > 
>>> this mailing list could help me do the separating.> > 
>>>> 
>>> [1]> > 
>>> https://lists.apache.org/thread.html/6a08422bc28743e132ae23e002bf5713eb464447a9ef35236dd1b957@%3Cdev.weex.apache.org%3E>
>>>  > 
>>> [2] https://github.com/apache/incubator-weex-playground> > 
>>>> 
>>> Best Regards,> > 
>>> YorkShen> > 
>>>> 
>>> 申远> > 
>>>> 
>> 

Re: [RESULT][VOTE] Release Apache Weex (Incubating) 0.26.0-RC2

[York Shen]

While, I only test English & Chinese language, both works fine for me.

As for your problems, I found there is no UpperCase function in 
textData.toUpperCase() only if textData is Cyrillic symbols. As I am not 
familiar with Russian alphabet, I can’t help you on this issue further. If it’s 
possible for you, just open a Github issue. I think some developers will look 
into it.

Best Regards,
York Shen

申远

> 在 2019年7月8日，19:42，Dmitry L.  写道：
> 
> Okay.
> But on my build for Android toUpperCase/toLocaleUpperCase causes segfault
> crash when use it for Cyrillic symbols.
> 
> http://dotwe.org/vue/9d389b539f7521f7a2cb57e3bc61676f 
> <http://dotwe.org/vue/9d389b539f7521f7a2cb57e3bc61676f>
> 
> PS: I have built it from release/0.26 gh branch
> 
> 
> On Mon, 8 Jul 2019 at 14:36, York Shen  <mailto:shenyua...@gmail.com>> wrote:
> 
>> The Java namespace issue is a known problem for a while, and shall fix in
>> next release(later in July or early in August) [1] .
>> 
>> [1]
>> https://lists.apache.org/x/thread.html/b3c4974a208f87e21c1f12b4ba5e5308cf20f7678cedd4523b5ddf25@%3Cdev.weex.apache.org%3E
>>  
>> <https://lists.apache.org/x/thread.html/b3c4974a208f87e21c1f12b4ba5e5308cf20f7678cedd4523b5ddf25@%3Cdev.weex.apache.org%3E>
>> <
>> https://lists.apache.org/x/thread.html/b3c4974a208f87e21c1f12b4ba5e5308cf20f7678cedd4523b5ddf25@%3Cdev.weex.apache.org%3E
>>  
>> <https://lists.apache.org/x/thread.html/b3c4974a208f87e21c1f12b4ba5e5308cf20f7678cedd4523b5ddf25@%3Cdev.weex.apache.org%3E>
>>> 
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远
>> 
>>> 在 2019年7月8日，19:29，Dmitry L.  写道：
>>> 
>>> I can compile apache-weex-incubating-0.26.0-RC2-src.tar.gz
>>> But it doesn't work because weex_core in archive refers to
>> com.taobao.weex
>>> namespace
>>> But android_sdk has org.apache.taobao.weex namespace.
>>> 
>>> Also it contains some bugs which cause segfault crashes
>>> 
>>> On Mon, 8 Jul 2019 at 14:14, 王乾元  wrote:
>>> 
>>>> Hi, community
>>>> 
>>>> The vote of release Apache Weex (Incubating) 0.26.0-RC2 has passed with
>>>> three +1 votes
>>>> 
>>>> binding vote:
>>>> 
>>>>  - Adam Feng
>>>>  - YorkShen
>>>>  - Shihan Zheng
>>>> 
>>>> Vote thread:
>>>> 
>>>> 
>> https://lists.apache.org/x/thread.html/1fe6327f7a2775fad2ca08c6960dac8d389479fce2abbd8c6680a374@%3Cdev.weex.apache.org%3E
>>>> 
>>>> Thank you to the above PPMC members for taking time to review and
>>>> provide feedback of this release.
>>>> 
>>>> Next, I will proceed the vote of release Apache Weex (Incubating)
>>>> 0.26.0-RC2 to IPMC.
>>>> 
>>>> Best Regards.
>>>> 
>>> 
>>> 
>>> --
>>> //wbr, Dmitry L.
>> 
>> 
> 
> -- 
> //wbr, Dmitry L.

Re: [RESULT][VOTE] Release Apache Weex (Incubating) 0.26.0-RC2

[York Shen]

The Java namespace issue is a known problem for a while, and shall fix in next 
release(later in July or early in August) [1] .

[1] 
https://lists.apache.org/x/thread.html/b3c4974a208f87e21c1f12b4ba5e5308cf20f7678cedd4523b5ddf25@%3Cdev.weex.apache.org%3E
 
<https://lists.apache.org/x/thread.html/b3c4974a208f87e21c1f12b4ba5e5308cf20f7678cedd4523b5ddf25@%3Cdev.weex.apache.org%3E>

Best Regards,
York Shen

申远

> 在 2019年7月8日，19:29，Dmitry L.  写道：
> 
> I can compile apache-weex-incubating-0.26.0-RC2-src.tar.gz
> But it doesn't work because weex_core in archive refers to com.taobao.weex
> namespace
> But android_sdk has org.apache.taobao.weex namespace.
> 
> Also it contains some bugs which cause segfault crashes
> 
> On Mon, 8 Jul 2019 at 14:14, 王乾元  wrote:
> 
>> Hi, community
>> 
>> The vote of release Apache Weex (Incubating) 0.26.0-RC2 has passed with
>> three +1 votes
>> 
>> binding vote:
>> 
>>   - Adam Feng
>>   - YorkShen
>>   - Shihan Zheng
>> 
>> Vote thread:
>> 
>> https://lists.apache.org/x/thread.html/1fe6327f7a2775fad2ca08c6960dac8d389479fce2abbd8c6680a374@%3Cdev.weex.apache.org%3E
>> 
>> Thank you to the above PPMC members for taking time to review and
>> provide feedback of this release.
>> 
>> Next, I will proceed the vote of release Apache Weex (Incubating)
>> 0.26.0-RC2 to IPMC.
>> 
>> Best Regards.
>> 
> 
> 
> -- 
> //wbr, Dmitry L.

Re: [MeetUp] Weex MeetUp in July

[York Shen]

Due to some contingency, the meeting is rescheduled to 15th, July(UTC+8), 
HangZhou.

I am sorry if this troubles you.

Best Regards,
York Shen

申远

> 在 2019年7月3日，22:30，申远  写道：
> 
> Hi, there
> 
> There will be an offline Weex meetup on 8h, July (UTC+8) in Hangzhou. The 
> attendees shall  be developers and committers of Apache Weex. This meetup 
> will last about 1 hour and walk-in is not welcomed. But If you are 
> interested, please contact me personally. It's my pleasure to have a few 
> invited guests of the meetUp.
> 
> The meeting minutes will be published to this mailing list after the meetup.
> 
> Best Regards,
> YorkShen
> 
> 申远

Re: Podling Report Reminder - July 2019

[York Shen]

Thanks for your supporting.

BTW: What place do you recommend to host Podling report. I’d like to archive 
all Podling report of Weex and I find mailing list is not a suitable place for 
archiving purpose.

Best Regards,
York Shen

申远

> 在 2019年7月3日，14:44，Myrle Krantz  写道：
> 
> Hey all,
> 
> I've signed off with the following comment:
> 
> "Weex is doing an excellent job of identifying their own  issues, and
> seeking solutions in the broader foundation.  I concur that they are
> nearing graduation."
> 
> Best,
> Myrle
> 
> On Mon, Jul 1, 2019 at 9:04 AM 申远  <mailto:shenyua...@gmail.com>> wrote:
> 
>> As I don't receive any response yet, I will update the draft to the wiki
>> page [1]. Feel free to comment out if there is any problem here.
>> 
>> [1] https://cwiki.apache.org/confluence/display/INCUBATOR/July2019
>> 
>> Best Regards,
>> YorkShen
>> 
>> 申远
>> 
>> 
>> 申远  于2019年6月28日周五 下午12:15写道：
>> 
>>> Hi, there
>>> 
>>> I have written a draft for podling reports of Weex. I’d like to know
>>> whether it is necessary to achieve all the podling reports in somewhere,
>>> like Weex Website[1] , Github Wiki page[2] or some other place. I think
>>> mailing list may be not a proper place to write and discuss the podling
>>> reports after I have done it twice.
>>> 
>>> Anyway, the draft is shown as below:
>>> 
>>> 
>>> Weex is a framework for building Mobile cross-platform high performance
>>> UI.
>>> Weex has been incubating since 2016-11-30.
>>> 
>>> Three most important unfinished issues to address before graduating:
>>> 
>>>   1. Weex convenience library should exclude the LGPL runtime(Webkit).
>>>   2. A collection of tools should be donated to ASF, as they are
>>>   essential part of building Weex App
>>>   3. The Java package name in Weex starts with com.taobao.xxx, which
>>>   should be renamed to org.apache.xxx with a low-cost upgrading way for
>> Weex
>>>   users.
>>> 
>>> Are there any issues that the IPMC or ASF Board need to be aware of?
>>> We need an  exemption about bundle LGPL runtime in next release[3] as
>>> Google sets 1st, August as the due day.
>>> 
>>> How has the community developed since the last report?
>>> 
>>>   - Weex has participated ASOC(Alibaba summer of Code)[4] program and
>>>   there will be a postgraduate from ASOC joined Weex community in this
>>>   summer(July to August)
>>>   - There is a new committer joined Weex since last report.
>>>   - We are learning Apache Way (IP/License/Governance Model) and figured
>>>   out issues that may block graduation.
>>> 
>>> 
>>> How has the project developed since the last report?
>>> 
>>>   - We have 197 incoming pull request and 164 of them are merged
>>>   - We have 55 threads in Weex mailing list
>>>   - We have solved 200 Github issues
>>> 
>>> 
>>> How would you assess the podling's maturity? Please feel free to add your
>>> own commentary.
>>> Please feel free to add your own commentary.
>>> 
>>>   - [  ]Initial setup
>>>   - [  ]Working towards first release
>>>   - [  ] Community building
>>>   - [X] Nearing graduation
>>>   - [  ]Other:
>>> 
>>> 
>>> Date of last release:
>>> 23rd, May, 2019
>>> 
>>> 
>>> When were the last committers or PPMC members elected?
>>> 5th, April, 2019
>>> 
>>> Have your mentors been helpful and responsive?
>>> Yes, they are very helpful. We learned a lot about Apache Way from them.
>>> 
>>> [1] https://weex.apache.org/
>>> [2] https://github.com/apache/incubator-weex/wiki
>>> [3]
>>> 
>> https://lists.apache.org/thread.html/babe010a7814d4cf3d3d92588bee9dd22277b610daf83733d2622c91@%3Cgeneral.incubator.apache.org%3E
>>> [4] https://developer.aliyun.com/special/summerofcode2019en
>>> 
>>> 
>>> Best Regards,
>>> York Shen
>>> 
>>> 申远
>>> 
>>> 在 2019年6月26日，10:32，jmcl...@apache.org 写道：
>>> 
>>> *   Your project name
>>> *   A brief description of your project, which assumes no knowledge of
>>>   the project or necessarily of its field
>>> *   A list of the three most important issues to address in the move
>>>   towards graduation.
>>> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
>>>   aware of
>>> *   How has the community developed since the last report
>>> *   How has the project developed since the last report.
>>> *   How does the podling rate their own maturity.

Re: [DISCUSS] Release Weex 0.26

[York Shen]

Threeoptions:
Compile code from master branch
Import weex 0.24 [1]
Wait for Weex 0.26, which will be notified in this mailing list.

FYI: We have deleted a few git tag in Github as they are not part of any Apache 
Release nor Release Candidate. They may cause users confuse whether a Git tag 
is an Apache Release/Release candidate or not.

[1] https://weex.apache.org/download/download.html#_0-24-0 
<https://weex.apache.org/download/download.html#_0-24-0>

Best Regards,
York Shen

申远

> 在 2019年7月3日，11:15，δμδμΘχΘχ <3322054...@qq.com> 写道：
> 
> Can I directly refer to your SDK? I failed to import your SDK directly a few 
> days ago.
> 
> 
> 
> 
> -- 原始邮件 --
> 发件人: "York Shen"mailto:shenyua...@gmail.com>>;
> 发送时间: 2019年7月3日(星期三) 中午11:08
> 收件人: "dev" <mailto:dev@weex.incubator.apache.org>>;
> 
> 主题: Re: [DISCUSS] Release Weex 0.26
> 
> 
> 
> We are still cutting the release by the time you asking. But each release 
> needs two rounds vote before publishing and sometimes we need to re-vote if 
> the previous vote failed for some reasons.
> 
> In a word, we are trying our best, but I cannot guarantee you any time 
> schedule.
> 
> Best Regards,
> York Shen
> 
> 申远
> 
>> 在 2019年7月3日，10:28，δμδμΘχΘχ <3322054...@qq.com> 写道：
>> 
>> Excuse me,When will version 26 be available
>> 
>> 
>> -- 原始邮件 --
>> 发件人: "York Shen"mailto:shenyua...@gmail.com> 
>> <mailto:shenyua...@gmail.com <mailto:shenyua...@gmail.com>>>;
>> 发送时间: 2019年7月1日(星期一) 下午3:07
>> 收件人: "dev"> <mailto:dev@weex.incubator.apache.org> <mailto:dev@weex.incubator.apache.org 
>> <mailto:dev@weex.incubator.apache.org>>>;
>> 
>> 主题: Re: [DISCUSS] Release Weex 0.26
>> 
>> 
>> 
>> @lucky-chen Please give us an email notification when you settled the 
>> Android part, then @wqyfavor88 could start his work as release manager.
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远
>> 
>>> 在 2019年6月28日，19:29，York Shen >> <mailto:shenyua...@gmail.com>> 写道：
>>> 
>>> Thanks, I think @wqyfavor88 shall start release next week and I can give my 
>>> hands along the release procedure.
>>> 
>>> Best Regards,
>>> York Shen
>>> 
>>> 申远
>>> 
>>>> 在 2019年6月28日，18:08，Myrle Krantz >>> <mailto:my...@apache.org> <mailto:my...@apache.org 
>>>> <mailto:my...@apache.org>> <mailto:my...@apache.org 
>>>> <mailto:my...@apache.org> <mailto:my...@apache.org 
>>>> <mailto:my...@apache.org>>>> 写道：
>>>> 
>>>> Hey York Shen,
>>>> 
>>>> Cut the release please.  I'll stand up for you in the incubator if there's
>>>> a problem.  You've already made releases containing webkit, and you are
>>>> still in incubation.  You are aware of the problem and working with the
>>>> relevant parties.  It's not ideal, but we live in an imperfect world.  It
>>>> is good enough.
>>>> 
>>>> Best Regards,
>>>> Myrle
>>>> 
>>>> On Fri, Jun 28, 2019 at 12:04 PM 王乾元 >>> <mailto:wqyfavo...@gmail.com> <mailto:wqyfavo...@gmail.com 
>>>> <mailto:wqyfavo...@gmail.com>> <mailto:wqyfavo...@gmail.com 
>>>> <mailto:wqyfavo...@gmail.com><mailto:wqyfavo...@gmail.com 
>>>> <mailto:wqyfavo...@gmail.com>>>> wrote:
>>>> 
>>>>> I will manage the releasing of 0.26. Thanks YorkShen for his excellent 
>>>>> work
>>>>> for Weex community.
>>>>> 
>>>>> On Fri, Jun 28, 2019 at 4:25 PM York Shen >>>> <mailto:shenyua...@gmail.com> <mailto:shenyua...@gmail.com 
>>>>> <mailto:shenyua...@gmail.com>> <mailto:shenyua...@gmail.com 
>>>>> <mailto:shenyua...@gmail.com><mailto:shenyua...@gmail.com 
>>>>> <mailto:shenyua...@gmail.com>>>> wrote:
>>>>> 
>>>>>> Hi, theere
>>>>>> 
>>>>>> As Google will ban Android Apps without 64bit support in Google Play from
>>>>>> August 1st[1], we need to publish next release which including Android
>>>>>> 64bit supports ASAP to give our users enough time to upgrade. The only
>>>>>> thing that blocks us from next release is Weex Android bundled Webkit in
>>>>>> i

Re: [DISCUSS] Release Weex 0.26

[York Shen]

We are still cutting the release by the time you asking. But each release needs 
two rounds vote before publishing and sometimes we need to re-vote if the 
previous vote failed for some reasons.

In a word, we are trying our best, but I cannot guarantee you any time schedule.

Best Regards,
York Shen

申远

> 在 2019年7月3日，10:28，δμδμΘχΘχ <3322054...@qq.com> 写道：
> 
> Excuse me,When will version 26 be available
> 
> 
> -- 原始邮件 ------
> 发件人: "York Shen"mailto:shenyua...@gmail.com>>;
> 发送时间: 2019年7月1日(星期一) 下午3:07
> 收件人: "dev" <mailto:dev@weex.incubator.apache.org>>;
> 
> 主题: Re: [DISCUSS] Release Weex 0.26
> 
> 
> 
> @lucky-chen Please give us an email notification when you settled the Android 
> part, then @wqyfavor88 could start his work as release manager.
> 
> Best Regards,
> York Shen
> 
> 申远
> 
>> 在 2019年6月28日，19:29，York Shen  写道：
>> 
>> Thanks, I think @wqyfavor88 shall start release next week and I can give my 
>> hands along the release procedure.
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远
>> 
>>> 在 2019年6月28日，18:08，Myrle Krantz mailto:my...@apache.org> 
>>> <mailto:my...@apache.org <mailto:my...@apache.org>>> 写道：
>>> 
>>> Hey York Shen,
>>> 
>>> Cut the release please.  I'll stand up for you in the incubator if there's
>>> a problem.  You've already made releases containing webkit, and you are
>>> still in incubation.  You are aware of the problem and working with the
>>> relevant parties.  It's not ideal, but we live in an imperfect world.  It
>>> is good enough.
>>> 
>>> Best Regards,
>>> Myrle
>>> 
>>> On Fri, Jun 28, 2019 at 12:04 PM 王乾元 >> <mailto:wqyfavo...@gmail.com> <mailto:wqyfavo...@gmail.com 
>>> <mailto:wqyfavo...@gmail.com>>> wrote:
>>> 
>>>> I will manage the releasing of 0.26. Thanks YorkShen for his excellent work
>>>> for Weex community.
>>>> 
>>>> On Fri, Jun 28, 2019 at 4:25 PM York Shen >>> <mailto:shenyua...@gmail.com> <mailto:shenyua...@gmail.com 
>>>> <mailto:shenyua...@gmail.com>>> wrote:
>>>> 
>>>>> Hi, theere
>>>>> 
>>>>> As Google will ban Android Apps without 64bit support in Google Play from
>>>>> August 1st[1], we need to publish next release which including Android
>>>>> 64bit supports ASAP to give our users enough time to upgrade. The only
>>>>> thing that blocks us from next release is Weex Android bundled Webkit in
>>>>> its convenience binary. I am still try to get an exemption[2] from
>>>>> Incubator only for our next release. Until now, there are no response in
>>>>> this thread.
>>>>> 
>>>>> As you might see, I am busying fixing license, package name and IP issues
>>>>> around Weex these days. I’m really appreciated that if someone on the
>>>>> mailing list would volunteer to be release manager. There is nothing need
>>>>> to do for release manager until we got response from general@incubator.
>>>>> 
>>>>> BTW, I have already checked out release/0.26 [3] as the release branch
>>>> and
>>>>> the release document is here[4]. As I am a little overloaded these days,
>>>> I
>>>>> only wrote down the release document of English version. Feel free to ask
>>>>> me if there is something missed in the release document.
>>>>> 
>>>>> [1]
>>>> https://developer.android.com/distribute/best-practices/develop/64-bit 
>>>> <https://developer.android.com/distribute/best-practices/develop/64-bit> 
>>>> <https://developer.android.com/distribute/best-practices/develop/64-bit 
>>>> <https://developer.android.com/distribute/best-practices/develop/64-bit>>
>>>>> <https://developer.android.com/distribute/best-practices/develop/64-bit>
>>>>> [2]
>>>>> 
>>>> https://lists.apache.org/thread.html/babe010a7814d4cf3d3d92588bee9dd22277b610daf83733d2622c91@%3Cgeneral.incubator.apache.org%3E
>>>>> <
>>>>> 
>>>> https://lists.apache.org/thread.html/babe010a7814d4cf3d3d92588bee9dd22277b610daf83733d2622c91@%3Cgeneral.incubator.apache.org%3E
>>>>>> 
>>>>> [3] https://github.com/apache/incubator-weex/tree/release/0.26 <
>>>>> https://github.com/apache/incubator-weex/tree/release/0.26>
>>>>> [4] https://weex.apache.org/community/release-procedure.html <
>>>>> https://weex.apache.org/community/release-procedure.html>
>>>>> 
>>>>> Best Regards,
>>>>> York Shen
>>>>> 
>>>>> 申远

Re: [DISCUSS] Package name in Java code

[York Shen]

Thanks for your detail explanation.

After some thoughts during weekend, I think though users may don’t care about 
package names at all, we still need to give it a try for the best interest of 
Weex unless it’s proven impossible/impractical. We failed to make things right 
in the first year and second year, let’s make that right in the third year.

As for detail plan, considering there are a great deal of Java reflection code 
currently, proxy classes may not work well and they are also bad for 
performance. Here is what I think could solve the problem:

 "copy *everything* and let it exist under two package names”, as suggested by 
Myrle.
Rename every package name in weex_sdk from com.alibaba.xxx to org.apache.xxx 
and provide a stand-along package named weex_compatible, where classes still 
are under package name of com.alibaba.xxx but inherit from org.apache.xxx. All 
further development should be under into weex_sdk with org.apache.xxx as its 
package name, not weex_compatible. Theoretically, existing users could import 
weex_sdk and weex_compatible without changing code and new users should just 
import weex_sdk. This is what I learnt after doing some research on Apache 
dubbo this weekend [1].

This refactoring may take weeks and I am not hurry to do this in next release. 
But I think we could gain more from it than pay for it.


[1] https://github.com/apache/dubbo/tree/master/dubbo-compatible 
<https://github.com/apache/dubbo/tree/master/dubbo-compatible>


Best Regards,
York Shen

申远

> 在 2019年6月28日，18:05，Myrle Krantz  写道：
> 
> There are cases in which packages don't get renamed upon acceptance to the
> incubator, precisely because of the backwards compatibility question.  An
> example of a TLP which doesn't use "apache" in its namespaces is groovy (
> https://github.com/apache/groovy).  But it *usually* isn't a company name
> there instead.
> 
> Putting a company name there might make it more difficult to attract
> contributors who don't work for alibaba.  They might believe that only
> employees of alibaba are welcome.
> 
> What have communicated you communicated to your current users in the past
> about the stability of your APIs?  Jan is right that you could,
> theoretically replace your alibaba classes with shells to redirect,.  But
> depending on the surface area of your API, this could be a very large
> amount of work, and the result might *still* not be completely backwards
> compatible.  If you are going to change the package names, it is good
> practice to at least indicate with semantic versioning or some other
> mechanism that the new version isn't backwards compatible (you probably
> already know that).
> 
> One possibility is to just copy *everything* and let it exist under two
> package names.  Then you mark the classes in the alibaba packages as
> deprecated, and don't make future enhancements to those classes.  Users
> will be incentivized to change to the new packages, but not forced to.  You
> can go a few cycles like that until you believe most users have adjusted
> their code, and then delete the alibaba classes.  Occasional backwards
> incompatible changes made in a controlled, well-communicated manner do not
> have to be deadly sins for every project.  You will have to decide what you
> feel is appropriate for your project.  It *is* important that you
> communicate to your users how you intend to handle situations like this
> though.  People find it easier to accept things when they are not surprised.
> 
> So, the first question is: what do you think is right for your project?
> 
> Best Regards,
> Myrle
> 
> On Fri, Jun 28, 2019 at 9:58 AM Jan Piotrowski  wrote:
> 
>> As a new user, I would probably be confused to find a
>> `com.taobao.xxx/com.alibaba.xxx` package name in an Apache Software
>> Foundation project.
>> 
>> As a a developer, I have no idea how to rename a Java package in a
>> backwards compatible way though. Proxy classes maybe that just import
>> and "redirect" to the new packages?
>> 
>> I don't know if there were earlier Java/Android projects added to
>> Apache after they already had packages names in use. Might be worth
>> asking on the incubator mailing list, maybe someone can remember
>> something.
>> 
>> Best,
>> Jan
>> 
>> Am Fr., 28. Juni 2019 um 04:45 Uhr schrieb York Shen >> :
>>> 
>>> Hi, community
>>> 
>>> As Jan pointed out[1], the Android package name in Weex is
>> com.taobao.xxx/com.alibaba.xxx .
>>> 
>>> I’d like to know whether there are rules about package name in ASF’s
>> project must starts with org.apache.xxx . If so, I’d like to know if there
>> is a zero-cost/low-cost upgrading method for renaming package

Re: [DISCUSS] Release Weex 0.26

[York Shen]

@lucky-chen Please give us an email notification when you settled the Android 
part, then @wqyfavor88 could start his work as release manager.

Best Regards,
York Shen

申远

> 在 2019年6月28日，19:29，York Shen  写道：
> 
> Thanks, I think @wqyfavor88 shall start release next week and I can give my 
> hands along the release procedure.
> 
> Best Regards,
> York Shen
> 
> 申远
> 
>> 在 2019年6月28日，18:08，Myrle Krantz mailto:my...@apache.org>> 
>> 写道：
>> 
>> Hey York Shen,
>> 
>> Cut the release please.  I'll stand up for you in the incubator if there's
>> a problem.  You've already made releases containing webkit, and you are
>> still in incubation.  You are aware of the problem and working with the
>> relevant parties.  It's not ideal, but we live in an imperfect world.  It
>> is good enough.
>> 
>> Best Regards,
>> Myrle
>> 
>> On Fri, Jun 28, 2019 at 12:04 PM 王乾元 > <mailto:wqyfavo...@gmail.com>> wrote:
>> 
>>> I will manage the releasing of 0.26. Thanks YorkShen for his excellent work
>>> for Weex community.
>>> 
>>> On Fri, Jun 28, 2019 at 4:25 PM York Shen >> <mailto:shenyua...@gmail.com>> wrote:
>>> 
>>>> Hi, theere
>>>> 
>>>> As Google will ban Android Apps without 64bit support in Google Play from
>>>> August 1st[1], we need to publish next release which including Android
>>>> 64bit supports ASAP to give our users enough time to upgrade. The only
>>>> thing that blocks us from next release is Weex Android bundled Webkit in
>>>> its convenience binary. I am still try to get an exemption[2] from
>>>> Incubator only for our next release. Until now, there are no response in
>>>> this thread.
>>>> 
>>>> As you might see, I am busying fixing license, package name and IP issues
>>>> around Weex these days. I’m really appreciated that if someone on the
>>>> mailing list would volunteer to be release manager. There is nothing need
>>>> to do for release manager until we got response from general@incubator.
>>>> 
>>>> BTW, I have already checked out release/0.26 [3] as the release branch
>>> and
>>>> the release document is here[4]. As I am a little overloaded these days,
>>> I
>>>> only wrote down the release document of English version. Feel free to ask
>>>> me if there is something missed in the release document.
>>>> 
>>>> [1]
>>> https://developer.android.com/distribute/best-practices/develop/64-bit 
>>> <https://developer.android.com/distribute/best-practices/develop/64-bit>
>>>> <https://developer.android.com/distribute/best-practices/develop/64-bit>
>>>> [2]
>>>> 
>>> https://lists.apache.org/thread.html/babe010a7814d4cf3d3d92588bee9dd22277b610daf83733d2622c91@%3Cgeneral.incubator.apache.org%3E
>>>> <
>>>> 
>>> https://lists.apache.org/thread.html/babe010a7814d4cf3d3d92588bee9dd22277b610daf83733d2622c91@%3Cgeneral.incubator.apache.org%3E
>>>>> 
>>>> [3] https://github.com/apache/incubator-weex/tree/release/0.26 <
>>>> https://github.com/apache/incubator-weex/tree/release/0.26>
>>>> [4] https://weex.apache.org/community/release-procedure.html <
>>>> https://weex.apache.org/community/release-procedure.html>
>>>> 
>>>> Best Regards,
>>>> York Shen
>>>> 
>>>> 申远
>>>> 
>>>> 
>>> 
> 

Re: [DISCUSS] Release Weex 0.26

[York Shen]

Thanks, I think @wqyfavor88 shall start release next week and I can give my 
hands along the release procedure.

Best Regards,
York Shen

申远

> 在 2019年6月28日，18:08，Myrle Krantz  写道：
> 
> Hey York Shen,
> 
> Cut the release please.  I'll stand up for you in the incubator if there's
> a problem.  You've already made releases containing webkit, and you are
> still in incubation.  You are aware of the problem and working with the
> relevant parties.  It's not ideal, but we live in an imperfect world.  It
> is good enough.
> 
> Best Regards,
> Myrle
> 
> On Fri, Jun 28, 2019 at 12:04 PM 王乾元  wrote:
> 
>> I will manage the releasing of 0.26. Thanks YorkShen for his excellent work
>> for Weex community.
>> 
>> On Fri, Jun 28, 2019 at 4:25 PM York Shen  wrote:
>> 
>>> Hi, theere
>>> 
>>> As Google will ban Android Apps without 64bit support in Google Play from
>>> August 1st[1], we need to publish next release which including Android
>>> 64bit supports ASAP to give our users enough time to upgrade. The only
>>> thing that blocks us from next release is Weex Android bundled Webkit in
>>> its convenience binary. I am still try to get an exemption[2] from
>>> Incubator only for our next release. Until now, there are no response in
>>> this thread.
>>> 
>>> As you might see, I am busying fixing license, package name and IP issues
>>> around Weex these days. I’m really appreciated that if someone on the
>>> mailing list would volunteer to be release manager. There is nothing need
>>> to do for release manager until we got response from general@incubator.
>>> 
>>> BTW, I have already checked out release/0.26 [3] as the release branch
>> and
>>> the release document is here[4]. As I am a little overloaded these days,
>> I
>>> only wrote down the release document of English version. Feel free to ask
>>> me if there is something missed in the release document.
>>> 
>>> [1]
>> https://developer.android.com/distribute/best-practices/develop/64-bit
>>> <https://developer.android.com/distribute/best-practices/develop/64-bit>
>>> [2]
>>> 
>> https://lists.apache.org/thread.html/babe010a7814d4cf3d3d92588bee9dd22277b610daf83733d2622c91@%3Cgeneral.incubator.apache.org%3E
>>> <
>>> 
>> https://lists.apache.org/thread.html/babe010a7814d4cf3d3d92588bee9dd22277b610daf83733d2622c91@%3Cgeneral.incubator.apache.org%3E
>>>> 
>>> [3] https://github.com/apache/incubator-weex/tree/release/0.26 <
>>> https://github.com/apache/incubator-weex/tree/release/0.26>
>>> [4] https://weex.apache.org/community/release-procedure.html <
>>> https://weex.apache.org/community/release-procedure.html>
>>> 
>>> Best Regards,
>>> York Shen
>>> 
>>> 申远
>>> 
>>> 
>> 

[DISCUSS] Release Weex 0.26

[York Shen]

Hi, theere

As Google will ban Android Apps without 64bit support in Google Play from 
August 1st[1], we need to publish next release which including Android 64bit 
supports ASAP to give our users enough time to upgrade. The only thing that 
blocks us from next release is Weex Android bundled Webkit in its convenience 
binary. I am still try to get an exemption[2] from Incubator only for our next 
release. Until now, there are no response in this thread.

As you might see, I am busying fixing license, package name and IP issues 
around Weex these days. I’m really appreciated that if someone on the mailing 
list would volunteer to be release manager. There is nothing need to do for 
release manager until we got response from general@incubator.

BTW, I have already checked out release/0.26 [3] as the release branch and the 
release document is here[4]. As I am a little overloaded these days, I only 
wrote down the release document of English version. Feel free to ask me if 
there is something missed in the release document.

[1] https://developer.android.com/distribute/best-practices/develop/64-bit 
<https://developer.android.com/distribute/best-practices/develop/64-bit>
[2] 
https://lists.apache.org/thread.html/babe010a7814d4cf3d3d92588bee9dd22277b610daf83733d2622c91@%3Cgeneral.incubator.apache.org%3E
 
<https://lists.apache.org/thread.html/babe010a7814d4cf3d3d92588bee9dd22277b610daf83733d2622c91@%3Cgeneral.incubator.apache.org%3E>
[3] https://github.com/apache/incubator-weex/tree/release/0.26 
<https://github.com/apache/incubator-weex/tree/release/0.26>
[4] https://weex.apache.org/community/release-procedure.html 
<https://weex.apache.org/community/release-procedure.html>

Best Regards,
York Shen

申远

[DISCUSS] Package name in Java code

[York Shen]

Hi, community

As Jan pointed out[1], the Android package name in Weex is 
com.taobao.xxx/com.alibaba.xxx .

I’d like to know whether there are rules about package name in ASF’s project 
must starts with org.apache.xxx . If so, I’d like to know if there is a 
zero-cost/low-cost upgrading method for renaming package names. It’s easy to 
rename all Android package to org.apache.xxx , but users would probably have a 
lot of complains about this renaming, which should cause compiling error when 
our users are building Android App with latest Weex.

BTW: This is only for Android(Java Code), as there is no such concept(Package 
Name) in C++/C/Objective C/JavaScript.

[1] https://github.com/apache/incubator-weex/issues/2148 
<https://github.com/apache/incubator-weex/issues/2148>
[2] 
https://github.com/apache/incubator-weex/blob/master/android/sdk/src/main/java/com/taobao/weex/WXSDKEngine.java
 
<https://github.com/apache/incubator-weex/blob/master/android/sdk/src/main/java/com/taobao/weex/WXSDKEngine.java>

Best Regards,
York Shen

申远

Re: 64bit sdk for android

[York Shen]

Please be noticed Weex cannot publish any release before LGPL issue is settled. 
In worst case, you may have checkout from master branch and compile it on your 
own hand. I’m sorry if that troubles you.

[1] 
https://lists.apache.org/thread.html/babe010a7814d4cf3d3d92588bee9dd22277b610daf83733d2622c91@%3Cgeneral.incubator.apache.org%3E
 
<https://lists.apache.org/thread.html/babe010a7814d4cf3d3d92588bee9dd22277b610daf83733d2622c91@%3Cgeneral.incubator.apache.org%3E>

Best Regards,
York Shen

申远

> 在 2019年6月14日，18:12，dyy199...@gmail.com 写道：
> 
> Hi, I am dealing with this issue, arm64-v8a has been supported this weex, And 
> Our team is testing this version now. I will commit a pr to apache Master 
> branch next week if there is no bug.
> 
> 
>> 在 2019年6月14日，下午6:06，chenjuncheng  写道：
>> 
>> 
>> Week can support 64bit sdk for android ? When can i get it?when?
>> 
>> Sent from YoMail
> 

Re: 【Alibaba Summer of Code】Introduction And Some Questions

[York Shen]

It’s your choice whether or not sharing the proposal entirely in the mailing 
list. As this is an open mailing list and we have limited quota for ASOC, all 
the applicant could see your proposal, which may be unfair to you. But asking 
related question of ASOC in this mailing list is always encouraged.

Best Regards,
York Shen

申远

> 在 2019年6月13日，18:54，WM  写道：
> 
> Hi YorkShen,
> 
> Thank you for your detailed reply.  I have a better understanding of those 
> issues now. I will finish the proposal as soon as possible and give it to you 
> for discussion.
> 
> Best wishes,
> Renmin Wang 
> 王仁敏
> 
> 
>> 2019年6月13日 16:57，申远  写道：
>> 
>> Well, I'm going to answer your question one by one.
>> 
>> 1. Help to build a user-friendly and high availability continuous
>>> integration(CI) environment and trigger the CI build each time a GitHub PR
>>> is created or updated.
>>> I found that Travis CI has been integrated into the project which has met
>>> the issue's requirements.  After my investigation, I believe Travis CI is
>>> the best choice for our project, which is an open source project that might
>>> need a free MAC image. So, does the CI referred in the issue specially
>>> means Travis CI?
>> 
>> 
>> Yes, according to ASF's policy[1], Travis CI and Jenkins are the only two
>> options you have. I'd prefer Travis CI, which is more modern and easy to
>> use compared to Jenkins. But as you already know, Travis CI of Weex is
>> broken for a while as it doesn't provide a NDK downloading API. I am still
>> trying to fix it, have a look at the PR [2].
>> 
>> 2. Help to build a mobile test infrastructure which provides the ability of
>>> Android and iOS UI/interface test upon the CI environment.
>>> Does this specifically mean writing UITest for UI components, such as
>>>  and  etc.
>> 
>> 
>> No.  Test infrastructure here is a big words, which include the following
>> things at least:
>> 
>>  - Unit Test. You can use Junit for Java code and Google Test for C++
>>  code or any other tools you'd like to use.
>>  - UI Test. We used to run UI test on Macaca but it's broken for a long
>>  time. Based on its poor behavior and limited ability, I'd personally
>>  suggest you consider some other tools.
>>  - Memory Test. Base on my research.  ASAN[3] is a really good to for C++
>>  Memory leak test.
>>  - Performance Test . Though we don't have a proper solution now, but I
>>  don't think this is a difficult task. You can just start the app, run some
>>  case, calculating the time spent.
>>  - Other format tests you can image.
>> 
>> All the test mentioned above should run the CI platform (e.g. Travis CI)
>> 
>> 3. Help to build a static code lint system
>>> I found out that Weex will choose ESLint as the default Code Lint tool
>>> when installing, and both the Vue and Rax can use ESLint for static code
>>> analysis. So does "help to build the static Code Lint system" refer to
>>> incubator-weex Project itself?
>> 
>> 
>> Weex includes C++, Java, Objective C and JavaScript codes. ESLint is only
>> available for JavaScript code, which doesn't get changed over months. You
>> should focus on Lint tools for C++, Java, Objective C. The lint system is
>> expected to run on the CI platform as well.
>> 
>> Finally, is there any specific content requirements and templates that I
>>> have to follow in my proposal? For example, the Proposal of GSOC includes
>>> Project Description, Project Outline, and Timeline, etc. Or is there any
>>> suggestions?
>> 
>> 
>> There is a time schedule and FAQ[4], but for other parts, I am afraid the
>> answer is No. We don't have a template now, after all, this is the first
>> year of ASOC(Alibaba Summer Of Code).
>> 
>> BTW: You may change the opening line of the mail to Community, Contributor
>> or Committer next time as Mentor[4] has special meaning in Apache Incubator.
>> 
>> [1]
>> https://lists.apache.org/thread.html/3645db8421407b247947820cab2dea33b817c08a1b12d20ce182dcaf@%3Cgeneral.incubator.apache.org%3E
>> [2] https://github.com/apache/incubator-weex/pull/2319
>> [3] https://source.android.com/devices/tech/debug/asan.html
>> [4] https://developer.aliyun.com/special/summerofcode2019en
>> [5] https://community.apache.org/mentoringprogramme.html
>> 
>> 
>> Best Regards,
>> YorkShen
>> 
>> 申远
>> 
>> 
>> WM  于2019年6月12日周三 下午10:16写道：
>> 
>>> Dear Mentors:
>>> 
>>> My name 

[ANNOUNCEMENT] The minute of Weex Meetup - June 10th, 2019

[York Shen]

Date
June 10th, 2019 (UTC+8)

Attendances

The following PPMC members were present:
York Shen
The following committers were present:
Hanks Zhang
Ling He
Peihan Chen
Qianyuan Wang
Yayun Dong
Minute of Weex MeetUp
LGPL License
The fact that Weex contains LGPL licensed header file(.h file) may be a block 
issue for our next release or even graduation. The detail is discussed in 
another mailing list[1], I will just give a brief explanation here

Weex just copied about the shared library and 1500 header file from Webkit 
which is a mixture of BSD and LGPL license, and 150 of them are under LGPL 
license.  Though those files are just header files ( .h files), and Weex 
dynamic links to the shared library of Webkit. I am still not sure whether this 
is a violation of ASF's license policy. If this is not allowed by ASF’s policy, 
we can cut down the header files to 50 and all of the files are under BSD 
license by a major change. After the change, we still need to dynamic link to 
the Webkit which is still a mixture of LGPL and BSD license at runtime. But any 
serious programs on Linux at runtime have to link to glic which is also under 
LGPL license, we don’t think linking a LGPL share library at runtime is a 
problem here.

Potential violation of ASF copyright or trademark
As it's discussed before, if users are able to create a Weex App only using 
tools under Apache Weex, then a good part of the problems might be solved. With 
donating the following project to ASF, the issue will be well solved.
https://github.com/weexteam/weex-vue-loader 
<https://github.com/weexteam/weex-vue-loader>
https://github.com/weexteam/weex-loader 
<https://github.com/weexteam/weex-loader>
https://github.com/weexteam/weex-toolkit 
<https://github.com/weexteam/weex-toolkit>
It’s still unclear whether the IP of the following repos belongs to individuals 
or company, but considering the authors of the above repos giving up their IP, 
it’s enough if we get company signed on the SGA.

Action:
@Hanks Zhang will be responsible for figuring out dependencies of the repos
@York Shen will be responsible for prepare the SGA.

Besides, Weex playground and weex_sdk should be separated into two repos, but 
this is not a blocking.

Next meetup
The time of next offline meetup is not clear but shall be scheduled several 
weeks later, with email notification in this mailing list.

[1] 
https://lists.apache.org/thread.html/ed725c9b6ff5ff658f8c639ed8116bfb0be44f46cfb7fcb52284b065@%3Cdev.weex.apache.org%3E
 
<https://lists.apache.org/thread.html/ed725c9b6ff5ff658f8c639ed8116bfb0be44f46cfb7fcb52284b065@%3Cdev.weex.apache.org%3E>

Best Regards,
York Shen

申远

Re: A change to your GitHub Marketplace subscription

[York Shen]

Got it. Thanks

> 在 2019年6月7日，09:13，Chris Lambertus  写道：
> 
> Hi folks,
> 
> Per INFRA-17365, we received this message today that GitHub is discontinuing 
> issue.sh as of tomorrow.
> 
> -Chris
> ASF Infra
> 
> 
> 
> 
>> Begin forwarded message:
>> 
>> From: GitHub 
>> Subject: A change to your GitHub Marketplace subscription
>> Date: June 6, 2019 at 2:30:43 PM PDT
>> To: 
>> Reply-To: priv...@infra.apache.org
>> Reply-To: GitHub 
>> 
>> Hi
>>  there,
>> 
>> We're writing to let you know that Issue.sh has been delisted from GitHub 
>> Marketplace and your active subscription will be canceled on Friday, June 
>> 7th.
>> 
>> Please review the Project Management category 
>> 
>>  in Marketplace for other tools that may meet your needs.
>> 
>> Happy shipping,
>> GitHub Marketplace team
>> 
>> Unsubscribe 
>> 
>>  · Email preferences 
>> 
>>  · Terms 
>> 
>>  · Privacy 
>> 
>>  · Sign in to GitHub 
>> 
>> GitHub, Inc.
>> 88 Colin P Kelly Jr St.
>> San Francisco, CA 94107
>> 
>> 
> 

Re: Weex Trademark(CopyRight) issue

[York Shen]

I agreed with that. Users should and could create a Weex App only using tools 
under Apache Weex. If this is not possible, we should consider donating 
corresponding tools to ASF.

While, one of the reason that stops us from donating tools to ASF is the IP of 
the tools is unclear. At least I know some of the tools are developed at work 
time with company’s laptop. Under this case, I am not sure the IP belongs to 
individual or company.

> 在 2019年6月6日，22:05，Jan Piotrowski  写道：
> 
> That sounds like a good plan YorkShen.
> 
> For me, with a user hat on,
> https://weex.apache.org/guide/develop/create-a-new-app.html is
> definitely the first place I will go to test Weex. So I will be told
> to use `weex-toolkit`. The preview rendered by `npm start` will tell
> me to use https://weex.apache.org/tools/playground.html.
> 
> So for the toolkit we definitely need a solution, as this will
> effectively be understood as "being" Weex by users (When people talk
> about Apache Cordova, they often actually mean the CLI `cordova` - for
> `weex` this comes from the toolkit).
> The playground app needs to come from Apache Weex as well, and be
> released as a normal Apache Weex project - but we already talked about
> that elsewhere and this is in progress if  I understood correctly. (It
> then of course should also not be listed under "Third Party Tools" on
> the website any more).
> 
> A bit confusing might be https://weex.apache.org/tools/dotwe.html
> which is linked as "Online Playground", which indicates to belong to
> the Playground app, but is actually a third party thing hosted on
> editor.weex.io (which of course it not ok as domain). What you get
> clicking the link also actually looks different than the preview
> screenshot, which looks a lot more like http://dotwe.org/vue/ - which
> itself is not linked at all in "Third Party Tools".
> 
> If I as a user can follow the "Create a new app" instructions without
> needing to use third party tools or encountering confusing links and
> discrepancies, a good part of the problems might be solved already.
> 
> -J
> 
> PS: Small bug report: https://weex.apache.org/tools/ide.html shows
> Chinese disclaimer.
> 
> Am Do., 6. Juni 2019 um 12:08 Uhr schrieb 申远 :
>> 
>> Hi, community
>> 
>> I spent some time this week to figure out what are essential parts to run
>> Apache Weex and what are not. Those essential part should go into Apahce
>> Weex's umbrella, while others could change their name to avoid violation of
>> ASF's trademark and copyright. What's more, the document itself should be
>> clear enough about what exactly users download or install when they use
>> Weex and where it come from. Here are progresses and issues still need
>> solved.
>> 
>> Documentation
>> The following issues are solved, all of the are marked as Un-Apache or
>> deleted:
>> 
>>   - https://weex.apache.org/tools/ide.html
>>   - https://weex.apache.org/tools/extension.html
>>   - https://weex.apache.org/tools/toolkit.html
>>   - https://weex.apache.org/404.html
>>   - https://github.com/weex-plugins
>>   - https://github.com/weexteam/ (Some of the repos may still have
>>   problems, see later discussion about Github Repo)
>> 
>> BTW: After some negotiation, I am a administor of the last two Github team.
>> And I will guide those repos to make sure all of them are not violation of
>> ASF's policies.
>> 
>> The following issues doesn't need solved, as they are clear about whether
>> they are part of Apache or not.
>> 
>>   - https://weex.apache.org/tools/playground.html
>>   - https://github.com/weexext
>>   - https://github.com/weex-cli
>> 
>> Currently, there are two essential tools listed in the documents and none
>> of them are under ASF:
>> 
>>   - weex-toolkit [1]
>>   - vue-loader [2]
>> 
>> Weex-toolkit is a collection of useful tools, maybe we could find a
>> replacement for it and rewrite the corresponding document. As for
>> vue-loader, I don't think users can build Weex without it. Correct me if I
>> am wrong, as I am not that familiar with front-side-engineering.
>> 
>> Github repositories
>> The following github repositories may lead confusion, as it's hard for
>> developers to understand whether they are part of Apache Weex or not. As
>> Weex document clearly said vue-loader as essential part [2], I am not sure
>> which of the following repoes are vue-loader and their relationships.
>> 
>>   - https://github.com/weexteam/weex-vue-render
>>   - https://github.com/weexteam/weex-vue-loader
>>   - https://github.com/weexteam/weex-vue-precompiler
>>   - https://github.com/weexteam/weex-builder
>>   - https://github.com/weexteam/weex-loader
>> 
>> Host Name
>> The following host name is clear about they are not part of Apache Weex, I
>> don't think we need pay more attention:
>> 
>>   - http://dotwe.org/vue/
>> 
>> The following host name may need more eyes, as they may lead confusion:
>> 
>>   - http://editor.weex.io/
>> 
>> [1] https://weex.apache.org/guide/develop/create-a-new-app.html
>> 

Re: [incubator-weex] annotated tag 0.9.1.7 deleted (was 7e9a946)

[York Shen]

Ref https://github.com/apache/incubator-weex/pull/2481 
<https://github.com/apache/incubator-weex/pull/2481>, which explains the reason 
of the bug and provides a fix.

Best Regards,
York Shen

申远

> 在 2019年5月24日，17:56，York Shen  写道：
> 
> Well, there is a bug in weex release script, which caused me pushing about 
> 300 local tag to GitHub yesterday. These 300 tags could cause confusion as 
> most of them are neither official release or release candidate. They are just 
> my local tags indicated daily building.
> 
> So, I just deleted the wrong tag and still remained the tag of official 
> release or release candidate.
> 
> I will fix the bug in the release script later.
> 
> Best Regards,
> York Shen
> 
> 申远
> 
>> 在 2019年5月24日，17:49，Willem Jiang > <mailto:willem.ji...@gmail.com>> 写道：
>> 
>> Can I know why do we remove these tags?
>> It's very danger to change the tags without any notification.
>> 
>> Willem Jiang
>> 
>> Twitter: willemjiang
>> Weibo: 姜宁willem
>> 
>> 
>> -- Forwarded message -
>> From: mailto:ky...@apache.org>>
>> Date: Fri, May 24, 2019 at 5:38 PM
>> Subject: [incubator-weex] annotated tag 0.9.1.7 deleted (was 7e9a946)
>> To: comm...@weex.apache.org <mailto:comm...@weex.apache.org> 
>> mailto:comm...@weex.apache.org>>
>> 
>> 
>> This is an automated email from the ASF dual-hosted git repository.
>> 
>> kyork pushed a change to annotated tag 0.9.1.7
>> in repository https://gitbox.apache.org/repos/asf/incubator-weex.git 
>> <https://gitbox.apache.org/repos/asf/incubator-weex.git>.
>> 
>> 
>> *** WARNING: tag 0.9.1.7 was deleted! ***
>> 
>>   tag was  7e9a946
>> 
>> The revisions that were on this annotated tag are still contained in
>> other references; therefore, this change does not discard any commits
>> from the repository.
> 

Re: [incubator-weex] annotated tag 0.9.1.7 deleted (was 7e9a946)

[York Shen]

Well, there is a bug in weex release script, which caused me pushing about 300 
local tag to GitHub yesterday. These 300 tags could cause confusion as most of 
them are neither official release or release candidate. They are just my local 
tags indicated daily building.

So, I just deleted the wrong tag and still remained the tag of official release 
or release candidate.

I will fix the bug in the release script later.

Best Regards,
York Shen

申远

> 在 2019年5月24日，17:49，Willem Jiang  写道：
> 
> Can I know why do we remove these tags?
> It's very danger to change the tags without any notification.
> 
> Willem Jiang
> 
> Twitter: willemjiang
> Weibo: 姜宁willem
> 
> 
> -- Forwarded message -
> From: 
> Date: Fri, May 24, 2019 at 5:38 PM
> Subject: [incubator-weex] annotated tag 0.9.1.7 deleted (was 7e9a946)
> To: comm...@weex.apache.org 
> 
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> kyork pushed a change to annotated tag 0.9.1.7
> in repository https://gitbox.apache.org/repos/asf/incubator-weex.git.
> 
> 
> *** WARNING: tag 0.9.1.7 was deleted! ***
> 
>   tag was  7e9a946
> 
> The revisions that were on this annotated tag are still contained in
> other references; therefore, this change does not discard any commits
> from the repository.

Re: Summer of Code

[York Shen]

Don’t worry and take your time. The official deadline for application of ASOC 
is 15th, Jun, as described in the Github Page. This is just a problem for 
warming-ing up, you have enough time to finish it and make your proposal 
impressing.

BTW, The team of ASOC will publish an English version for their website this 
week. For now, you only have a Chinese page 
https://developer.aliyun.com/summerofcode2019 
<https://developer.aliyun.com/summerofcode2019> .

Best Regards,
York Shen

申远

> 在 2019年5月15日，17:28，rohan julka  写道：
> 
> I would definitely like to work on this issue but right now I am not so
> familiar with the concepts therefore I need some time to get familiarized
> with the concepts and the project itself, moreover I have some university
> work to do right now, So will it be okay if I work on this after 20th May?
> 
> Regards,
> Rohan
> 
> On Wed, May 15, 2019, 2:45 PM 申远  wrote:
> 
>> Rohan, thanks for reaching out.
>> 
>> As mentioned in Github Page, you can apply ASOC(Alibaba summer of Code)
>> through https://page.aliyun.com/form/act1008956472/index.htm . The recruit
>> team of ASOC will handle your application.
>> 
>> FYI: If you want to get your hands dirty now, you could help us by fixing
>> TravisCI problem. The TravisCI of Weex always fails as TravisCI doesn't
>> provide an official API for download Android NDK. I have wrote a incomplete
>> demo to fix the problem, ref
>> https://github.com/apache/incubator-weex/pull/2319/files if you are
>> interested.
>> 
>> Best Regards,
>> YorkShen
>> 
>> 申远
>> 
>> 
>> rohan julka  于2019年5月15日周三 下午1:11写道：
>> 
>>> Hi,
>>> 
>>> I am Rohan, I have participated in Google Summer of Code  with Apache
>>> Software Foundation before and it was a great experience for me, So I
>> want
>>> to work on the issue "High Availability and continous integration" [1]
>>> under Alibaba Summer of Code this time.
>>> 
>>> 
>>> [1] https://github.com/apache/incubator-weex/issues/2421
>>> 
>>> Regards,
>>> Rohan
>>> 
>> 

Re: [DISCUSS] Summer Program of Students for Weex

[York Shen]

Well, the schedule of Asoc for next year is not known now, but from what I have 
been told, projects can get in touched with Asoc by 
aliopensou...@alibabacloud.com <mailto:aliopensou...@alibabacloud.com> .

FYI: Asoc only has a Chinese website for students to apply 
https://developer.aliyun.com/summerofcode2019 
<https://developer.aliyun.com/summerofcode2019> 

Best Regards,
York Shen

申远

> 在 2019年5月10日，17:19，Myrle Krantz  写道：
> 
> Hey YorkShen,
> 
> That's fine and it sounds like Apache already has some representation which
> makes me happy.
> 
> But I would be very interested in increasing visibility of this for next
> year.  How do projects apply, and when does the process start?
> 
> Best,
> Myrle
> 
> On Fri, May 10, 2019 at 5:18 AM 申远  wrote:
> 
>> I'm informed that Asoc (Alibaba summer of code) have recruited enough open
>> source projects now. And I quoted the words of the manager of Asoc "This is
>> just the first year of Asoc, it is possible to include more available
>> Apache projects next year."
>> 
>> Best Regards,
>> YorkShen
>> 
>> 申远
>> 
>> 
>> Myrle Krantz  于2019年5月9日周四 下午6:03写道：
>> 
>>> Wonderful!  If you do need anything from the board, please let me know.
>>> I'll be happy to help.
>>> 
>>> Best,
>>> Myrle
>>> 
>>> On Thu, May 9, 2019 at 11:51 AM 申远  wrote:
>>> 
>>>> Understood.
>>>> 
>>>> I am going to ask the manager of Alibaba Summer of Code (not sure the
>>>> official name) that whether he/she would be interested to invite Apache
>>>> projects as their candidate. If so, I will move this thread to
>>>> d...@community.apache.org to if there is any Apache project interested
>> in
>>>> this Summer Program.
>>>> 
>>>> Best Regards,
>>>> YorkShen
>>>> 
>>>> 申远
>>>> 
>>>> 
>>>> Myrle Krantz  于2019年5月9日周四 下午4:40写道：
>>>> 
>>>>> Well, I am on the board, but I don't think you need board approval.
>> I
>>>>> suggest bringing it to ComDev (d...@community.apache.org).
>>>>> ComDev is where GSoC is also managed, so it seems like a natural home
>>> for
>>>>> this.
>>>>> 
>>>>> This is really good news!
>>>>> 
>>>>> Thank you,
>>>>> Myrle
>>>>> 
>>>>> On Thu, May 9, 2019 at 10:26 AM 申远  wrote:
>>>>> 
>>>>>> For now, I think Apache Flink, Apache RocketMQ, Apache
>>> Incubator-Dubbo
>>>>> and
>>>>>> Apache Incubator-Weex projects have or would have joined the Summer
>>>>>> Program.
>>>>>> 
>>>>>> I could ask the possibility of all Apache project participating the
>>>>> Summer
>>>>>> Program, but maybe someone on behalf of the ASF Board could have
>> the
>>>>> final
>>>>>> decision.
>>>>>> 
>>>>>> Best Regards,
>>>>>> YorkShen
>>>>>> 
>>>>>> 申远
>>>>>> 
>>>>>> 
>>>>>> Myrle Krantz  于2019年5月9日周四 下午4:03写道：
>>>>>> 
>>>>>>> That's pretty awesome!  Is this something that could benefit
>> other
>>>>> Apache
>>>>>>> projects too?
>>>>>>> 
>>>>>>> Best Regards,
>>>>>>> Myrle
>>>>>>> 
>>>>>>> On Thu, May 9, 2019 at 9:51 AM 申远  wrote:
>>>>>>> 
>>>>>>>> Hi, community
>>>>>>>> 
>>>>>>>> I'm informed by an employee of Alibaba Group that they are
>>> hosting
>>>> a
>>>>>>> summer
>>>>>>>> program intended to engage undergraduates/postgraduates into
>> open
>>>>>> source
>>>>>>>> software development. He offered me a chance to include Weex in
>>>> their
>>>>>>>> summer program and in my opinion it would be great if Weex
>> could
>>>>>>>> participate as we do need more developers from community.
>>>>>>>> 
>>>>>>>> As far as my knowledge, it is similar to Google summer of Code
>>>>>>>> <https://summerofcode.withgoogle.com/>, one can look the
>> detail
>>>>>> proposal
>>>>>>>> of
>>>>>>>> Weex summer of Code on our Github site
>>>>>>>> <https://github.com/apache/incubator-weex/issues/2422>.
>>>>>>>> 
>>>>>>>> Best Regards,
>>>>>>>> YorkShen
>>>>>>>> 
>>>>>>>> 申远
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 

Re: Podling Report Reminder - April 2019

[York Shen]

@Willem
 
I have updated the website and mark all the non-Apache things clearly.

Best Regards,
York Shen

申远

> 在 2019年4月1日，20:50，York Shen  写道：
> 
> Agreed with that. I will prepare a Github PR to remove the potential branding 
> violations after release things are settled.
> 
> Best Regards,
> York Shen
> 
> 申远
> 
>> 在 2019年4月1日，14:26，Willem Jiang > <mailto:willem.ji...@gmail.com>> 写道：
>> 
>> We need to stop this kind of branding violation actions thing first by
>> removing the tools link from website.
>> We could let the tools team to host the download themself and they
>> could add "powered by Weex" in their site, but they cannot use "Weex"
>> in their product name.
>> 
>> Willem Jiang
>> 
>> Twitter: willemjiang
>> Weibo: 姜宁willem
>> 
>> On Mon, Apr 1, 2019 at 11:24 AM 申远 > <mailto:shenyua...@gmail.com>> wrote:
>>> 
>>> Thanks for your message.
>>> 
>>> 1.  We don't have the download link for the weex project.
>>> 
>>> 
>>> I will handle this issue ASAP
>>> 
>>> 2. There are lots download links tools[1] in the weex website, which source
>>>> code are not part of apache weex project.
>>> 
>>> As it is not clear that we should invite them as Apache weex, or mark them
>>> Un-Apache Weex and notify them to rename their names, I think we need some
>>> time to handle this problem.
>>> 
>>> 
>>> Best Regards,
>>> YorkShen
>>> 
>>> 申远
>>> 
>>> 
>>> Willem Jiang mailto:willem.ji...@gmail.com>> 
>>> 于2019年4月1日周一 上午11:13写道：
>>> 
>>>> Hi，
>>>> 
>>>> There are some issues on the weex apache website which need to be resolved
>>>> ASAP.
>>>> 1.  We don't have the download link for the weex project.
>>>> 2. There are lots download links tools[1] in the weex website, which
>>>> source code are not part of apache weex project.
>>>> 
>>>> [1]https://weex.apache.org/tools/ <https://weex.apache.org/tools/>
>>>> 
>>>> Willem Jiang
>>>> 
>>>> Twitter: willemjiang
>>>> Weibo: 姜宁willem
>>>> 
>>>> On Tue, Mar 26, 2019 at 11:31 AM York Shen >>> <mailto:shenyua...@gmail.com>> wrote:
>>>>> 
>>>>> Hi, there
>>>>> 
>>>>> As we need to prepare the Weex Podling Reports before 3rd, April, and we
>>>> have a national holiday in 5th, April in China, we’d better finish the
>>>> report a little earlier.
>>>>> 
>>>>> The content of the report draft is below:
>>>>> 
>>>>> Weex is a framework for building Mobile cross-platform high performance
>>>> UI.
>>>>> 
>>>>> Weex has been incubating since 2016-11-30.
>>>>> 
>>>>> Three most important unfinished issues to address before graduating:
>>>>>  1. Third party plugins like weex-toolkit is not part of Apache Weex,
>>>> and they may violate the trademark / copyright of ASF
>>>>>  2. The release procedure for Weex is not documented clearly.
>>>>>  3. More active committers and PPMC members should be invited into the
>>>> community.
>>>>> 
>>>>> Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
>>>>> aware of?
>>>>> No
>>>>> 
>>>>> 
>>>>> How has the community developed since the last report?
>>>>> 1. There are two new committers for Weex, e.g. He Ling and Darin726.
>>>>> 2. We have a new mentor : Jan Piotrowski
>>>>> 3. The mailing list for weex community is getting better, as we have 28
>>>> mailing threads in d...@weex.apache.org <mailto:d...@weex.apache.org> 
>>>> <mailto:d...@weex.apache.org <mailto:d...@weex.apache.org>>
>>>>> 
>>>>> 
>>>>> How has the project developed since the last report?
>>>>> 1. We launched new website for Weex.
>>>>> 2. We merged and closed 144 Github PRs
>>>>> 3. We had 212 Github issues created and 145 of them are solved.
>>>>> 
>>>>> 
>>>>> How would you assess the podling's maturity?
>>>>> Please feel free to add your own commentary.
>>>>>  [ ] Initial setup
>>>>>  [ ] Working towards

Re: [DISCUSS] Weex Download Page

[York Shen]

Got it. I will create a download page and make it right during the next release 
process.

Best Regards,
York Shen

申远

> 在 2019年4月23日，23:30，Jan Piotrowski  写道：
> 
>> Is there a webpage for release note or change log except for the 
>> RELEASENOTES.md in Cordova?
> 
> blog.cordova.io is a blog with posts about releases.
> 
>> Or is it necessary to have that page?
> 
> Not that I know of.
> 
>> Does it comply the ASF’s policy if Weex continues to include npm/gradle 
>> distribution channel in Github page 
>> https://github.com/apache/incubator-weex#weex 
>> <https://github.com/apache/incubator-weex#weex> ?
> 
> I personally see no problem in linking do npm, gradle, or whatever
> _additional_ distribution methods a project uses for developer
> convenience. The idea behind the rules of Apache are that developers
> can understand what software they are actually downloading. If you
> make sure the Apache releases are equal to npm/gradle/whatever, that
> goal is reached and everything should be fine.
> 
> -J
> 
> Am Di., 23. Apr. 2019 um 13:38 Uhr schrieb York Shen :
>> 
>> Found it. Thanks.
>> 
>> Is there a webpage for release note or change log except for the 
>> RELEASENOTES.md in Cordova? Or is it necessary to have that page?
>> 
>> Does it comply the ASF’s policy if Weex continues to include npm/gradle 
>> distribution channel in Github page 
>> https://github.com/apache/incubator-weex#weex 
>> <https://github.com/apache/incubator-weex#weex> ?
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远
>> 
>>> 在 2019年4月23日，19:21，Jan Piotrowski  写道：
>>> 
>>> I would guess the .tgz includes the RELEASENOTES.md that is also in
>>> the source code repository.
>>> 
>>> As I wrote before, I am at least not aware of any complaints about how
>>> Cordova does things from Apache.
>>> 
>>> -J
>>> 
>>> Am Di., 23. Apr. 2019 um 13:12 Uhr schrieb York Shen :
>>>> 
>>>> Actually, I’d like to adopt Cordova’s distribution mechanism and 
>>>> corresponding webpages if it complies ASF policy.
>>>> 
>>>> As far as I understand, Weex is very similar to Cordova.  Main users of 
>>>> both are front-end engineers, who would prefer npm or gradle as 
>>>> distribution mechanism.
>>>> 
>>>> But is there ChangeLog/ReleaseNote pages for Cordova’s Source Distribution?
>>>> 
>>>> Best Regards,
>>>> York Shen
>>>> 
>>>> 申远
>>>> 
>>>>> 在 2019年4月23日，18:00，Jan Piotrowski  写道：
>>>>> 
>>>>> What part of the release policy are you specifically referring to?
>>>>> 
>>>>> The main distribution mechanism for Apache Cordova is npm, which
>>>>> command is mentioned in the "Get started" [1] part of the homepage and
>>>>> installations instructions [2] of the documentation. Using the source
>>>>> code is just a fallback, which the "Source Distribution" link probably
>>>>> takes care of. I am not aware of any complaints from Apache regarding
>>>>> this to Apache Cordova. The main usage type for users is front and
>>>>> center, the source code still is available if needed - so I wouldn't
>>>>> know why this should not be fine.
>>>>> 
>>>>> -J
>>>>> 
>>>>> [1] https://cordova.apache.org/#getstarted
>>>>> [2] https://cordova.apache.org/docs/en/latest/guide/cli/index.html
>>>>> 
>>>>> Am Di., 23. Apr. 2019 um 11:50 Uhr schrieb 申远 :
>>>>>> 
>>>>>> Hi, developers
>>>>>> 
>>>>>> After digging into ASF policy [1], it is clear that Weex missing a 
>>>>>> download
>>>>>> page which should links to Weex Apache Release. But is there any
>>>>>> requirement of the format for the download page?
>>>>>> 
>>>>>> For example, I found RocketMQ has a specified designed download page [2],
>>>>>> while Cordova [3] only has a text area called "source distribution" which
>>>>>> will be redirected to ASF page [4] .
>>>>>> 
>>>>>> Are both the download pages valid according to ASFs' policy? No offense,
>>>>>> but it occured to me that Cordova may probably choose a lazy way.
>>>>>> 
>>>>>> [1] https://www.apache.org/legal/release-policy.html
>>>>>> [2] https://rocketmq.apache.org/dowloading/releases/
>>>>>> [3] https://cordova.apache.org/
>>>>>> [4] https://www.apache.org/dyn/closer.cgi/cordova
>>>>>> 
>>>>>> Best Regards,
>>>>>> YorkShen
>>>>>> 
>>>>>> 申远
>>>> 
>> 

[DISCUSS] Weex Release

[York Shen]

Does anyone have any reason to delay a Weex release ? Any vital patches needs 
to be merged?

If not, I will start the release process tomorrow.

Actually, after reading ASF’s release policy [1] and Apache Cordova release 
process [2], I found the following aspect of Weex release process needs 
improvement:

Weex release process is not documented and it’s necessary to document it. 
Weex misses release script which would handle packing and publishing in several 
command line.
Weex needs a webpage to list all the release version, release date, release 
source, binary artifact, changeLog, and available secondary distribution 
channel like Bintray  or NPM.
Weex needs a place that is only visible to PPMCs to store private key for NPM 
and Bintray distribution channel.

I am volunteer to help with the missing part above and this release may take 
longer than before as we need to finish the missing part during the release 
process

BTW: Though Apache Cordova release process is pretty complicated, I think Weex 
can learn a lot from it as these projects are very similar in release artifact 
and distribution channel.

[1] http://www.apache.org/legal/release-policy.html 
<http://www.apache.org/legal/release-policy.html>
[2] 
https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md
 
<https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md>

Best Regards,
York Shen

申远

Re: [DISCUSS] Third party tools

[York Shen]

@Jan Thanks for your review

I have published the website, now tools/plugins that don’t belong to Apache 
Weex is marked clearly in the website.

Next step, I  will contact the author of those tools to rename their work, it 
may take a long while

Best Regards,
York Shen

申远

> 在 2019年4月23日，21:05，York Shen  写道：
> 
> Hi, there
> 
> I just mark tools listed on weex webpage as third party tools. As I am not 
> fluent enough at English, I’d like to know whether my words is clear an 
> unambiguous for Weex users, so that they would understand third part tools is 
> not part of Apache Weex.
> 
> https://github.com/apache/incubator-weex-site/pull/388 
> <https://github.com/apache/incubator-weex-site/pull/388>
> 
> I am willing to hear you advice, thanks.
> 
> Best Regards,
> York Shen
> 
> 申远
> 

[DISCUSS] Third party tools

[York Shen]

Hi, there

I just mark tools listed on weex webpage as third party tools. As I am not 
fluent enough at English, I’d like to know whether my words is clear an 
unambiguous for Weex users, so that they would understand third part tools is 
not part of Apache Weex.

https://github.com/apache/incubator-weex-site/pull/388 
<https://github.com/apache/incubator-weex-site/pull/388>

I am willing to hear you advice, thanks.

Best Regards,
York Shen

申远

Re: [DISCUSS] Weex Download Page

[York Shen]

Found it. Thanks.

Is there a webpage for release note or change log except for the 
RELEASENOTES.md in Cordova? Or is it necessary to have that page?

Does it comply the ASF’s policy if Weex continues to include npm/gradle 
distribution channel in Github page 
https://github.com/apache/incubator-weex#weex 
<https://github.com/apache/incubator-weex#weex> ?

Best Regards,
York Shen

申远

> 在 2019年4月23日，19:21，Jan Piotrowski  写道：
> 
> I would guess the .tgz includes the RELEASENOTES.md that is also in
> the source code repository.
> 
> As I wrote before, I am at least not aware of any complaints about how
> Cordova does things from Apache.
> 
> -J
> 
> Am Di., 23. Apr. 2019 um 13:12 Uhr schrieb York Shen :
>> 
>> Actually, I’d like to adopt Cordova’s distribution mechanism and 
>> corresponding webpages if it complies ASF policy.
>> 
>> As far as I understand, Weex is very similar to Cordova.  Main users of both 
>> are front-end engineers, who would prefer npm or gradle as distribution 
>> mechanism.
>> 
>> But is there ChangeLog/ReleaseNote pages for Cordova’s Source Distribution?
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远
>> 
>>> 在 2019年4月23日，18:00，Jan Piotrowski  写道：
>>> 
>>> What part of the release policy are you specifically referring to?
>>> 
>>> The main distribution mechanism for Apache Cordova is npm, which
>>> command is mentioned in the "Get started" [1] part of the homepage and
>>> installations instructions [2] of the documentation. Using the source
>>> code is just a fallback, which the "Source Distribution" link probably
>>> takes care of. I am not aware of any complaints from Apache regarding
>>> this to Apache Cordova. The main usage type for users is front and
>>> center, the source code still is available if needed - so I wouldn't
>>> know why this should not be fine.
>>> 
>>> -J
>>> 
>>> [1] https://cordova.apache.org/#getstarted
>>> [2] https://cordova.apache.org/docs/en/latest/guide/cli/index.html
>>> 
>>> Am Di., 23. Apr. 2019 um 11:50 Uhr schrieb 申远 :
>>>> 
>>>> Hi, developers
>>>> 
>>>> After digging into ASF policy [1], it is clear that Weex missing a download
>>>> page which should links to Weex Apache Release. But is there any
>>>> requirement of the format for the download page?
>>>> 
>>>> For example, I found RocketMQ has a specified designed download page [2],
>>>> while Cordova [3] only has a text area called "source distribution" which
>>>> will be redirected to ASF page [4] .
>>>> 
>>>> Are both the download pages valid according to ASFs' policy? No offense,
>>>> but it occured to me that Cordova may probably choose a lazy way.
>>>> 
>>>> [1] https://www.apache.org/legal/release-policy.html
>>>> [2] https://rocketmq.apache.org/dowloading/releases/
>>>> [3] https://cordova.apache.org/
>>>> [4] https://www.apache.org/dyn/closer.cgi/cordova
>>>> 
>>>> Best Regards,
>>>> YorkShen
>>>> 
>>>> 申远
>> 

Re: [DISCUSS] Weex Download Page

[York Shen]

Actually, I’d like to adopt Cordova’s distribution mechanism and corresponding 
webpages if it complies ASF policy.

As far as I understand, Weex is very similar to Cordova.  Main users of both 
are front-end engineers, who would prefer npm or gradle as distribution 
mechanism. 

But is there ChangeLog/ReleaseNote pages for Cordova’s Source Distribution?

Best Regards,
York Shen

申远

> 在 2019年4月23日，18:00，Jan Piotrowski  写道：
> 
> What part of the release policy are you specifically referring to?
> 
> The main distribution mechanism for Apache Cordova is npm, which
> command is mentioned in the "Get started" [1] part of the homepage and
> installations instructions [2] of the documentation. Using the source
> code is just a fallback, which the "Source Distribution" link probably
> takes care of. I am not aware of any complaints from Apache regarding
> this to Apache Cordova. The main usage type for users is front and
> center, the source code still is available if needed - so I wouldn't
> know why this should not be fine.
> 
> -J
> 
> [1] https://cordova.apache.org/#getstarted
> [2] https://cordova.apache.org/docs/en/latest/guide/cli/index.html
> 
> Am Di., 23. Apr. 2019 um 11:50 Uhr schrieb 申远 :
>> 
>> Hi, developers
>> 
>> After digging into ASF policy [1], it is clear that Weex missing a download
>> page which should links to Weex Apache Release. But is there any
>> requirement of the format for the download page?
>> 
>> For example, I found RocketMQ has a specified designed download page [2],
>> while Cordova [3] only has a text area called "source distribution" which
>> will be redirected to ASF page [4] .
>> 
>> Are both the download pages valid according to ASFs' policy? No offense,
>> but it occured to me that Cordova may probably choose a lazy way.
>> 
>> [1] https://www.apache.org/legal/release-policy.html
>> [2] https://rocketmq.apache.org/dowloading/releases/
>> [3] https://cordova.apache.org/
>> [4] https://www.apache.org/dyn/closer.cgi/cordova
>> 
>> Best Regards,
>> YorkShen
>> 
>> 申远

Re: Feature Proposal: Remove dependency between isJSFrameworkInit & data render

[York Shen]

Thanks for your advice.  I really like your idea and I am glad to see your 
improvement if it’s possible.

Don’t be hurry, you would have plenty designing and coding.

BTW: I have created a Github Project for you Schedule 
(https://github.com/apache/incubator-weex/projects/3 
<https://github.com/apache/incubator-weex/projects/3>).


Best Regards,
York Shen

申远

> 在 2019年4月18日，16:37，胥加成  写道：
> 
> Background: On Android, DATA_RENDER / DATA_RENDER_BINARY render mode don't 
> require JSFramework to be inited to run. Currently WXBridgeManager will check 
> framework init state for every bridge call such as createInstance or 
> refreshInstance.
> 
> Improvement: Create a flag: dataRenderRequireJSF in WXSDKInstance, when 
> checking isJSFrameworkInit in WXBridgeManager, check if render strategy is 
> (DATA_RENDER|| DATA_RENDER_BINARY) && dataRenderRequireJSF. If so,
>  check isJSFrameworkInit; If not, skip checking procedure. Using Dom module 
> to set up this flag. Default value is false;
> 
> Influence: Weex instance that renders in data render mode.
> 
> Tasks: 2 days,  modify WXSDKInstance.java WXBridgeManager.java && 
> WXDomModule.java
> 
> 

Re: Podling Report Reminder - April 2019

[York Shen]

Agreed with that. I will prepare a Github PR to remove the potential branding 
violations after release things are settled.

Best Regards,
York Shen

申远

> 在 2019年4月1日，14:26，Willem Jiang  写道：
> 
> We need to stop this kind of branding violation actions thing first by
> removing the tools link from website.
> We could let the tools team to host the download themself and they
> could add "powered by Weex" in their site, but they cannot use "Weex"
> in their product name.
> 
> Willem Jiang
> 
> Twitter: willemjiang
> Weibo: 姜宁willem
> 
> On Mon, Apr 1, 2019 at 11:24 AM 申远  wrote:
>> 
>> Thanks for your message.
>> 
>> 1.  We don't have the download link for the weex project.
>> 
>> 
>> I will handle this issue ASAP
>> 
>> 2. There are lots download links tools[1] in the weex website, which source
>>> code are not part of apache weex project.
>> 
>> As it is not clear that we should invite them as Apache weex, or mark them
>> Un-Apache Weex and notify them to rename their names, I think we need some
>> time to handle this problem.
>> 
>> 
>> Best Regards,
>> YorkShen
>> 
>> 申远
>> 
>> 
>> Willem Jiang  于2019年4月1日周一 上午11:13写道：
>> 
>>> Hi，
>>> 
>>> There are some issues on the weex apache website which need to be resolved
>>> ASAP.
>>> 1.  We don't have the download link for the weex project.
>>> 2. There are lots download links tools[1] in the weex website, which
>>> source code are not part of apache weex project.
>>> 
>>> [1]https://weex.apache.org/tools/
>>> 
>>> Willem Jiang
>>> 
>>> Twitter: willemjiang
>>> Weibo: 姜宁willem
>>> 
>>> On Tue, Mar 26, 2019 at 11:31 AM York Shen  wrote:
>>>> 
>>>> Hi, there
>>>> 
>>>> As we need to prepare the Weex Podling Reports before 3rd, April, and we
>>> have a national holiday in 5th, April in China, we’d better finish the
>>> report a little earlier.
>>>> 
>>>> The content of the report draft is below:
>>>> 
>>>> Weex is a framework for building Mobile cross-platform high performance
>>> UI.
>>>> 
>>>> Weex has been incubating since 2016-11-30.
>>>> 
>>>> Three most important unfinished issues to address before graduating:
>>>>  1. Third party plugins like weex-toolkit is not part of Apache Weex,
>>> and they may violate the trademark / copyright of ASF
>>>>  2. The release procedure for Weex is not documented clearly.
>>>>  3. More active committers and PPMC members should be invited into the
>>> community.
>>>> 
>>>> Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
>>>> aware of?
>>>> No
>>>> 
>>>> 
>>>> How has the community developed since the last report?
>>>> 1. There are two new committers for Weex, e.g. He Ling and Darin726.
>>>> 2. We have a new mentor : Jan Piotrowski
>>>> 3. The mailing list for weex community is getting better, as we have 28
>>> mailing threads in d...@weex.apache.org <mailto:d...@weex.apache.org>
>>>> 
>>>> 
>>>> How has the project developed since the last report?
>>>> 1. We launched new website for Weex.
>>>> 2. We merged and closed 144 Github PRs
>>>> 3. We had 212 Github issues created and 145 of them are solved.
>>>> 
>>>> 
>>>> How would you assess the podling's maturity?
>>>> Please feel free to add your own commentary.
>>>>  [ ] Initial setup
>>>>  [ ] Working towards first release
>>>>  [X] Community building
>>>>  [ ] Nearing graduation
>>>>  [ ] Other:
>>>> 
>>>> Date of last release:
>>>> 2018-12-10 (v0.20.0)
>>>> 
>>>> When were the last committers or PPMC members elected?
>>>> 2019-03-06
>>>> 
>>>> Have your mentors been helpful and responsive or are things falling
>>>> through the cracks? In the latter case, please list any open issues
>>>> that need to be addressed.
>>>> Yes, I think we have achieved lots of progress with their help in these
>>> month.
>>>> 
>>>> 
>>>> Best Regards,
>>>> York Shen
>>>> 
>>>> 申远
>>>> 
>>>>> 在 2019年3月26日，10:45，York Shen  写道：
>>>>> 
>>&g

Re: Podling Report Reminder - April 2019

[York Shen]

Thank, I have just updated the Incubator Wiki page for Weex report.

https://wiki.apache.org/incubator/April2019 
<https://wiki.apache.org/incubator/April2019>
York Shen

申远

> 在 2019年3月31日，17:58，Myrle Krantz  写道：
> 
> Hey York Shen,
> 
> I think your report is correct and comprehensive.  Good job!
> 
> Best,
> Myrle
> 
> On Tue, Mar 26, 2019 at 4:31 AM York Shen  <mailto:shenyua...@gmail.com>> wrote:
> 
>> Hi, there
>> 
>> As we need to prepare the Weex Podling Reports before 3rd, April, and we
>> have a national holiday in 5th, April in China, we’d better finish the
>> report a little earlier.
>> 
>> The content of the report draft is below:
>> 
>> Weex is a framework for building Mobile cross-platform high performance UI.
>> 
>> Weex has been incubating since 2016-11-30.
>> 
>> Three most important unfinished issues to address before graduating:
>>  1. Third party plugins like weex-toolkit is not part of Apache Weex, and
>> they may violate the trademark / copyright of ASF
>>  2. The release procedure for Weex is not documented clearly.
>>  3. More active committers and PPMC members should be invited into the
>> community.
>> 
>> Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
>> aware of?
>> No
>> 
>> 
>> How has the community developed since the last report?
>> 1. There are two new committers for Weex, e.g. He Ling and Darin726.
>> 2. We have a new mentor : Jan Piotrowski
>> 3. The mailing list for weex community is getting better, as we have 28
>> mailing threads in d...@weex.apache.org <mailto:d...@weex.apache.org> 
>> <mailto:d...@weex.apache.org <mailto:d...@weex.apache.org>>
>> 
>> 
>> How has the project developed since the last report?
>> 1. We launched new website for Weex.
>> 2. We merged and closed 144 Github PRs
>> 3. We had 212 Github issues created and 145 of them are solved.
>> 
>> 
>> How would you assess the podling's maturity?
>> Please feel free to add your own commentary.
>>  [ ] Initial setup
>>  [ ] Working towards first release
>>  [X] Community building
>>  [ ] Nearing graduation
>>  [ ] Other:
>> 
>> Date of last release:
>> 2018-12-10 (v0.20.0)
>> 
>> When were the last committers or PPMC members elected?
>> 2019-03-06
>> 
>> Have your mentors been helpful and responsive or are things falling
>> through the cracks? In the latter case, please list any open issues
>> that need to be addressed.
>> Yes, I think we have achieved lots of progress with their help in these
>> month.
>> 
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远
>> 
>>> 在 2019年3月26日，10:45，York Shen >> <mailto:shenyua...@gmail.com>> 写道：
>>> 
>>> As the deadline for Weex podling reports is 03, April, I am volunteer to
>> write the draft and will send it to the mailing list to see if there is
>> something need fixed.
>>> 
>>> Best Regards,
>>> York Shen
>>> 
>>> 申远
>>> 
>>>> 在 2019年3月24日，09:23，jmcl...@apache.org <mailto:jmcl...@apache.org> 
>>>> <mailto:jmcl...@apache.org <mailto:jmcl...@apache.org>> 写道：
>>>> 
>>>> Dear podling,
>>>> 
>>>> This email was sent by an automated system on behalf of the Apache
>>>> Incubator PMC. It is an initial reminder to give you plenty of time to
>>>> prepare your quarterly board report.
>>>> 
>>>> The board meeting is scheduled for Wed, 17 April 2019, 10:30 am PDT.
>>>> The report for your podling will form a part of the Incubator PMC
>>>> report. The Incubator PMC requires your report to be submitted 2 weeks
>>>> before the board meeting, to allow sufficient time for review and
>>>> submission (Wed, April 03).
>>>> 
>>>> Please submit your report with sufficient time to allow the Incubator
>>>> PMC, and subsequently board members to review and digest. Again, the
>>>> very latest you should submit your report is 2 weeks prior to the board
>>>> meeting.
>>>> 
>>>> Candidate names should not be made public before people are actually
>>>> elected, so please do not include the names of potential committers or
>>>> PPMC members in your report.
>>>> 
>>>> Thanks,
>>>> 
>>>> The Apache Incubator PMC
>>>> 
>>>> Submitting your Report
>>>> 
>>>

Re: [DISCUSS] Deprecation of weex components.

[York Shen]

You can mix image component and text component to simulate RichText, thought it 
is not a perfect solution.

The main reason I want to deprecate RichText is its poor design, which is full 
of hack and inconsistent with front-end tech.

We have a plan to rewrite the all the UI components according to W3C standards, 
but no schedule yet. I’d suggest you should deprecate RichText as the time 
goes, as it is no longer under maintenance except security related bugs.
Best Regards,
York Shen

申远

> 在 2019年3月27日，11:09，wcxwave  写道：
> 
> is Richtext  deprecation?
> If it's ture,  I want to know which component is the backup component for it?
> 
> ------
> 发件人：York Shen 
> 发送时间：2019年3月26日(星期二) 14:50
> 收件人：dev 
> 主　题：[DISCUSS] Deprecation of weex components.
> 
> Hi, there
> 
> I’d like to make some weex component as deprecation due to the following 
> reasons:
> These components are designed and implemented in a hack way, which makes them 
> difficult to maintain.
> As Weex is lack of active committers, we need to concentrate on more 
> important things, not just fix bug for the poor design.
> I think we have backup component for the deprecation ones, developer could 
> switch to the backup component.
> 
> The code for the deprecation components still remain for a long time, but 
> they are not under maintenance unless there is a security bug.
> 
> The deprecation components are listed below:
> Richtext <https://weex.apache.org/docs/components/richtext.html>
> recycle-list <https://weex.apache.org/docs/components/recycle-list.html>
> 
> I’d like to hear your advice before I mark them as deprecation in the 
> document.
> 
> Best Regards,
> York Shen
> 
> 申远
> 
> 

[DISCUSS] Deprecation of weex components.

[York Shen]

Hi, there

I’d like to make some weex component as deprecation due to the following 
reasons:
These components are designed and implemented in a hack way, which makes them 
difficult to maintain.
As Weex is lack of active committers, we need to concentrate on more important 
things, not just fix bug for the poor design.
I think we have backup component for the deprecation ones, developer could 
switch to the backup component.

The code for the deprecation components still remain for a long time, but they 
are not under maintenance unless there is a security bug.

The deprecation components are listed below:
Richtext <https://weex.apache.org/docs/components/richtext.html>
recycle-list <https://weex.apache.org/docs/components/recycle-list.html>

I’d like to hear your advice before I mark them as deprecation in the document.

Best Regards,
York Shen

申远

Re: Podling Report Reminder - April 2019

[York Shen]

Hi, there

As we need to prepare the Weex Podling Reports before 3rd, April, and we have a 
national holiday in 5th, April in China, we’d better finish the report a little 
earlier.

The content of the report draft is below:

Weex is a framework for building Mobile cross-platform high performance UI.

Weex has been incubating since 2016-11-30.

Three most important unfinished issues to address before graduating:
  1. Third party plugins like weex-toolkit is not part of Apache Weex, and they 
may violate the trademark / copyright of ASF
  2. The release procedure for Weex is not documented clearly.
  3. More active committers and PPMC members should be invited into the 
community.

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


How has the community developed since the last report?
1. There are two new committers for Weex, e.g. He Ling and Darin726.
2. We have a new mentor : Jan Piotrowski
3. The mailing list for weex community is getting better, as we have 28 mailing 
threads in d...@weex.apache.org <mailto:d...@weex.apache.org>


How has the project developed since the last report?
1. We launched new website for Weex.
2. We merged and closed 144 Github PRs
3. We had 212 Github issues created and 145 of them are solved.


How would you assess the podling's maturity?
Please feel free to add your own commentary.
  [ ] Initial setup
  [ ] Working towards first release
  [X] Community building
  [ ] Nearing graduation
  [ ] Other:

Date of last release:
 2018-12-10 (v0.20.0)

When were the last committers or PPMC members elected?
2019-03-06

Have your mentors been helpful and responsive or are things falling
through the cracks? In the latter case, please list any open issues
that need to be addressed.
Yes, I think we have achieved lots of progress with their help in these month.


Best Regards,
York Shen

申远

> 在 2019年3月26日，10:45，York Shen  写道：
> 
> As the deadline for Weex podling reports is 03, April, I am volunteer to 
> write the draft and will send it to the mailing list to see if there is 
> something need fixed.
> 
> Best Regards,
> York Shen
> 
> 申远
> 
>> 在 2019年3月24日，09:23，jmcl...@apache.org <mailto:jmcl...@apache.org> 写道：
>> 
>> Dear podling,
>> 
>> This email was sent by an automated system on behalf of the Apache
>> Incubator PMC. It is an initial reminder to give you plenty of time to
>> prepare your quarterly board report.
>> 
>> The board meeting is scheduled for Wed, 17 April 2019, 10:30 am PDT.
>> The report for your podling will form a part of the Incubator PMC
>> report. The Incubator PMC requires your report to be submitted 2 weeks
>> before the board meeting, to allow sufficient time for review and
>> submission (Wed, April 03).
>> 
>> Please submit your report with sufficient time to allow the Incubator
>> PMC, and subsequently board members to review and digest. Again, the
>> very latest you should submit your report is 2 weeks prior to the board
>> meeting.
>> 
>> Candidate names should not be made public before people are actually
>> elected, so please do not include the names of potential committers or
>> PPMC members in your report.
>> 
>> Thanks,
>> 
>> The Apache Incubator PMC
>> 
>> Submitting your Report
>> 
>> --
>> 
>> Your report should contain the following:
>> 
>> *   Your project name
>> *   A brief description of your project, which assumes no knowledge of
>>the project or necessarily of its field
>> *   A list of the three most important issues to address in the move
>>towards graduation.
>> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
>>aware of
>> *   How has the community developed since the last report
>> *   How has the project developed since the last report.
>> *   How does the podling rate their own maturity.
>> 
>> This should be appended to the Incubator Wiki page at:
>> 
>> https://wiki.apache.org/incubator/April2019 
>> <https://wiki.apache.org/incubator/April2019>
>> 
>> Note: This is manually populated. You may need to wait a little before
>> this page is created from a template.
>> 
>> Mentors
>> ---
>> 
>> Mentors should review reports for their project(s) and sign them off on
>> the Incubator wiki page. Signing off reports shows that you are
>> following the project - projects that are not signed may raise alarms
>> for the Incubator PMC.
>> 
>> Incubator PMC
>