Re: [DISCUSS] What should we handle editor.weex.io ?

[Jan Piotrowski]

The domain is not used to host any content, it just redirects to other URLs
that host the actual content: ASF servers for Apache Weex things, random
other server for random other content.

But do what you think best, I will disengage from this topic after this
message.

J

Am Mi., 4. Dez. 2019 um 07:55 Uhr schrieb 申远 :

> Based on the conservation with ASF, Brand Management, I don't think it will
> satiffy ASF's requirement if we keep it in our hands. From my
> understanding, we either take it down or give it to ASF.
>
> *As said by several people several times, Weex is a trademark of ASF and
> using weex in domain domain name also violate the legal right of ASF.*
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Jan Piotrowski  于2019年12月4日周三 上午4:29写道：
>
> > I already sent somthing similar in the other thread, so repeating:
> > If the editor code is not part of Apache Weex, it should live on its own
> > domain.
> > Keep the weex.io domain around so old links continue to work, but
> redirect
> > the main domain to the Apache Weex site and the editor subdomain to the
> new
> > external subdomain.
> >
> > I am happy to sponsor the cost for weex.io for the first year to whoever
> > takes over the domain: https://www.domcomp.com/tld/io
> >
> > ASF does not have to be involved here at all if this is just a user
> project
> > for Weex in my opinion, which clearly states this via e.g. "Editor for
> > Apache Weex". Agree Myrle?
> >
> > -J
> >
> > Am Di., 3. Dez. 2019 um 04:11 Uhr schrieb 申远 :
> >
> > > Hi, community
> > >
> > > I am going to move discussion [1] of using editor.weex.io to here,
> which
> > > will make our discussion more clear.
> > >
> > > Background: http://editor.weex.io is a useful tool for Weex
> developers,
> > > however Weex is a trademark of ASF, and using weex in domain name
> without
> > > approval of ASF is an violation of ASF's legal right [2], as long as
> the
> > > code, server, domain is not controlled by ASF.
> > >
> > > After discussion these days, here are options we have:
> > >
> > >- Use another domain unrelated to Weex, like *editor.dotwe.org
> > ><http://editor.dotwe.org>*
> > >- Donate the domain of *editor.weex.io <http://editor.weex.io>* to
> > ASF
> > >and have ASF paid the domain name every year [3]. (*Thanks for the
> > help
> > >of Myrle and Greg, this could not work without you.*)
> > >- Set up a DNS CNAME which connects *editor.weex.apache.org
> > ><http://editor.weex.apache.org> *and the server of editor.
> > >
> > > In either case, ASF won't pay for the fee of server, but this is not a
> > > problem as we are paying it for almost one year.
> > >
> > > If we choose opinion 1 or 3, we'd better still pay for the domain bill
> > each
> > > year in order to prevent it from misusing by any possible new owners.
> > >
> > > [1]
> > >
> > >
> >
> https://mail-archives.apache.org/mod_mbox/weex-dev/201911.mbox/%3CCAMAfNmEXTMVhN6n%3DPe2wGkJ1zodKa8%3DT_7%3DeQ%2BCPeYuFN-yWpQ%40mail.gmail.com%3E
> > > [2] http://www.apache.org/foundation/marks/domains.html
> > > [3] https://issues.apache.org/jira/browse/INFRA-19504
> > >
> > >
> > > Best Regards,
> > > YorkShen
> > >
> > > 申远
> > >
> >
>

Re: [DISCUSS] What should we handle editor.weex.io ?

[Jan Piotrowski]

I already sent somthing similar in the other thread, so repeating:
If the editor code is not part of Apache Weex, it should live on its own
domain.
Keep the weex.io domain around so old links continue to work, but redirect
the main domain to the Apache Weex site and the editor subdomain to the new
external subdomain.

I am happy to sponsor the cost for weex.io for the first year to whoever
takes over the domain: https://www.domcomp.com/tld/io

ASF does not have to be involved here at all if this is just a user project
for Weex in my opinion, which clearly states this via e.g. "Editor for
Apache Weex". Agree Myrle?

-J

Am Di., 3. Dez. 2019 um 04:11 Uhr schrieb 申远 :

> Hi, community
>
> I am going to move discussion [1] of using editor.weex.io to here, which
> will make our discussion more clear.
>
> Background: http://editor.weex.io is a useful tool for Weex developers,
> however Weex is a trademark of ASF, and using weex in domain name without
> approval of ASF is an violation of ASF's legal right [2], as long as the
> code, server, domain is not controlled by ASF.
>
> After discussion these days, here are options we have:
>
>- Use another domain unrelated to Weex, like *editor.dotwe.org
>*
>- Donate the domain of *editor.weex.io * to ASF
>and have ASF paid the domain name every year [3]. (*Thanks for the help
>of Myrle and Greg, this could not work without you.*)
>- Set up a DNS CNAME which connects *editor.weex.apache.org
> *and the server of editor.
>
> In either case, ASF won't pay for the fee of server, but this is not a
> problem as we are paying it for almost one year.
>
> If we choose opinion 1 or 3, we'd better still pay for the domain bill each
> year in order to prevent it from misusing by any possible new owners.
>
> [1]
>
> https://mail-archives.apache.org/mod_mbox/weex-dev/201911.mbox/%3CCAMAfNmEXTMVhN6n%3DPe2wGkJ1zodKa8%3DT_7%3DeQ%2BCPeYuFN-yWpQ%40mail.gmail.com%3E
> [2] http://www.apache.org/foundation/marks/domains.html
> [3] https://issues.apache.org/jira/browse/INFRA-19504
>
>
> Best Regards,
> YorkShen
>
> 申远
>

Re: [DISCUSS] Donate Weex UI to Apache Weex

[Jan Piotrowski]

Thanks - sounds good to me.

Am Do., 17. Okt. 2019 um 14:43 Uhr schrieb 申远 :
>
> I am personally in favour of the donation for following reasons:
>
>- It's a pity that there is no UI library for Weex
>- Weex UI is a confusion name and may violate the brand of ASF as ASF
>hold the trademark of Weex. Donate it to ASF will solve the problem.
>
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> 汤威  于2019年10月17日周四 下午8:34写道：
>
> > Hi community
> >
> >
> >
> >
> > my name is TangWei, Is the developer of the Weex UI. I would like to use
> > this email to introduce Weex UI and donation to Apache.
> >
> >
> >
> >
> > Weex Ui is a rich interaction, lightweight, high performance UI library
> > based on Weex.
> >
> >
> >
> >
> > It originated in the beginning of Weex in Alibaba,  Step by step follow to
> > precipitate common components and functions. Then a lot of developers in
> > our company began to use it, and improved a lot of development efficiency.
> >
> >
> >
> >
> > In order to let more external developers use it, we opened source on
> > September 30, 2017, which is the current  github.com/alibaba/weex-ui .
> > After more than two years of development and maintenance of 46 releases, it
> > has been used by most of the developers using weex, and gained 4.6k star
> > and 882 fork at the same time.
> >
> >
> >
> >
> > In order to better promote its development and involve more developers, we
> > are ready to follow the footsteps of weex and donate it to Apache.
> >
> >
> >
> >
> > At present, the license of the weex UI code has been completely modified,
> > the   is being sorted out,  the relevant
> > agreements are being prepared for signing, it is expected to be submitted
> > to Apache on 2019.10.31 as a whole.
> >
> >
> >
> >
> > The above is the basic situation of weex UI at present. Thank you for
> > reading.
> >
> >
> >
> >
> > Best Regards,
> >
> >  TangWei
> >
> >  汤威
> >
> >
> >
> >
> >
> >
> > 汤威
> > t...@qq.com

Re: [DISCUSS] Graduate Weex from Apache Incubator

[Jan Piotrowski]

Nice progress.

Let me know when website and all public communication and content is
on par for what you think should be fine for graduation, and I will
spend the time to go through all of it and see if I can find any
confusing parts.

-J

Am Fr., 27. Sept. 2019 um 13:40 Uhr schrieb shihan zheng
:
>
> Very beautiful progress, thanks to York Shen’s efforts ！
>
> During this time, we spent a lot of time learning "the Apache Way" to
> improve the Apache Weex(Incubating)  community.
>
> There may still be some problems at present, hope everyone can help find
> problems together and provide valuable advice.
>
> Looking forward to Apache Weex(Incubating)  graduation！
>
> Best Regards,
>
> shihan zheng
>
>
> 饮源
>
> York Shen  于2019年9月27日周五 下午3:32写道：
>
> > 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/ 
> > Migrated conversation/decision to d...@weex.apache.org  > 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
> >
> > 申远
>
>
>
> --
>
> Best Regards!
> -
> Shihan Zheng (Weex project team member )

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

[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 
> 
> [2] 
> https://developer.apple.com/app-store/review/guidelines/#third-party-software 
> 
>
> Best Regards,
> York Shen
>
> 申远
>

Re: [DISCUSS] Package name in Java code

[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 :
>
> 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

[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 :
>
> 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: [Vote] [IP Clearance] Accepting donation of Weex-loader

[Jan Piotrowski]

+1

Am Mi., 11. Sept. 2019 um 10:37 Uhr schrieb 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 
> 
> [2] 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
>  
> 
> [4] 
> https://www.timeanddate.com/countdown/generic?iso=20190914T09=1440=Countdown+=cursive
>  
> 
>
> Best Regards,
> York Shen
>
> 申远

Re: [DISCUSS] Maven account to publish connivence binary

[Jan Piotrowski]

Releases to npm, maven, bintray etc. are what is called "convenience"
in ASF land, similar to the "Convenience Binaries" that are produced.
The official release is the _source code_ that will he hosted on an
_ASF server_, everything else is just to make life easier (which is
super important of course).

That being said, Cordova might not be the best example here because it
is pretty ancient - very possible that there is a more correct way to
do this now which might include an account provided by ASF Infra
(similar to the App Store or Google Play account we talked about
before). So it might be worth to shoot INFRA a question via a ticket.

-J

Am Fr., 6. Sept. 2019 um 08:48 Uhr schrieb 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 
> 
>
> 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 
> > 
> > [2] https://svn.apache.org/repos/private/pmc/incubator/weex/JCenter_key 
> > 
> >
> >
> > Best Regards,
> > York Shen
> >
> > 申远
> >
>

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

[Jan Piotrowski]

+1!

Am Mi., 4. Sept. 2019 um 09:15 Uhr schrieb 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 
> 
> [2] 
> 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
>  
> 
> [4] 
> https://www.timeanddate.com/countdown/generic?iso=20190907T00=283=Countdown+Timer=cursive
>  
> 
>
> Best Regards,
> York Shen
>
> 申远
>

Re: Books about Weex

[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 
> [2] https://cwiki.apache.org/confluence/display/WEEX/CheckList 
> 
>
> Best Regards,
> York Shen
>
> 申远

Re: [ANNOUNCEMENT] Sauce Lab Enable

[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
> >>
> >> 申远
>

Re: [ANNOUNCEMENT] Sauce Lab Enable

[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 
> 
> [2] https://weex.apache.org/thanks.html 
>
> Best Regards,
> York Shen
>
> 申远

Re: [DISCUSS] Prepare IP Clearance

[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 :
>
> 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

[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 :
>
> 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

[Jan Piotrowski]

Sounds good - SauceLabs are good people.

J

Am Di., 20. Aug. 2019 um 09:54 Uhr schrieb 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.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 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 | Sauce blog
>
>
>
>

Re: Some Suggestions about incubator-weex

[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: [ANNOUNCEMENT] Separate weex_sdk and weex_playground for good

[Jan Piotrowski]

Thanks a lot.

The only remaining thing here confusing might now be the duplication
of "Playground" in the navigation as
https://weex.apache.org/tools/dotwe.html also uses that word.

J

Am Mi., 7. Aug. 2019 um 06:35 Uhr schrieb 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
> >>>>
> >>>> 申远
> >>>>
> >
>

Re: [Discuss] Recent works about CI

[Jan Piotrowski]

As far as I am aware ASF rules only apply to code included in the
releases - what you do to build or test your code is not really
relevant to these requirements.

But obviously you should follow the licences of the code itself, which
seems fine in this case.
Of course if you want to keep that in the codebase longer term, the
repo should probably become part of the apache org. But for small
things like that it might be fine to keep it in your personal org, and
maybe just publish it to npm with a different name.

J

Am Mi., 7. Aug. 2019 um 09:56 Uhr schrieb 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 

Re: [DISCUSS] How to handle Github Issue

[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

[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: [GitHub] [incubator-weex-playground] katherine95s opened a new pull request #2: [Android]add flag to configure weex_sdk source

[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?

[Jan Piotrowski]

Awesome :)

OT: Someone should ask INFRA to enable issues on the playground repo.

J

Am Do., 11. Juli 2019 um 10:36 Uhr schrieb 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 fo

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

[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: [DISCUSS][LICENSE] Include downloaded dependencies in LICENSE file for Playground?

[Jan Piotrowski]

>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: [DISCUSS] Add Github MileStone When PR

[Jan Piotrowski]

Just to bring up an idea of a still lightweight, still Github based,
but already a bit more formal planning process:

Import all issues and PRs into a GitHub project boards, then decide
which ones are just "support/questions" (column) vs. work items.
Former are irrelevant here, latter go into a "backlog" (column). The
backlog then is prioritized, sorted, filtered to get to the "next"
(column) items (probably in some kind of meeting or discussion process
- this can be quite hard in a distributed work situation so maybe this
can be delegated to a few trusted parties of the community). The end
result then can be the basis for formal milestones that are used by
developers to select their work.

Of course this can get a _lot_ more fancy and process based - but with
cost of additional effort.

J


Am Do., 4. Juli 2019 um 11:32 Uhr schrieb Jan Piotrowski :
>
> Thanks for bringing this up Renmin Wang.
>
> It is important to note here, that Github Milestones are just a tool
> to document and organize an organizational process. If the Apache Weex
> contributors are not actually planning in milestones, it doesn't make
> too much sense to use Github Milestones.
>
> So an earlier question how to fix the "transparency of Weex
> development is not enough" problem, is if a "Let's plan our work in
> milestones based on issues and PRs" is actually what you want.
>
> How is work currently planned?
> Are there meetings or communications where the "next issues" are
> defined and discussed?
> Is there always only one "next release" or are there multiple ones?
> Who decides what is to be worked on next?
> How is decided what goes in a release and what does not? (e.g. just
> based on what PRs there are and merged?)
> Is the planning really release focused, or maybe topic focused and
> releases are just a side effect?
> What is the planning horizon? Next release (whenever that happens),
> month, quarter, year?
>
> J
>
> Am Do., 4. Juli 2019 um 11:20 Uhr schrieb 王仁敏 :
> >
> > Hi there，
> >
> > I am very very very sorry to send so many emails with the error format 
> > text. The below is the email main content:
> >
> >
> >
> >
> > As the transparency of Weex development is not enough now, even the 
> > developers in the community are not sure what features are added after an 
> > iteration, and when this iteration is released.
> >
> > But Github Milestone can solve this problem.
> >
> > Here are the benefits of milestones copied from reference link 1:
> > -  A user-provided description of the milestone, which can include 
> > information like a project overview, relevantteams, and projected due 
> > dates
> > -  The milestone's due date
> > - The milestone's completion percentage
> > - The number of open and closed issues and pull requests associated with 
> > the milestone
> > - A list of the open and closed issues and pull requests associated with 
> > the milestone
> >
> >
> > with the Milestone, developers in the community will know the progress of 
> > the project easily.
> > so I propose that all PRs must be associated with Github Milestone.
> >
> >
> > BTW, The milestone check can be added to Travis CI. If the milestone is not 
> > included in the PR, the Travis ci will build failed.
> >
> >
> >
> > Reference Link:
> >
> > [1]Github Milestone:https://help.github.com/en/articles/about-milestones
> >
> >
> >
> > Best Wishes,
> > Renmin Wang
> >
> >
> > | |
> > 王仁敏
> > |
> > |
> > hnht...@163.com
> > |
> > 签名由网易邮箱大师定制
> >
> >
> > On 07/4/2019 16:51，王仁敏 wrote：
> > forget to add the reference link，sorry.
> >
> >
> >
> >
> > Reference Links:
> > 1. https://help.github.com/en/articles/about-milestones
> >
> >
> >
> >
> > | |
> > 王仁敏
> > |
> > |
> > hnht...@163.com
> > |
> > 签名由网易邮箱大师定制
> >
> >
> > On 07/4/2019 16:48，王仁敏 wrote：
> > Hi there，
> >
> > As the transparency of Weex development is not enough now,even the 
> > developers in the community are not sure what features are added after an 
> > iteration, and when this iteration is released.
> >
> > But Github Milestone can solve this problem.
> >
> > Here are the benefits of milestones copyed from reference link 1:
> >
> > A user-provided description of the milestone, which can include information 
> > like a project overview, relevant teams, and projected due dates
> >
> > The milesto

Re: [DISCUSS] Add Github MileStone When PR

[Jan Piotrowski]

Thanks for bringing this up Renmin Wang.

It is important to note here, that Github Milestones are just a tool
to document and organize an organizational process. If the Apache Weex
contributors are not actually planning in milestones, it doesn't make
too much sense to use Github Milestones.

So an earlier question how to fix the "transparency of Weex
development is not enough" problem, is if a "Let's plan our work in
milestones based on issues and PRs" is actually what you want.

How is work currently planned?
Are there meetings or communications where the "next issues" are
defined and discussed?
Is there always only one "next release" or are there multiple ones?
Who decides what is to be worked on next?
How is decided what goes in a release and what does not? (e.g. just
based on what PRs there are and merged?)
Is the planning really release focused, or maybe topic focused and
releases are just a side effect?
What is the planning horizon? Next release (whenever that happens),
month, quarter, year?

J

Am Do., 4. Juli 2019 um 11:20 Uhr schrieb 王仁敏 :
>
> Hi there，
>
> I am very very very sorry to send so many emails with the error format text. 
> The below is the email main content:
>
>
>
>
> As the transparency of Weex development is not enough now, even the 
> developers in the community are not sure what features are added after an 
> iteration, and when this iteration is released.
>
> But Github Milestone can solve this problem.
>
> Here are the benefits of milestones copied from reference link 1:
> -  A user-provided description of the milestone, which can include 
> information like a project overview, relevantteams, and projected due 
> dates
> -  The milestone's due date
> - The milestone's completion percentage
> - The number of open and closed issues and pull requests associated with the 
> milestone
> - A list of the open and closed issues and pull requests associated with the 
> milestone
>
>
> with the Milestone, developers in the community will know the progress of the 
> project easily.
> so I propose that all PRs must be associated with Github Milestone.
>
>
> BTW, The milestone check can be added to Travis CI. If the milestone is not 
> included in the PR, the Travis ci will build failed.
>
>
>
> Reference Link:
>
> [1]Github Milestone:https://help.github.com/en/articles/about-milestones
>
>
>
> Best Wishes,
> Renmin Wang
>
>
> | |
> 王仁敏
> |
> |
> hnht...@163.com
> |
> 签名由网易邮箱大师定制
>
>
> On 07/4/2019 16:51，王仁敏 wrote：
> forget to add the reference link，sorry.
>
>
>
>
> Reference Links:
> 1. https://help.github.com/en/articles/about-milestones
>
>
>
>
> | |
> 王仁敏
> |
> |
> hnht...@163.com
> |
> 签名由网易邮箱大师定制
>
>
> On 07/4/2019 16:48，王仁敏 wrote：
> Hi there，
>
> As the transparency of Weex development is not enough now,even the developers 
> in the community are not sure what features are added after an iteration, and 
> when this iteration is released.
>
> But Github Milestone can solve this problem.
>
> Here are the benefits of milestones copyed from reference link 1:
>
> A user-provided description of the milestone, which can include information 
> like a project overview, relevant teams, and projected due dates
>
> The milestone's due date
>
> The milestone's completion percentage
>
> The number of open and closed issues and pull requests associated with the 
> milestone
>
> A list of the open and closed issues and pull requests associated with the 
> milestone
>
> I think with the Milestone, developers in the community will know the 
> progress of the project easily.
>
> so I proposal that that all PRs must be associated with Github Milestone.
>
> BTW, The milestone check can be added to Travis CI. If milestone is not 
> included in the PR, the travis ci will build failed.
>
> Best Wishes,
>
> Renmin Wang
>
>
>
> | |
> 王仁敏
> |
> |
> hnht...@163.com
> |
> 签名由网易邮箱大师定制
>

Re: [DISCUSS] Separate Weex into two repos

[Jan Piotrowski]

Awesome!

I volunteer to test the app(s) when the move has been made to ensure
everything works and will also gladly review any README etc. Just
reply when the move is in a state that should be looked at.

J

Am Do., 4. Juli 2019 um 10:08 Uhr schrieb 王仁敏 :
>
> and I would like to do the separating of ios.
>
>
> | |
> 王仁敏
> |
> |
> 邮箱：hnht...@163.com
> |
>
> 签名由 网易邮箱大师 定制
>
> On 07/04/2019 15:35, 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] Package name in Java code

[Jan Piotrowski]

Sounds pretty neat and was pretty much what I was thinking of.

That users have to add the new weex_compatible package for this to
work I count as a positive, as it makes sure they are aware of the
package name change and can decide if to use the compatibility package
or rename their package usage once on their side.

I think Weex will definitely from it in the long term, so go for it!

J

Am Mo., 1. Juli 2019 um 09:34 Uhr schrieb 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 impo

Re: [DISCUSS] Package name in Java code

[Jan Piotrowski]

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 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 
> 
> [2] 
> https://github.com/apache/incubator-weex/blob/master/android/sdk/src/main/java/com/taobao/weex/WXSDKEngine.java
>  
> 
>
> Best Regards,
> York Shen
>
> 申远
>

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

[Jan Piotrowski]

> Cordova does too, so Jan may be able to answer.

Apache Cordova fortunately only _uses_ it via APIs that are offered by the
OS, and does not _include_ it (or any of its code) - so this problem never
came up.

-J

Am Di., 11. Juni 2019 um 18:32 Uhr schrieb Myrle Krantz :

> On Tue, Jun 11, 2019 at 2:20 PM 申远  wrote:
>
> > >
> > > But you say "a mixture of LGPL and BSD license at runtime".  What do
> you
> > > mean by that?  Is there a way to reduce that to just BSD?  Or are you
> > using
> > > WebCore or JavaScriptCore?
> >
> >
> > According to the document, "WebKit is open source software with portions
> > licensed under the LGPL and BSD licenses available here." [1] and Weex
> just
> > has a dynamic link to the shared library of WebKit. IMO, the license of
> > Webkit is really a mess, I really don't know whether Weex will invoke
> LGPL
> > part of Webkit at runtime, or there is a call chain will will lead to
> LGPL
> > code eventually, like Weex.apiA-> Webkit.BSD.apiA -> Webkit.BSD.apiB ->
> > Webkit.LGPL.apiC
> >
>
> I suggest asking on the gene...@incubator.apache.org list.  With luck,
> you'll find someone there who's looked at this more deeply.   (Actually
> Flex seems to use some part from webkit, so Justin may be able to answer
> this question.  Cordova does too, so Jan may be able to answer.)  And if
> not, they may send you on to the le...@apache.org list.  My guess is that,
> if you're only using the parts that you can access using the BSD-licensed
> headers, that you can consider it to be licensed under BSD.  I hope this is
> true.  But I don't actually know.
>
> But what I do know is that all of the header files of a certain directory
> > [2] in Webkit are under BSD License. And after some major change, Weex
> > could just import the header file I mentioned at compiling stage, though
> at
> > runtime Weex has to dynamic link to the shared library of Webkit as
> before.
> > As for glibc(sorry for my misspelling, it's not glic, it's glibc), which
> is
> > also under LGPL license, any serious program could invoke the glibc by
> > simply a *malloc* function in a *.c file. I don't see any difference
> there
> > between Weex using Webkit and any other C program using glibc.
> >
>
> The point is that, if there are alternatives (which there are for the c
> runtime), then the dependency is optional for your user.  Optional
> dependencies are treated differently than required dependencies for ASF
> release policy.  But again, I suggest asking on general@incubator.a.o.
>
> Best Regards,
> Myrle
>

Re: Weex Trademark(CopyRight) issue

[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
> [2] https://weex.apache.org/guide/use-vue-in-weex.html
>
> Best Regards,
> YorkShen
>
> 申远

Re: [ANNOUNCEMENT] Weex 0.24.0 Released

[Jan Piotrowski]

Awesome that INFRA already has the iOS account in place!

Just for the record: We can of course do all the publishing manually
for iOS without fastlane, should be pretty trivial.

For Android, you are correct that fastlane does not support many
Chinese Android app stores - yet. I would be happy to work with you on
creating plugins for fastlane to automate the publishing on those
markets, if possible. I am pretty sure, many are already covered with
plugins published on GitHub.

But you are correct, a quicker and more efficient way would probably
be to allow users to download the APK from the website. In the long
term we can still work on getting it on all the stores again.

-J


Am Mi., 29. Mai 2019 um 04:55 Uhr schrieb 申远 :
>
> Sorry for misspelling, let me correct it.
>
> The sentence
>
> > One of the reason that Weex used to publish Android Playground in the name
> > of Taobao (China) Software is that Taobao already developer accounts almost
> > for each of the twenty Android App market.
>
>
> should change to
>
> One of the reason that Weex used to publish Android Playground in the name
> of Taobao (China) Software is that Taobao already registered accounts for
> most of the twenty Android App market.
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> 申远  于2019年5月29日周三 上午10:49写道：
>
> > Before I was going to bring this to general@incubator, I got a response
> > from INFRA[1], according to which there is an Apple Developer Account under
> > ASF.
> >
> > The iOS parts seems to be solved as long as we separate weex_sdk and Weex
> > playground then import fastline [2] in Weex Playground.
> >
> > But I am not sure about the Android part, though I am an Android
> > developer. Let me explain situation here. There are at least twenty Android
> > App Market including Google Play in China. Android developers have to
> > register developer account for each market in order to cover as many users
> > as possible. One of the reason that Weex used to publish Android Playground
> > in the name of Taobao (China) Software is that Taobao already developer
> > accounts almost for each of the twenty Android App market. With the help of
> > developer accounts and other infrastructure of Taobao (China) Software,
> > things were pretty easy as we just needed to click a button to publish
> > Android App.
> >
> > I don't know the detail of fastlane, but according to the doc[3], it just
> > supports Google Play, which is inaccessible for most Chinese developers.
> > And I am not a big fan of registering over 20 android market account, it
> > seems like that we need to remove Android Weex Playground from all market
> > and host it somewhere in our official website. But when users installs
> > Android Weex Playground from our website, the system may warn users that
> > "weex playground is developer by third party and may contain vulnerable".
> > Anyway, not a perfect solution, but acceptable for me.
> >
> > [1] https://issues.apache.org/jira/browse/INFRA-18494
> > [2] https://github.com/fastlane/fastlane
> > [3]
> > https://docs.fastlane.tools/getting-started/android/setup/#collect-your-google-credentials
> >
> > Best Regards,
> > YorkShen
> >
> > 申远
> >
> >
> > Jan Piotrowski  于2019年5月28日周二 下午4:07写道：
> >
> >> Why does this require a enterprise development account? If the app it
> >> to be placed in the App Stores, a normal personal account should be
> >> enough.
> >>
> >> > As for Android, it's more complicated in China as we need to apply tens
> >> of Chinese Android distribution channel plus Google Play.
> >>
> >> I am also a contributor to https://github.com/fastlane/fastlane, a
> >> tool that can be used to automate the build and deployment of iOS and
> >> Android apps. If playground is split to its own repository, it would
> >> be an interesting project to automate that process. I would volunteer
> >> to set that up (or at least get it started, until I hit the barrier
> >> that I don't know Chinese - then I would gladly collaborate with a
> >> native Chinese speaker).
> >>
> >> I agree with the rest YorkShen wrote, so lets see if ASF has any
> >> suggestion regarding the App Store accounts.
> >>
> >> -J
> >>
> >> Am Di., 28. Mai 2019 um 09:01 Uhr schrieb 申远 :
> >> >
> >> > The publishing of Weex Playground is hold as soon as we learned it may
> >> > violate ASF policy here.
> >> >
> >> > Maybe we should find a way to let the PMC member to provide the
> >>

Re: [ANNOUNCEMENT] Weex 0.24.0 Released

[Jan Piotrowski]

Why does this require a enterprise development account? If the app it
to be placed in the App Stores, a normal personal account should be
enough.

> As for Android, it's more complicated in China as we need to apply tens of 
> Chinese Android distribution channel plus Google Play.

I am also a contributor to https://github.com/fastlane/fastlane, a
tool that can be used to automate the build and deployment of iOS and
Android apps. If playground is split to its own repository, it would
be an interesting project to automate that process. I would volunteer
to set that up (or at least get it started, until I hit the barrier
that I don't know Chinese - then I would gladly collaborate with a
native Chinese speaker).

I agree with the rest YorkShen wrote, so lets see if ASF has any
suggestion regarding the App Store accounts.

-J

Am Di., 28. Mai 2019 um 09:01 Uhr schrieb 申远 :
>
> The publishing of Weex Playground is hold as soon as we learned it may
> violate ASF policy here.
>
> Maybe we should find a way to let the PMC member to provide the convenience
> > binary.
>
>
> The tricky thing here is that we need an Apple/Google enterprise
> development account under a company's or individual's name. And the Apple
> account would cost us 299 USD per year. As for Android, it's more
> complicated in China as we need to apply tens of Chinese Android
> distribution channel plus Google Play.
>
> Maybe we should remove Weex Playground from Apple Store and Google Play,
> and host Weex Playground(Binary) only in our website? I think we'd better
> not do any release nor separate repos of Weex Playground until we get
> response from general@incubator
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Willem Jiang  于2019年5月28日周二 上午11:31写道：
>
> > On Mon, May 27, 2019 at 8:04 PM 申远  wrote:
> > >
> > > I agree with that.
> > >
> > > Moving playground to another separate repository(also under ASF?) may
> > take
> > > couple of days, I don't think there will be big technical issue.
> > >
> > > But this doesn't solve the issue that Weex Playground is under Apple
> > > Developer Enterprise Program Account of Taobao (China) Software. And
> > there
> > > is a similar situation for Weex Android Playground.
> > >
> >
> > So, it looks like Taobao publish the binary release of Weex Playground.
> > I'm not sure if it is OK for Apache.
> > Maybe we should find a way to let the PMC member to provide the
> > convenience binary.
> >
> >
> > > I could and would mark thing "Stuff that some third party provides for
> > > Apache Weex", but for "Stuff for Weex the Apache Weex team also
> > provides",
> > > this is really confusing concept.
> > >
> > > Best Regards,
> > > YorkShen
> > >
> > > 申远
> > >
> > >
> > > Jan Piotrowski  于2019年5月27日周一 下午4:32写道：
> > >
> > > > Thanks for the clarification. I understand why the Playground app is
> > > > valuable and awesome for developers.
> > > >
> > > > Would it be an option to move the playground and connected code (e.g.
> > > > for http://dotwe.org/vue) to a separate repository? Or does the
> > > > `playground` code benefit so much from being in the same repository?
> > > >
> > > > For me right now this is one of these cases, where it is totally
> > > > unclear what actually is part of "Apache Weex" (vs. "Stuff for Weex
> > > > the Apache Weex team also provides" vs. "Stuff that some third party
> > > > provides for Apache Weex").
> > > >
> > > > -J
> > > >
> > > >
> > > > Am Mo., 27. Mai 2019 um 09:01 Uhr schrieb 申远 :
> > > > >
> > > > > Let me rephrase myself.
> > > > >
> > > > >- The code of Android or iOS playground app is never part of
> > Apache
> > > > >Release. The release scripts always delete code of the Playground
> > App
> > > > >before publishing release candidate.
> > > > >- The code of playground and weex_sdk is loosely coupled and the
> > > > >playground is mainly for demo purpose, like Google Sample [1]. It
> > > > should
> > > > >*never* go into real product environment.
> > > > >- But the playground does provide developers the convenience of
> > > > >verifying the API or feature of Weex. They just need write code
> > > > snippet
> > > > >online [2], and scan the QR c

Re: [ANNOUNCEMENT] Weex 0.24.0 Released

[Jan Piotrowski]

> Moving playground to another separate repository(also under ASF?) may take
> couple of days, I don't think there will be big technical issue.

Great. Everything that is part of Weex should be a ASF repository, so
this should definitely be one as well
(https://gitbox.apache.org/setup/newrepo.html can be used to create
them self-service).

> But this doesn't solve the issue that Weex Playground is under Apple
> Developer Enterprise Program Account of Taobao (China) Software. And there
> is a similar situation for Weex Android Playground.

Indeed, for that my initial assessment stands. It might be worth to
ask the incubating list as well, maybe they encountered something like
that in the past.

> I could and would mark thing "Stuff that some third party provides for
> Apache Weex", but for "Stuff for Weex the Apache Weex team also provides",
> this is really confusing concept.

Ha yes, especially with the words I chose :D
A better way to represent this might be:

1. Apache Weex (the actual SDK)
2. Apache Weex tooling and helpers (e.g. playground app)
3. Third party things for Apache Weex (e.g. VS Code Extension)

1 and 2 are both ASF things and live in separate repositories under
the Apache GitHub org, and 3 are external and only linked for
convenience with a disclaimer (like I saw you added).

J

Am Mo., 27. Mai 2019 um 14:04 Uhr schrieb 申远 :
>
> I agree with that.
>
> Moving playground to another separate repository(also under ASF?) may take
> couple of days, I don't think there will be big technical issue.
>
> But this doesn't solve the issue that Weex Playground is under Apple
> Developer Enterprise Program Account of Taobao (China) Software. And there
> is a similar situation for Weex Android Playground.
>
> I could and would mark thing "Stuff that some third party provides for
> Apache Weex", but for "Stuff for Weex the Apache Weex team also provides",
> this is really confusing concept.
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Jan Piotrowski  于2019年5月27日周一 下午4:32写道：
>
> > Thanks for the clarification. I understand why the Playground app is
> > valuable and awesome for developers.
> >
> > Would it be an option to move the playground and connected code (e.g.
> > for http://dotwe.org/vue) to a separate repository? Or does the
> > `playground` code benefit so much from being in the same repository?
> >
> > For me right now this is one of these cases, where it is totally
> > unclear what actually is part of "Apache Weex" (vs. "Stuff for Weex
> > the Apache Weex team also provides" vs. "Stuff that some third party
> > provides for Apache Weex").
> >
> > -J
> >
> >
> > Am Mo., 27. Mai 2019 um 09:01 Uhr schrieb 申远 :
> > >
> > > Let me rephrase myself.
> > >
> > >- The code of Android or iOS playground app is never part of Apache
> > >Release. The release scripts always delete code of the Playground App
> > >before publishing release candidate.
> > >- The code of playground and weex_sdk is loosely coupled and the
> > >playground is mainly for demo purpose, like Google Sample [1]. It
> > should
> > >*never* go into real product environment.
> > >- But the playground does provide developers the convenience of
> > >verifying the API or feature of Weex. They just need write code
> > snippet
> > >online [2], and scan the QR code, then they get what they write.
> > >
> > > [1] https://github.com/googlesamples
> > > [2] http://dotwe.org/vue
> > >
> > > Best Regards,
> > > YorkShen
> > >
> > > 申远
> > >
> > >
> > > Jan Piotrowski  于2019年5月24日周五 下午8:14写道：
> > >
> > > > A compiled Android or iOS native app is actually an interesting case.
> > > > Is this actually part of the release, or is just the source code of
> > > > the app?
> > > >
> > > > How tightly coupled are weex and the playground app anyway? Right now
> > > > the playground app seems to live in a `playground` subfolder of `ios`
> > > > and `android`. Would it maybe make sense to split that off in its own
> > > > repo and have its own releases? I don't expect actual users of weex to
> > > > really need the `playground` code, or do they?
> > > >
> > > > But yes, it would definitely be better to have this app not be
> > > > published via a different commercial entity - no matter if you define
> > > > the binary app to be part of the release or not. If Apache itself has
> > > > a A

Re: [ANNOUNCEMENT] Weex 0.24.0 Released

[Jan Piotrowski]

Thanks for the clarification. I understand why the Playground app is
valuable and awesome for developers.

Would it be an option to move the playground and connected code (e.g.
for http://dotwe.org/vue) to a separate repository? Or does the
`playground` code benefit so much from being in the same repository?

For me right now this is one of these cases, where it is totally
unclear what actually is part of "Apache Weex" (vs. "Stuff for Weex
the Apache Weex team also provides" vs. "Stuff that some third party
provides for Apache Weex").

-J


Am Mo., 27. Mai 2019 um 09:01 Uhr schrieb 申远 :
>
> Let me rephrase myself.
>
>- The code of Android or iOS playground app is never part of Apache
>Release. The release scripts always delete code of the Playground App
>before publishing release candidate.
>- The code of playground and weex_sdk is loosely coupled and the
>playground is mainly for demo purpose, like Google Sample [1]. It should
>*never* go into real product environment.
>- But the playground does provide developers the convenience of
>verifying the API or feature of Weex. They just need write code snippet
>online [2], and scan the QR code, then they get what they write.
>
> [1] https://github.com/googlesamples
> [2] http://dotwe.org/vue
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Jan Piotrowski  于2019年5月24日周五 下午8:14写道：
>
> > A compiled Android or iOS native app is actually an interesting case.
> > Is this actually part of the release, or is just the source code of
> > the app?
> >
> > How tightly coupled are weex and the playground app anyway? Right now
> > the playground app seems to live in a `playground` subfolder of `ios`
> > and `android`. Would it maybe make sense to split that off in its own
> > repo and have its own releases? I don't expect actual users of weex to
> > really need the `playground` code, or do they?
> >
> > But yes, it would definitely be better to have this app not be
> > published via a different commercial entity - no matter if you define
> > the binary app to be part of the release or not. If Apache itself has
> > a App Store Connect account I don't know though - best start by asking
> > INFRA via a ticket. (Maybe it could also be published via one of the
> > committers personal account as a fallback)
> >
> > -J
> >
> >
> > -J
> >
> > Am Fr., 24. Mai 2019 um 12:20 Uhr schrieb 申远 :
> > >
> > > Dear Community
> > >
> > > Weex 0.24.0 is released now, one can download source or convenience
> > binary
> > > through the link in our website [1].
> > >
> > > And there is a remaining issue for the release. One may notice that there
> > > exists a showcase app called Weex Playground[2], which is compiled
> > > from incubator-weex, but it is not a part os Apache Release as the
> > release
> > > script deleted the files of Playground when publishing release candidate.
> > > As one need a enterprise certificates to publish an iOS App, we used to
> > > borrow the certificates from Taobao(China), LTD.
> > >
> > > Based on the fact above, I have following concerns:
> > >
> > >1. I'd like to know whether it is ok to exclude some file during
> > apache
> > >release, like the code for Weex playground
> > >2. I am not sure whether it is suitable that I continue borrow the
> > >enterprise certificates from Taobao(China), LTD and publish the iOS
> > App. If
> > >it is not acceptable, is there any iOS enterprise certificates under
> > ASF?
> > >
> > > [1] https://weex.apache.org/download/download.html#latest-release
> > > [2] https://itunes.apple.com/cn/app/weex-playground/id1130862662
> > >
> > > Best Regards,
> > > YorkShen
> > >
> > > 申远
> >

Re: [ANNOUNCEMENT] Weex 0.24.0 Released

[Jan Piotrowski]

A compiled Android or iOS native app is actually an interesting case.
Is this actually part of the release, or is just the source code of
the app?

How tightly coupled are weex and the playground app anyway? Right now
the playground app seems to live in a `playground` subfolder of `ios`
and `android`. Would it maybe make sense to split that off in its own
repo and have its own releases? I don't expect actual users of weex to
really need the `playground` code, or do they?

But yes, it would definitely be better to have this app not be
published via a different commercial entity - no matter if you define
the binary app to be part of the release or not. If Apache itself has
a App Store Connect account I don't know though - best start by asking
INFRA via a ticket. (Maybe it could also be published via one of the
committers personal account as a fallback)

-J


-J

Am Fr., 24. Mai 2019 um 12:20 Uhr schrieb 申远 :
>
> Dear Community
>
> Weex 0.24.0 is released now, one can download source or convenience binary
> through the link in our website [1].
>
> And there is a remaining issue for the release. One may notice that there
> exists a showcase app called Weex Playground[2], which is compiled
> from incubator-weex, but it is not a part os Apache Release as the release
> script deleted the files of Playground when publishing release candidate.
> As one need a enterprise certificates to publish an iOS App, we used to
> borrow the certificates from Taobao(China), LTD.
>
> Based on the fact above, I have following concerns:
>
>1. I'd like to know whether it is ok to exclude some file during apache
>release, like the code for Weex playground
>2. I am not sure whether it is suitable that I continue borrow the
>enterprise certificates from Taobao(China), LTD and publish the iOS App. If
>it is not acceptable, is there any iOS enterprise certificates under ASF?
>
> [1] https://weex.apache.org/download/download.html#latest-release
> [2] https://itunes.apple.com/cn/app/weex-playground/id1130862662
>
> Best Regards,
> YorkShen
>
> 申远

Re: [DISCUSS] Weex Trademark issue

[Jan Piotrowski]

I was under the impression that nothing happened yet after we talked
about this the last time. Or was there some cleanup that I missed?
Because then I would re-review the situation and point out the
remaining problems again.

-J

Am Mo., 13. Mai 2019 um 09:39 Uhr schrieb 申远 :
>
> Hi, community
>
> I know this discussion happened before, but I'd like to mention it again.
>
> After review the discussion of trademark issue in Apache dubbo[1], I think
> Weex should pay more attention trademark, too. As both Weex and Dubbo have
> external ecosystem, which means there are repos[2] on github related to
> Weex but not under ASF.
>
> Owners of this repo can choose donate this repo to Weex, renaming repos to
> xxx-for-apache-weex or deleting such repos. Apache Dubbo really shows us a
> good example.
>
> [1]
> https://lists.apache.org/thread.html/dd36fa6c4ae4c1962be6c6a1235507eaa8c5c3ae009281e7cfdb2522@%3Cgeneral.incubator.apache.org%3E
> [2] https://github.com/weex-plugins
> [3] https://github.com/weexteam
> [4]
> https://github.com/apache/incubator-dubbo/wiki/Apache-Dubbo-external-ecosystem-status
>
> Best Regards,
> YorkShen
>
> 申远

Re: [DISCUSS] Weex Release

[Jan Piotrowski]

> Weex needs a place that is only visible to PPMCs to store private key for NPM 
> and Bintray distribution channel.

Apache Cordova is using a private SVN hosted by Apache for that and
similar use cases.

> 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.

The Apache Cordova release process is also >5 years old, pretty over
complex and currently not very well documented. You should _not_ take
this as a positive example at all. You should probably just forget
that it exists (besides the individual things being done, those
probably still make sense for Weex).

-J

Am Mi., 24. Apr. 2019 um 09:44 Uhr schrieb 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 
> 
> [2] 
> https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md
>  
> 
>
> Best Regards,
> York Shen
>
> 申远
>

Re: [DISCUSS] Weex Download Page

[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
> >>>>
> >>>> 申远
> >>
>

Re: [DISCUSS] Weex Download Page

[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

[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] Deprecation of weex components.

[Jan Piotrowski]

Anecdotally deprecation is often a problem as many users misunderstand
it as "we removed this" or "this is broken", instead of what it
actually means. So they will be unhappy, although you didn't change
anything than to put a label "this will not be developed further in
its current form" on it.

-J

Am Mi., 27. März 2019 um 07:34 Uhr schrieb 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 
> > recycle-list 
> >
> > I’d like to hear your advice before I mark them as deprecation in the 
> > document.
> >
> > Best Regards,
> > York Shen
> >
> > 申远
> >
> >
>

Re: Question about the website of weex

[Jan Piotrowski]

In my opinion there is no dilemma, just a bit of work ahead of us.
We will start by collecting all the possibly problematic things, then
find simple and effective solutions to each and every one.
And _if_ we can't solve some of them, we might have to think about
"legal" or other solutions. But I don't expect that to be needed.

-J

Am Mi., 6. März 2019 um 18:00 Uhr schrieb York Shen :
>
> I understand the brand issues and the general topics. But let me explain my 
> concerns first:
>
> There are definitely some third party extensions violating the trademark of 
> Apache Weex. But in my opinion, I think weex’s( difficult to pronounce 路‍♀️) 
> priority is getting more developers into the community (mailing list instead 
> of github) and encourage them from users to contributor or committers. 
> Trademark issue is time consuming and may be not that urgent to Weex 
> community at this point (just personal opinion).
> I’d like to treat thirty-party extensions as good sign because the Weex is 
> useful so that someone would develop tools for Weex. I want to show the kind 
> and friendly part of the Weex community, not threaten developers with law. 
> Maybe the boundary between kindness and weakness is not so clear, such 
> kindness may be treated as weakness. But I really don’t appreciate the idea 
> of threatening enthusiastic developers with law.
>
> Though, I understand that from ASF’s point, such violation may be 
> unacceptable and need corrected.  So, I am really in a dilemma.
>
> > 在 2019年3月6日，23:11，Jan Piotrowski  写道：
> >
> > I assume Myrle's response was not focused on this one extension, but
> > on the general topic we discussed over multiple emails.
> >
> > As soon as I have the necessary rights I will start to collect all the
> > "problematic" things I can find in the GitHub project board and we can
> > then start to discuss possible solutions or workarounds for those.
> >
> > The website is now fully on Git, so we should be able to iterate here
> > quickly and efficiently. And I am sure we will find great solutions
> > with all third parties as well.
> >
> > -J
> >
> > Am Mi., 6. März 2019 um 16:03 Uhr schrieb 申远 :
> >>
> >> I am totally aware of the situation, but what we met here is that someone
> >> published a VSCode extension named weex-plugin/tool/helper. I cannot
> >> contact all of the author of such extension to ask them rename their code
> >> or invite all of them into Weex repo under Apache. Either of these choices
> >> is impractical.
> >>
> >> But these tools are useful, I can't pretend that I don't know there is a
> >> such tool and ignore all the things that happened in the world beyond
> >> apache community.
> >>
> >> What I can think of is that listing the useful tools in weex website and
> >> make it clear it is not part of apache weex.
> >>
> >> Best Regards,
> >> YorkShen
> >>
> >> 申远
> >>
> >>
> >> Myrle Krantz  于2019年3月6日周三 下午7:44写道：
> >>
> >>> Apache Weex dev team:
> >>>
> >>> Using the Weex name to denote something that isn't weex is a problem.
> >>> Calling a team a "weex team" if they aren't the Apache Weex committers and
> >>> PMC is confusing to end users.  Apache doesn't allow project brands to be
> >>> diluted like this.
> >>>
> >>> Registering a website with the weex name which offers code that isn't from
> >>> the weex project is a problem.  If these tools are important to the 
> >>> project
> >>> to the point that it is important that they share the weex brand, then 
> >>> they
> >>> *do* belong on the Apache weex website.  They also need to be licensed
> >>> under ALv2, and released by the Weex PMC, and the source needs to be 
> >>> hosted
> >>> on the apache github account.
> >>>
> >>> The Weex PMC needs to have control of all the weex code or else you won't
> >>> be able to graduate.  And generating more code in these off-list projects
> >>> pushes your project *away* from graduation, not towards it.
> >>>
> >>> Best Regards,
> >>> Myrle
> >>>
> >>> On Mon, Mar 4, 2019 at 1:51 PM Jan Piotrowski 
> >>> wrote:
> >>>
> >>>> Of course there can still be a "VS Code extension" entry under (e.g.)
> >>>> "Third party tools".
> >>>>
> >>>> And the extension actually has a perfectly fine 

Re: Question about the website of weex

[Jan Piotrowski]

I assume Myrle's response was not focused on this one extension, but
on the general topic we discussed over multiple emails.

As soon as I have the necessary rights I will start to collect all the
"problematic" things I can find in the GitHub project board and we can
then start to discuss possible solutions or workarounds for those.

The website is now fully on Git, so we should be able to iterate here
quickly and efficiently. And I am sure we will find great solutions
with all third parties as well.

-J

Am Mi., 6. März 2019 um 16:03 Uhr schrieb 申远 :
>
> I am totally aware of the situation, but what we met here is that someone
> published a VSCode extension named weex-plugin/tool/helper. I cannot
> contact all of the author of such extension to ask them rename their code
> or invite all of them into Weex repo under Apache. Either of these choices
> is impractical.
>
> But these tools are useful, I can't pretend that I don't know there is a
> such tool and ignore all the things that happened in the world beyond
> apache community.
>
> What I can think of is that listing the useful tools in weex website and
> make it clear it is not part of apache weex.
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Myrle Krantz  于2019年3月6日周三 下午7:44写道：
>
> > Apache Weex dev team:
> >
> > Using the Weex name to denote something that isn't weex is a problem.
> > Calling a team a "weex team" if they aren't the Apache Weex committers and
> > PMC is confusing to end users.  Apache doesn't allow project brands to be
> > diluted like this.
> >
> > Registering a website with the weex name which offers code that isn't from
> > the weex project is a problem.  If these tools are important to the project
> > to the point that it is important that they share the weex brand, then they
> > *do* belong on the Apache weex website.  They also need to be licensed
> > under ALv2, and released by the Weex PMC, and the source needs to be hosted
> > on the apache github account.
> >
> > The Weex PMC needs to have control of all the weex code or else you won't
> > be able to graduate.  And generating more code in these off-list projects
> > pushes your project *away* from graduation, not towards it.
> >
> > Best Regards,
> > Myrle
> >
> > On Mon, Mar 4, 2019 at 1:51 PM Jan Piotrowski 
> > wrote:
> >
> > > Of course there can still be a "VS Code extension" entry under (e.g.)
> > > "Third party tools".
> > >
> > > And the extension actually has a perfectly fine website, so no need to
> > > rehost the documentation and images etc:
> > > Both
> > https://marketplace.visualstudio.com/items?itemName=weex.vscode-weex
> > > and https://github.com/weex-cli/vscode-weex (although the Github org
> > > name is problematic) work just fine.
> > >
> > > Of course feel free to drop the PR link when it is up. Will be happy
> > > to provide feedback.
> > >
> > > -J
> > >
> > > Am Mo., 4. März 2019 um 13:42 Uhr schrieb 申远 :
> > > >
> > > > Agreed.
> > > >
> > > > We should set the boundary clearly about what is Apache Weex and what
> > is
> > > > not and mention that on the webpage.
> > > >
> > > > But given current situation, it is hard to move them to a seperate
> > domain
> > > > totally. For example, vscode extension
> > > > <https://weex.apache.org/tools/extension.html#features> are just third
> > > > party VSCode extension, which I found by searching on VScode. It is
> > > > unlikely to ask them have their own website and remove them directly
> > > from .
> > > > apache.org is not also a good idea.
> > > >
> > > > What I can think of is marked them as third party plugin .apache.org
> > > > clearly and remain them in the page as they are now.
> > > >
> > > > When I finished my work, maybe you could review my PR?
> > > >
> > > >
> > > > Best Regards,
> > > > YorkShen
> > > >
> > > > 申远
> > > >
> > > >
> > > > Jan Piotrowski  于2019年3月1日周五 下午6:10写道：
> > > >
> > > > > Ok, then it's pretty simple:
> > > > >
> > > > > Those tools should have their own website on another domain (one that
> > > > > does not redirect to the .apache.org site by default - maybe
> > > > > subdomains for weex-community.io or something if someone wants to
> > > > &

Re: New Committer: He Ling

[Jan Piotrowski]

Welcome He Ling!

Am Mi., 6. März 2019 um 03:41 Uhr schrieb 申远 :
>
> The Podling Project Management Committee (PPMC) for Apache Weex has invited
> He Ling to become a committer and we are pleased to announce that he has
> accepted.
>
> He Ling is a great iOS Developer and works with weex project for a while.
> He focuses on improving the stability, utility of Weex and the following is
> part of his commit:
>
>- https://github.com/apache/incubator-weex/pull/1938, Fix
>backgroundColor issues
>- https://github.com/apache/incubator-weex/pull/2124, Fix text color
>issues
>- https://github.com/apache/incubator-weex/pull/2024, Fix crash
>
> Being a committer enables easier contribution to the project since there is
> no need to go via the Github Pull Request process. This should enable
> better productivity. Being a PMC member enables assistance with the
> management and to guide the direction of the project.
>
> Best Regards,
> YorkShen
>
> 申远

Re: [DISCUSS] can we use weex.io as the short domain name for the apache project

[Jan Piotrowski]

Great that we are on the same page here.

Could someone from the PMC please request a project board on Github
being created at https://github.com/apache/incubator-weex/projects so
I can create a space to track all these TODO items regarding
incubation, compliance etc? We don't want to miss anything there.
Thanks.

-J

Am Di., 5. März 2019 um 07:33 Uhr schrieb Dan :
>
> > Technically speaking, I or other Weex PPMC are not the owner of weex.io,
> I can not ask EMAS team uses another domain as weex.io is not under my or
> other PPMC's control.
>
> Yes, this domain name is currently managed in my hands. On the construction
> of this website, the EMAS team gave us a lot of construction assistance, so
> we provided a subdomain `emas.weex.io` to give the EMAS team to deploy
> their official website.
>
>
> > Actually, I think
> https://cn.aliyun.com/solution/emas?spm=a2c7j.-zh-community-biz-emas.0.0.5daac8eecHbyWI
> already is an external website for EMAS - so this can probably just be
> listed under "Tools using Apache Weex" on the new Apache Weex website.
>
> That's ok, I will deploy a page to show this content, all
> the  not-really-Apache-Weex things will put on this page, but for the time
> being, the EMAS page may be mounted on `emas.weex.io` until a more suitable
> domain name is found, and I will also push them to learn Apache Cordova and
> Adobe Phonegap to re-edit the page content, I think it will take a certain
> amount of time, and I can’t do it right away.
>
> Thanks,
> Dan
>
> 申远  于2019年3月4日周一 下午8:49写道：
>
> > Technically speaking, I or other Weex PPMC are not the owner of weex.io,
> > I can not ask EMAS team uses another domain as weex.io is not under my or
> > other PPMC's control.
> >
> > Actually, I think Dan may have the admin privilege of weex.io.
> >
> > What do you think, Dan?
> >
> > Best Regards,
> > YorkShen
> >
> > 申远
> >
> >
> > Jan Piotrowski  于2019年3月1日周五 下午6:19写道：
> >
> >> Actually, I think
> >>
> >> https://cn.aliyun.com/solution/emas?spm=a2c7j.-zh-community-biz-emas.0.0.5daac8eecHbyWI
> >> already is an external website for EMAS - so this can probably just be
> >> listed under "Tools using Apache Weex" on the new Apache Weex website.
> >>
> >> Am Fr., 1. März 2019 um 11:17 Uhr schrieb Jan Piotrowski <
> >> piotrow...@gmail.com>:
> >> >
> >> > I understood that, and that is exactly why EMAS can not be under one
> >> > of the official domains being used for Apache Weex. As weex.io is a
> >> > plain redirect, it will be considered as "part of Apache Weex" by the
> >> > users. If EMAS uses the same domain, users will make the same
> >> > assumption here - which is not true.
> >> >
> >> > The content from http://emas.weex.io/zh/community/biz-emas.html should
> >> > be extracted into its own website that does not share anything with
> >> > the Apache Weex project website. Something non Apache-Weex can't just
> >> > copy the whole website and add a few pages, as this will greatly
> >> > confuse users. (If EMAS was historically available under that domain,
> >> > of course all the old links can be redirected to its new domains so
> >> > they keep working.)
> >> >
> >> > EMAS can (and should! it's awesome something like that exists) of
> >> > course be listed on the official Apache Weex website as "enterprise
> >> > mobile development solution based on Apache Weex" or similar.
> >> >
> >> > Take Apache Cordova and Adobe Phonegap as an example. Apache Cordova
> >> > is https://cordova.apache.org/. Phonegap is https://phonegap.com/ and
> >> > builds on Apache Cordova. It mentions Cordova on its website and links
> >> > to Apache Cordova.
> >> >
> >> > But as with all other not-really-Apache-Weex things, the
> >> > differentiation has to be made 100% clear. Ther should be no confusion
> >> > for users what is _Apache_ Weex and what is tools for or other
> >> > software built on Weex.
> >> >
> >> > -J
> >> >
> >> > Am Fr., 1. März 2019 um 03:16 Uhr schrieb 申远 :
> >> > >
> >> > > Technically speaking, EMAS is an enterprise mobile develop solution
> >> based
> >> > > on weex, and I think the target users of EMAS are Chinese. Actually,
> >> there
> >> > > is an entry[1] for EMAS in Chinese document. Besides that, there is no
> >> &

Re: Question about the website of weex

[Jan Piotrowski]

Of course there can still be a "VS Code extension" entry under (e.g.)
"Third party tools".

And the extension actually has a perfectly fine website, so no need to
rehost the documentation and images etc:
Both https://marketplace.visualstudio.com/items?itemName=weex.vscode-weex
and https://github.com/weex-cli/vscode-weex (although the Github org
name is problematic) work just fine.

Of course feel free to drop the PR link when it is up. Will be happy
to provide feedback.

-J

Am Mo., 4. März 2019 um 13:42 Uhr schrieb 申远 :
>
> Agreed.
>
> We should set the boundary clearly about what is Apache Weex and what is
> not and mention that on the webpage.
>
> But given current situation, it is hard to move them to a seperate domain
> totally. For example, vscode extension
> <https://weex.apache.org/tools/extension.html#features> are just third
> party VSCode extension, which I found by searching on VScode. It is
> unlikely to ask them have their own website and remove them directly from .
> apache.org is not also a good idea.
>
> What I can think of is marked them as third party plugin .apache.org
> clearly and remain them in the page as they are now.
>
> When I finished my work, maybe you could review my PR?
>
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Jan Piotrowski  于2019年3月1日周五 下午6:10写道：
>
> > Ok, then it's pretty simple:
> >
> > Those tools should have their own website on another domain (one that
> > does not redirect to the .apache.org site by default - maybe
> > subdomains for weex-community.io or something if someone wants to
> > sponsor that?) and the official weex page just links out to them,
> > mentioning that those are community supported and owned tools (e.g. by
> > having a "Community Tools" headline in the navigation or by combining
> > them all on a "Community Tools" page instead of having own navigation
> > item for each tool).
> >
> > To users it has to be absolutely clear and obvious what is official
> > Apache Weex, and what is not.
> >
> > Am Fr., 1. März 2019 um 03:22 Uhr schrieb 申远 :
> > >
> > > >
> > > > Sorry, did I miss part of the thread here? What "development tools and
> > > > others" are you talking about?
> > >
> > >
> > > Under the right side of the page [1], there is a list for weex tool.
> > Except
> > > for Playground App, others are developed by third party developers. As
> > such
> > > tools are useful and we cannot move all of them to Apache repos, we just
> > > list it in the page.
> > >
> > > [1] https://weex.apache.org/tools/playground.html
> > >
> > > Best Regards,
> > > YorkShen
> > >
> > > 申远
> > >
> > >
> > > Jan Piotrowski  于2019年2月28日周四 下午10:13写道：
> > >
> > > > > Such tools are useful and attractive for users of Weex, and we need a
> > > > place
> > > > to list such tools in Weex eco system, ...
> > > >
> > > > Sorry, did I miss part of the thread here? What "development tools and
> > > > others" are you talking about?
> > > >
> > > > > As weex users are Android/iOS/JavaScript developers, they often
> > choose
> > > > Gradle/Cocoapods/NPM to install the artifacts instead of source. But I
> > > > could list the artifacts and Gradle/Cocoapods/NPM link together in a
> > > > webpage later.
> > > >
> > > > This is of course no problem at all. But the original voting and
> > > > release process follows the required Apache way, when it is finished
> > > > the binaries or releases can of course be distributed in any way
> > > > useful to the users. See here for an example of the Cordova release
> > > > process:
> > > >
> > https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md#otherwise-publish-real-release-to-dist--npm
> > > > (pretty overcomplicated because of historical reasons, but you get the
> > > > idea)
> > > >
> > > > Am Do., 28. Feb. 2019 um 04:58 Uhr schrieb Willem Jiang
> > > > :
> > > > >
> > > > > When you send the announcement of the code release, you need to list
> > > > > the released artifacts just like this[1].
> > > > > Here is  dubbo release guidelines that you can take a look.
> > > > >
> > > > > [1]http://servicecomb.apache.org/release/
> > > > > [2]
> > http://dub

Re: [DISCUSS] can we use weex.io as the short domain name for the apache project

[Jan Piotrowski]

Actually, I think
https://cn.aliyun.com/solution/emas?spm=a2c7j.-zh-community-biz-emas.0.0.5daac8eecHbyWI
already is an external website for EMAS - so this can probably just be
listed under "Tools using Apache Weex" on the new Apache Weex website.

Am Fr., 1. März 2019 um 11:17 Uhr schrieb Jan Piotrowski :
>
> I understood that, and that is exactly why EMAS can not be under one
> of the official domains being used for Apache Weex. As weex.io is a
> plain redirect, it will be considered as "part of Apache Weex" by the
> users. If EMAS uses the same domain, users will make the same
> assumption here - which is not true.
>
> The content from http://emas.weex.io/zh/community/biz-emas.html should
> be extracted into its own website that does not share anything with
> the Apache Weex project website. Something non Apache-Weex can't just
> copy the whole website and add a few pages, as this will greatly
> confuse users. (If EMAS was historically available under that domain,
> of course all the old links can be redirected to its new domains so
> they keep working.)
>
> EMAS can (and should! it's awesome something like that exists) of
> course be listed on the official Apache Weex website as "enterprise
> mobile development solution based on Apache Weex" or similar.
>
> Take Apache Cordova and Adobe Phonegap as an example. Apache Cordova
> is https://cordova.apache.org/. Phonegap is https://phonegap.com/ and
> builds on Apache Cordova. It mentions Cordova on its website and links
> to Apache Cordova.
>
> But as with all other not-really-Apache-Weex things, the
> differentiation has to be made 100% clear. Ther should be no confusion
> for users what is _Apache_ Weex and what is tools for or other
> software built on Weex.
>
> -J
>
> Am Fr., 1. März 2019 um 03:16 Uhr schrieb 申远 :
> >
> > Technically speaking, EMAS is an enterprise mobile develop solution based
> > on weex, and I think the target users of EMAS are Chinese. Actually, there
> > is an entry[1] for EMAS in Chinese document. Besides that, there is no
> > difference between http://weex.apache.org and http://emas.weex.io/ .
> >
> > And Weex projcet always declared that http://weex.apache.org or
> > http://weex.io are the official homepage.
> >
> > [1] http://emas.weex.io/zh/community/biz-emas.html
> >
> > Best Regards,
> > YorkShen
> >
> > 申远
> >
> >
> > Jan Piotrowski  于2019年2月28日周四 下午10:08写道：
> >
> > > I don't understand.
> > >
> > > A "commercial eco system for weex" should not just mirror the complete
> > > site, even (and especially!) if they add their own things.
> > > Right now I have no idea what this really is when I go there, so this
> > > should definitely be cleaned up.
> > >
> > > -J
> > >
> > > Am Do., 28. Feb. 2019 um 04:24 Uhr schrieb 申远 :
> > > >
> > > > EMAS is a commercial eco-system for weex, so this url[1] should not be
> > > > redirected to https:/weex.apache.org
> > > >
> > > > I have talked to guys of EMAS, they are using the source code of
> > > > incubator-weex-site [2] and some third-party content to build the
> > > website,
> > > > while weex only use incubator-weex-site [2]
> > > >
> > > > [1] http://emas.weex.io/
> > > > [2] https://github.com/apache/incubator-weex-site/
> > > >
> > > > Best Regards,
> > > > YorkShen
> > > >
> > > > 申远
> > > >
> > > >
> > > > Jan Piotrowski  于2019年2月28日周四 上午5:37写道：
> > > >
> > > > > Nice!
> > > > >
> > > > > Just found http://emas.weex.io/ which is not redirecting yet.
> > > > >
> > > > > J
> > > > >
> > > > > Am Mi., 27. Feb. 2019 um 07:00 Uhr schrieb 申远 :
> > > > > >
> > > > > > http://weex-project.io is also redirected to http://weex.apache.org
> > > > > >
> > > > > > Except for the following issue, I think we have done the relaunch
> > > > > procedure
> > > > > > of website:
> > > > > >
> > > > > >
> > > > > >- Google Search Console Account
> > > > > >- Redirect http://weex.apache.org to https://weex.apache.org
> > > > > >
> > > > > >
> > > > > > Best Regards,
> > > > > > YorkShen
> > > > > >
> > > > > > 申远
&

Re: [DISCUSS] can we use weex.io as the short domain name for the apache project

[Jan Piotrowski]

I understood that, and that is exactly why EMAS can not be under one
of the official domains being used for Apache Weex. As weex.io is a
plain redirect, it will be considered as "part of Apache Weex" by the
users. If EMAS uses the same domain, users will make the same
assumption here - which is not true.

The content from http://emas.weex.io/zh/community/biz-emas.html should
be extracted into its own website that does not share anything with
the Apache Weex project website. Something non Apache-Weex can't just
copy the whole website and add a few pages, as this will greatly
confuse users. (If EMAS was historically available under that domain,
of course all the old links can be redirected to its new domains so
they keep working.)

EMAS can (and should! it's awesome something like that exists) of
course be listed on the official Apache Weex website as "enterprise
mobile development solution based on Apache Weex" or similar.

Take Apache Cordova and Adobe Phonegap as an example. Apache Cordova
is https://cordova.apache.org/. Phonegap is https://phonegap.com/ and
builds on Apache Cordova. It mentions Cordova on its website and links
to Apache Cordova.

But as with all other not-really-Apache-Weex things, the
differentiation has to be made 100% clear. Ther should be no confusion
for users what is _Apache_ Weex and what is tools for or other
software built on Weex.

-J

Am Fr., 1. März 2019 um 03:16 Uhr schrieb 申远 :
>
> Technically speaking, EMAS is an enterprise mobile develop solution based
> on weex, and I think the target users of EMAS are Chinese. Actually, there
> is an entry[1] for EMAS in Chinese document. Besides that, there is no
> difference between http://weex.apache.org and http://emas.weex.io/ .
>
> And Weex projcet always declared that http://weex.apache.org or
> http://weex.io are the official homepage.
>
> [1] http://emas.weex.io/zh/community/biz-emas.html
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Jan Piotrowski  于2019年2月28日周四 下午10:08写道：
>
> > I don't understand.
> >
> > A "commercial eco system for weex" should not just mirror the complete
> > site, even (and especially!) if they add their own things.
> > Right now I have no idea what this really is when I go there, so this
> > should definitely be cleaned up.
> >
> > -J
> >
> > Am Do., 28. Feb. 2019 um 04:24 Uhr schrieb 申远 :
> > >
> > > EMAS is a commercial eco-system for weex, so this url[1] should not be
> > > redirected to https:/weex.apache.org
> > >
> > > I have talked to guys of EMAS, they are using the source code of
> > > incubator-weex-site [2] and some third-party content to build the
> > website,
> > > while weex only use incubator-weex-site [2]
> > >
> > > [1] http://emas.weex.io/
> > > [2] https://github.com/apache/incubator-weex-site/
> > >
> > > Best Regards,
> > > YorkShen
> > >
> > > 申远
> > >
> > >
> > > Jan Piotrowski  于2019年2月28日周四 上午5:37写道：
> > >
> > > > Nice!
> > > >
> > > > Just found http://emas.weex.io/ which is not redirecting yet.
> > > >
> > > > J
> > > >
> > > > Am Mi., 27. Feb. 2019 um 07:00 Uhr schrieb 申远 :
> > > > >
> > > > > http://weex-project.io is also redirected to http://weex.apache.org
> > > > >
> > > > > Except for the following issue, I think we have done the relaunch
> > > > procedure
> > > > > of website:
> > > > >
> > > > >
> > > > >- Google Search Console Account
> > > > >- Redirect http://weex.apache.org to https://weex.apache.org
> > > > >
> > > > >
> > > > > Best Regards,
> > > > > YorkShen
> > > > >
> > > > > 申远
> > > > >
> > > > >
> > > > > Dan  于2019年2月27日周三 上午11:53写道：
> > > > >
> > > > > > > The server should just be a Apache webserver (of course!) that
> > can
> > > > > > accept .htaccess files to redirect non-http requests.
> > > > > > Super complicated example from Cordova:
> > > > > >
> > > > > >
> > > >
> > https://github.com/apache/cordova-docs/blob/3c41a7d14192eb26c883c65fc63be303f811474e/www/.htaccess#L118-L130
> > > > > > There should be much easier ways to achieve this.
> > > > > >
> > > > > > I will take a look and try to make weex.apache.org work with
> > non-http.
> > > > > >
> > 

Re: Question about the website of weex

[Jan Piotrowski]

Ok, then it's pretty simple:

Those tools should have their own website on another domain (one that
does not redirect to the .apache.org site by default - maybe
subdomains for weex-community.io or something if someone wants to
sponsor that?) and the official weex page just links out to them,
mentioning that those are community supported and owned tools (e.g. by
having a "Community Tools" headline in the navigation or by combining
them all on a "Community Tools" page instead of having own navigation
item for each tool).

To users it has to be absolutely clear and obvious what is official
Apache Weex, and what is not.

Am Fr., 1. März 2019 um 03:22 Uhr schrieb 申远 :
>
> >
> > Sorry, did I miss part of the thread here? What "development tools and
> > others" are you talking about?
>
>
> Under the right side of the page [1], there is a list for weex tool. Except
> for Playground App, others are developed by third party developers. As such
> tools are useful and we cannot move all of them to Apache repos, we just
> list it in the page.
>
> [1] https://weex.apache.org/tools/playground.html
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Jan Piotrowski  于2019年2月28日周四 下午10:13写道：
>
> > > Such tools are useful and attractive for users of Weex, and we need a
> > place
> > to list such tools in Weex eco system, ...
> >
> > Sorry, did I miss part of the thread here? What "development tools and
> > others" are you talking about?
> >
> > > As weex users are Android/iOS/JavaScript developers, they often choose
> > Gradle/Cocoapods/NPM to install the artifacts instead of source. But I
> > could list the artifacts and Gradle/Cocoapods/NPM link together in a
> > webpage later.
> >
> > This is of course no problem at all. But the original voting and
> > release process follows the required Apache way, when it is finished
> > the binaries or releases can of course be distributed in any way
> > useful to the users. See here for an example of the Cordova release
> > process:
> > https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md#otherwise-publish-real-release-to-dist--npm
> > (pretty overcomplicated because of historical reasons, but you get the
> > idea)
> >
> > Am Do., 28. Feb. 2019 um 04:58 Uhr schrieb Willem Jiang
> > :
> > >
> > > When you send the announcement of the code release, you need to list
> > > the released artifacts just like this[1].
> > > Here is  dubbo release guidelines that you can take a look.
> > >
> > > [1]http://servicecomb.apache.org/release/
> > > [2] http://dubbo.apache.org/en-us/blog/prepare-an-apache-release.html
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Thu, Feb 28, 2019 at 11:46 AM 申远  wrote:
> > > >
> > > > >
> > > > > But we can only host the downloads of the weex project, not the other
> > > > > tools which are built on top it.
> > > >
> > > >
> > > > Such tools are useful and attractive for users of Weex, and we need a
> > place
> > > > to list such tools in Weex eco system, which is important from our
> > users'
> > > > point. If there is a better place than https://weex.apache.org/ for
> > such
> > > > tools, I can move them.
> > > >
> > > > I cannot find the download the weex artifacts but only the weex IDE
> > > > > and playground.
> > > >
> > > >
> > > > As weex users are Android/iOS/JavaScript developers, they often choose
> > > > Gradle/Cocoapods/NPM to install the artifacts instead of source. But I
> > > > could list the artifacts and Gradle/Cocoapods/NPM link together in a
> > > > webpage later.
> > > >
> > > > BTW, once we vote the release, we need to distributed those release
> > > > > kit to Apache mirrors for the downloads of user.
> > > > > I don't think we did this step of work after the vote of weex 0.22.0
> > > >
> > > >
> > > > I will move it later. I think I would propose the next release of weex,
> > > > which will give me a better understanding of the whole Apache release
> > > > procedure.
> > > >
> > > > Best Regards,
> > > > YorkShen
> > > >
> > > > 申远
> > > >
> > > >
> > > > Willem Jiang  于2019年2月28日周四 上午10:35写道：
> > > >
> >

Re: Question about the website of weex

[Jan Piotrowski]

> Such tools are useful and attractive for users of Weex, and we need a place
to list such tools in Weex eco system, ...

Sorry, did I miss part of the thread here? What "development tools and
others" are you talking about?

> As weex users are Android/iOS/JavaScript developers, they often choose
Gradle/Cocoapods/NPM to install the artifacts instead of source. But I
could list the artifacts and Gradle/Cocoapods/NPM link together in a
webpage later.

This is of course no problem at all. But the original voting and
release process follows the required Apache way, when it is finished
the binaries or releases can of course be distributed in any way
useful to the users. See here for an example of the Cordova release
process: 
https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md#otherwise-publish-real-release-to-dist--npm
(pretty overcomplicated because of historical reasons, but you get the
idea)

Am Do., 28. Feb. 2019 um 04:58 Uhr schrieb Willem Jiang
:
>
> When you send the announcement of the code release, you need to list
> the released artifacts just like this[1].
> Here is  dubbo release guidelines that you can take a look.
>
> [1]http://servicecomb.apache.org/release/
> [2] http://dubbo.apache.org/en-us/blog/prepare-an-apache-release.html
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Thu, Feb 28, 2019 at 11:46 AM 申远  wrote:
> >
> > >
> > > But we can only host the downloads of the weex project, not the other
> > > tools which are built on top it.
> >
> >
> > Such tools are useful and attractive for users of Weex, and we need a place
> > to list such tools in Weex eco system, which is important from our users'
> > point. If there is a better place than https://weex.apache.org/ for such
> > tools, I can move them.
> >
> > I cannot find the download the weex artifacts but only the weex IDE
> > > and playground.
> >
> >
> > As weex users are Android/iOS/JavaScript developers, they often choose
> > Gradle/Cocoapods/NPM to install the artifacts instead of source. But I
> > could list the artifacts and Gradle/Cocoapods/NPM link together in a
> > webpage later.
> >
> > BTW, once we vote the release, we need to distributed those release
> > > kit to Apache mirrors for the downloads of user.
> > > I don't think we did this step of work after the vote of weex 0.22.0
> >
> >
> > I will move it later. I think I would propose the next release of weex,
> > which will give me a better understanding of the whole Apache release
> > procedure.
> >
> > Best Regards,
> > YorkShen
> >
> > 申远
> >
> >
> > Willem Jiang  于2019年2月28日周四 上午10:35写道：
> >
> > > Hi York,
> > >
> > > I know weex team put lot of effort to build the whole eco system, from
> > > the runtime to development tools and others.
> > > But we can only host the downloads of the weex project, not the other
> > > tools which are built on top it.
> > > I cannot find the download the weex artifacts but only the weex IDE
> > > and playground.
> > >
> > > Could you explain it?
> > >
> > > BTW, once we vote the release, we need to distributed those release
> > > kit to Apache mirrors for the downloads of user.
> > > I don't think we did this step of work after the vote of weex 0.22.0[1]
> > >
> > > [1]
> > > https://lists.apache.org/thread.html/76f90754258431e48a6d86afedd3862b642320a43e3c96de4326a9cd@%3Cgeneral.incubator.apache.org%3E
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Tue, Feb 26, 2019 at 11:54 AM 申远  wrote:
> > > >
> > > > I will redirect weex.io, weex-project.io and all other domain to
> > > > weex.apache.org ASAP.
> > > >
> > > > Meanwhile, if there is any inappropriate content under apache domain[1],
> > > > please let me know.
> > > >
> > > > So far, the following content is inappropriate:
> > > >
> > > >- https://weex.apache.org/zh/community/biz-emas.html
> > > >
> > > >
> > > > [1] https://weex.apache.org/
> > > >
> > > > Best Regards,
> > > > YorkShen
> > > >
> > > > 申远
> > > >
> > > >
> > > > Dan  于2019年2月26日周二 上午11:35写道：
> > > >
> > > > > sure, that will be remove soon, that’s my mistake,
> > > > >
> > > > > > 在 2019年2月26日，上午11:33，Willem Jiang  写道：
> > > > > >
> > > > > > It's not only about the domain name, but also about the content[1].
> > > > > > That's the key issue, if we cannot drop clear line between the 
> > > > > > apache
> > > > > > project and commercial product, the user could be confused.
> > > > > >
> > > > > > [1]http://weex.apache.org/zh/community/biz-emas.html
> > > > > >
> > > > > > Willem Jiang
> > > > > >
> > > > > > Twitter: willemjiang
> > > > > > Weibo: 姜宁willem
> > > > > >
> > > > > > On Tue, Feb 26, 2019 at 10:57 AM Dan  wrote:
> > > > > >>
> > > > > >> The weex.io doesn't use to redirect the weex.apache.org now, we
> > > have
> > > > > >> discussed on the mail list about use weex.io as the short domain of
> > > > > >> weex apache website, if it's ok, I will redirect all the weex.io
> > > page
> > > > > to
> > > > > >> 

Re: [DISCUSS] can we use weex.io as the short domain name for the apache project

[Jan Piotrowski]

I don't understand.

A "commercial eco system for weex" should not just mirror the complete
site, even (and especially!) if they add their own things.
Right now I have no idea what this really is when I go there, so this
should definitely be cleaned up.

-J

Am Do., 28. Feb. 2019 um 04:24 Uhr schrieb 申远 :
>
> EMAS is a commercial eco-system for weex, so this url[1] should not be
> redirected to https:/weex.apache.org
>
> I have talked to guys of EMAS, they are using the source code of
> incubator-weex-site [2] and some third-party content to build the website,
> while weex only use incubator-weex-site [2]
>
> [1] http://emas.weex.io/
> [2] https://github.com/apache/incubator-weex-site/
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Jan Piotrowski  于2019年2月28日周四 上午5:37写道：
>
> > Nice!
> >
> > Just found http://emas.weex.io/ which is not redirecting yet.
> >
> > J
> >
> > Am Mi., 27. Feb. 2019 um 07:00 Uhr schrieb 申远 :
> > >
> > > http://weex-project.io is also redirected to http://weex.apache.org
> > >
> > > Except for the following issue, I think we have done the relaunch
> > procedure
> > > of website:
> > >
> > >
> > >- Google Search Console Account
> > >- Redirect http://weex.apache.org to https://weex.apache.org
> > >
> > >
> > > Best Regards,
> > > YorkShen
> > >
> > > 申远
> > >
> > >
> > > Dan  于2019年2月27日周三 上午11:53写道：
> > >
> > > > > The server should just be a Apache webserver (of course!) that can
> > > > accept .htaccess files to redirect non-http requests.
> > > > Super complicated example from Cordova:
> > > >
> > > >
> > https://github.com/apache/cordova-docs/blob/3c41a7d14192eb26c883c65fc63be303f811474e/www/.htaccess#L118-L130
> > > > There should be much easier ways to achieve this.
> > > >
> > > > I will take a look and try to make weex.apache.org work with non-http.
> > > >
> > > > Thanks,
> > > > Dan
> > > >
> > > > 申远  于2019年2月27日周三 上午11:08写道：
> > > >
> > > > > The check has passed now.
> > > > >
> > > > > Best Regards,
> > > > > YorkShen
> > > > >
> > > > > 申远
> > > > >
> > > > >
> > > > > Willem Jiang  于2019年2月22日周五 下午8:08写道：
> > > > >
> > > > > > FYI, there is a tool[1] to check if the website is following the
> > Apache
> > > > > > rules.
> > > > > > Please take a look and fix them ASAP. The website issues need to be
> > > > > > addressed before graducation.
> > > > > >
> > > > > > [1]https://whimsy.apache.org/pods.cgi/project/weex
> > > > > >
> > > > > >
> > > > > >
> > > > > > Willem Jiang
> > > > > >
> > > > > > Twitter: willemjiang
> > > > > > Weibo: 姜宁willem
> > > > > >
> > > > > > On Fri, Feb 22, 2019 at 7:58 PM 申远  wrote:
> > > > > > >
> > > > > > > It seems like INFRA is not ok the mirror site in China.
> > > > > > >
> > > > > > > Anyway, I have updated the content of https://weex.apache.org/,
> > > > which
> > > > > is
> > > > > > > the same as https://weex.io now. *As there is a
> > > > > > > privilege issue, https://weex-project.io/ <
> > https://weex-project.io/>
> > > > > is
> > > > > > not
> > > > > > > updated yet.*
> > > > > > >
> > > > > > > Later, I will redirect https://weex.io and
> > https://weex-project.io/
> > > > to
> > > > > > > https://weex.apache.org/ using 302 redirection and configure
> > robots.
> > > > > > >
> > > > > > > Feedback of the new design for https://weex.apache.org/ is
> > welcomed.
> > > > > > >
> > > > > > > Thanks
> > > > > > >
> > > > > > > Best Regards,
> > > > > > > YorkShen
> > > > > > >
> > > > > > > 申远
> > > > > > >
> > > > > > >
> > > > > > > Jan Piotrowski  于2019年2月20日周三 下午8:02写道：
> > > &

Re: [DISCUSS] can we use weex.io as the short domain name for the apache project

[Jan Piotrowski]

Nice!

Just found http://emas.weex.io/ which is not redirecting yet.

J

Am Mi., 27. Feb. 2019 um 07:00 Uhr schrieb 申远 :
>
> http://weex-project.io is also redirected to http://weex.apache.org
>
> Except for the following issue, I think we have done the relaunch procedure
> of website:
>
>
>- Google Search Console Account
>- Redirect http://weex.apache.org to https://weex.apache.org
>
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Dan  于2019年2月27日周三 上午11:53写道：
>
> > > The server should just be a Apache webserver (of course!) that can
> > accept .htaccess files to redirect non-http requests.
> > Super complicated example from Cordova:
> >
> > https://github.com/apache/cordova-docs/blob/3c41a7d14192eb26c883c65fc63be303f811474e/www/.htaccess#L118-L130
> > There should be much easier ways to achieve this.
> >
> > I will take a look and try to make weex.apache.org work with non-http.
> >
> > Thanks,
> > Dan
> >
> > 申远  于2019年2月27日周三 上午11:08写道：
> >
> > > The check has passed now.
> > >
> > > Best Regards,
> > > YorkShen
> > >
> > > 申远
> > >
> > >
> > > Willem Jiang  于2019年2月22日周五 下午8:08写道：
> > >
> > > > FYI, there is a tool[1] to check if the website is following the Apache
> > > > rules.
> > > > Please take a look and fix them ASAP. The website issues need to be
> > > > addressed before graducation.
> > > >
> > > > [1]https://whimsy.apache.org/pods.cgi/project/weex
> > > >
> > > >
> > > >
> > > > Willem Jiang
> > > >
> > > > Twitter: willemjiang
> > > > Weibo: 姜宁willem
> > > >
> > > > On Fri, Feb 22, 2019 at 7:58 PM 申远  wrote:
> > > > >
> > > > > It seems like INFRA is not ok the mirror site in China.
> > > > >
> > > > > Anyway, I have updated the content of https://weex.apache.org/,
> > which
> > > is
> > > > > the same as https://weex.io now. *As there is a
> > > > > privilege issue, https://weex-project.io/ <https://weex-project.io/>
> > > is
> > > > not
> > > > > updated yet.*
> > > > >
> > > > > Later, I will redirect https://weex.io and https://weex-project.io/
> > to
> > > > > https://weex.apache.org/ using 302 redirection and configure robots.
> > > > >
> > > > > Feedback of the new design for https://weex.apache.org/ is welcomed.
> > > > >
> > > > > Thanks
> > > > >
> > > > > Best Regards,
> > > > > YorkShen
> > > > >
> > > > > 申远
> > > > >
> > > > >
> > > > > Jan Piotrowski  于2019年2月20日周三 下午8:02写道：
> > > > >
> > > > > > Good question comment you posted on the INFRA post.
> > > > > >
> > > > > > I hope they will agree, that there is no problem at all as long as
> > > the
> > > > > > official website is at weex.apache.org.
> > > > > >
> > > > > > -J
> > > > > >
> > > > > > Am Mi., 20. Feb. 2019 um 09:48 Uhr schrieb 申远 <
> > shenyua...@gmail.com
> > > >:
> > > > > > >
> > > > > > > >
> > > > > > > > But until this happens I think an absolutely practical solution
> > > > would
> > > > > > > > be to use a second host in China with a separate domain that
> > can
> > > > > > > > provide better speeds to Chinese users. It just has to show the
> > > > exact
> > > > > > > > same content as the official site (and be hidden from search
> > > > engines
> > > > > > > > via robots.txt to not confuse them). INFRA should have no real
> > > > problem
> > > > > > > > with that (as it is a appropriate workaround for their slow
> > > > response
> > > > > > > > times in China - and no branding stuff is ignored).
> > > > > > >
> > > > > > >
> > > > > > > 1. Deploying the same content to two different host and domains
> > is
> > > > what
> > > > > > we
> > > > > > > are planning to do until we understand it may still break one
> > > domain
> > > 

Re: [DISCUSS] can we use weex.io as the short domain name for the apache project

[Jan Piotrowski]

Thanks for fixing the 404s and making the homepage editable.

> we can not control the Apache server to force redirect all non-https
requests to the https version, so, now we can just replace manually, I will
check it through automated means.

The server should just be a Apache webserver (of course!) that can
accept .htaccess files to redirect non-http requests.
Super complicated example from Cordova:
https://github.com/apache/cordova-docs/blob/3c41a7d14192eb26c883c65fc63be303f811474e/www/.htaccess#L118-L130
There should be much easier ways to achieve this.

-J

Am Di., 26. Feb. 2019 um 10:44 Uhr schrieb 申远 :
>
> >
> > I am fine with editing any .yml or .json files that include the
> > content, but the headline "Cross Platforms" has to come from somewhere
> > in this repo, right?
> >
>
> The homepage is generated by
> https://github.com/apache/incubator-weex-site/blob/draft/docs/.vuepress/data/lang-en.js
> on
> draft branch, I have just merged Dans' PR.
>
>
> > Old links that are listed in Google like e.g.
> > https://weex.apache.org/references/ also _have_ to be redirected to
> > the content's new location as quickly as possible. That is one of
> > those things that destroys existing traffic to websites on relaunches.
> > (https://www.google.com/search?client=firefox-b-d=site%3Aweex.apache.org
> > - 217 pages that show mostly a 404 right now)
>
>
> The 404 problems has been fixed thanks to Dan's effort.
>
> BTW, https://weex.io has been redirected to https://weex.apache.org
> officially. I will contact the owner of weex-project.io to make it redirect
> as well later.
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Dan  于2019年2月26日周二 下午1:29写道：
>
> > Hi, Jan
> >
> > > I am fine with editing any .yml or .json files that include the
> > content, but the headline "Cross Platforms" has to come from somewhere
> > in this repo, right?
> >
> > I have created a pull request to support edit homepage date, see  [docs]
> > support edit homepage data
> > <https://github.com/apache/incubator-weex-site/pull/327>, after the pull
> > request merged, you can edit the data file to change the homepage content.
> >
> > > One thing I would advise is that you make all non-https requests
> > redirect to the https version as soon as possible.
> >
> > we can not control the Apache server to force redirect all non-https
> > requests to the https version, so, now we can just replace manually, I will
> > check it through automated means.
> >
> > > Old links that are listed in Google like e.g.
> > https://weex.apache.org/references/ also _have_ to be redirected to
> > the content's new location as quickly as possible. That is one of
> > those things that destroys existing traffic to websites on relaunches.
> > (https://www.google.com/search?client=firefox-b-d=site%3Aweex.apache.org
> > - 217 pages that show mostly a 404 right now)
> >
> > I am do it now, will be fixed today.
> >
> > > Have you already created a Google Search Console account for the site?
> > If not, someone should do so. I would be happy to look at the reports
> > being generated and give advice how to fix any possible problems.
> >
> > After finish all the below jobs, I will study how to deploy  Google Search
> > Console account on the site.
> >
> > Thanks,
> > Dan
> >
> > Jan Piotrowski  于2019年2月25日周一 下午9:18写道：
> >
> > > I am fine with editing any .yml or .json files that include the
> > > content, but the headline "Cross Platforms" has to come from somewhere
> > > in this repo, right?
> > >
> > > One thing I would advise is that you make all non-https requests
> > > redirect to the https version as soon as possible.
> > >
> > > Old links that are listed in Google like e.g.
> > > https://weex.apache.org/references/ also _have_ to be redirected to
> > > the content's new location as quickly as possible. That is one of
> > > those things that destroys existing traffic to websites on relaunches.
> > > (
> > https://www.google.com/search?client=firefox-b-d=site%3Aweex.apache.org
> > > - 217 pages that show mostly a 404 right now)
> > >
> > > Have you already created a Google Search Console account for the site?
> > > If not, someone should do so. I would be happy to look at the reports
> > > being generated and give advice how to fix any possible problems.
> > >
> > > -J
> > >
> > > Am Mo., 25. Feb. 2019 um 12:50 Uhr schrieb Dan :
> > > >
> > > 

Re: Question about the website of weex

[Jan Piotrowski]

Hm, what kind of code is the user missing at that link? (Google
Translate unfortunately didn't help)
If there was something on the old site that can now not be par of it
any more, it should at least be moved somewhere else (subdomain of
weex.io for example?) and the old URL redirected.
Being compliant with Apache rules is one thing, the other is to keep
users happy :)

-J

Am Di., 26. Feb. 2019 um 10:40 Uhr schrieb 申远 :
>
> 1. https://weex.io has been redirected to https://weex.apache.org
> 2. All the commercial should also be removed now. If there is still
> something inappropriate, please let me know, thanks.
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> 申远  于2019年2月26日周二 上午11:54写道：
>
> > I will redirect weex.io, weex-project.io and all other domain to
> > weex.apache.org ASAP.
> >
> > Meanwhile, if there is any inappropriate content under apache domain[1],
> > please let me know.
> >
> > So far, the following content is inappropriate:
> >
> >- https://weex.apache.org/zh/community/biz-emas.html
> >
> >
> > [1] https://weex.apache.org/
> >
> > Best Regards,
> > YorkShen
> >
> > 申远
> >
> >
> > Dan  于2019年2月26日周二 上午11:35写道：
> >
> >> sure, that will be remove soon, that’s my mistake,
> >>
> >> > 在 2019年2月26日，上午11:33，Willem Jiang  写道：
> >> >
> >> > It's not only about the domain name, but also about the content[1].
> >> > That's the key issue, if we cannot drop clear line between the apache
> >> > project and commercial product, the user could be confused.
> >> >
> >> > [1]http://weex.apache.org/zh/community/biz-emas.html
> >> >
> >> > Willem Jiang
> >> >
> >> > Twitter: willemjiang
> >> > Weibo: 姜宁willem
> >> >
> >> > On Tue, Feb 26, 2019 at 10:57 AM Dan  wrote:
> >> >>
> >> >> The weex.io doesn't use to redirect the weex.apache.org now, we have
> >> >> discussed on the mail list about use weex.io as the short domain of
> >> >> weex apache website, if it's ok, I will redirect all the weex.io page
> >> to
> >> >> the weex.apache.org.
> >> >>
> >> >> Thanks,
> >> >> Dan
> >> >>
> >> >> Willem Jiang  于2019年2月26日周二 上午10:51写道：
> >> >>
> >> >>> There is angry user github issue[1] about he wants his use case code
> >> back.
> >> >>>
> >> >>> So I get a close look of the weex.io website, it looks there are some
> >> >>> Alibaba's content[2] in the site.  As weex is donated to ASF, and ASF
> >> >>> in vendor neutral organization. We cannot mix the commercial content
> >> >>> with Apache project in the same site.
> >> >>>
> >> >>> I'm not sure if the PPMC member are knowing about this things, can you
> >> >>> explain it and let work on an solution together.
> >> >>>
> >> >>> [1]https://github.com/apache/incubator-weex-site/issues/325
> >> >>> [2]http://emas.weex.io/zh/community/biz-emas.html
> >> >>>
> >> >>> Willem Jiang
> >> >>>
> >> >>> Twitter: willemjiang
> >> >>> Weibo: 姜宁willem
> >> >>>
> >>
> >>

Re: [DISCUSS] can we use weex.io as the short domain name for the apache project

[Jan Piotrowski]

I am fine with editing any .yml or .json files that include the
content, but the headline "Cross Platforms" has to come from somewhere
in this repo, right?

One thing I would advise is that you make all non-https requests
redirect to the https version as soon as possible.

Old links that are listed in Google like e.g.
https://weex.apache.org/references/ also _have_ to be redirected to
the content's new location as quickly as possible. That is one of
those things that destroys existing traffic to websites on relaunches.
(https://www.google.com/search?client=firefox-b-d=site%3Aweex.apache.org
- 217 pages that show mostly a 404 right now)

Have you already created a Google Search Console account for the site?
If not, someone should do so. I would be happy to look at the reports
being generated and give advice how to fix any possible problems.

-J

Am Mo., 25. Feb. 2019 um 12:50 Uhr schrieb Dan :
>
> Hi, Jan
>
> We deployed an automated server build system for building the content of
> weex.apache.org, the homepage is not a pure HTML file that can be easily
> edited.
>
> If you have any advice about this page, please let me know, I will improve
> it later.
>
> Maybe some of the content can be built from a data file on the
> incubator-weex-site <https://github.com/apache/incubator-weex-site> repo.
>
> Thanks,
> Dan
>
> Jan Piotrowski  于2019年2月25日周一 下午6:11写道：
>
> > Yeah, the homepage is unfortunately missing that button ;)
> > As the content is still in the `draft` branch, I also can't just
> > search for a sub string of the headlines to fine the page that
> > represents the homepage - could you please point me to the correct
> > file?
> >
> > -J
> >
> > Am Mo., 25. Feb. 2019 um 10:59 Uhr schrieb 申远 :
> > >
> > > There are two options.
> > >
> > > 1. On the bottom of each page, there is a button called *Edit this
> > page.* Just
> > > click it, then you will be navigated to the right branch and file on the
> > > github.
> > > 2. If you prefer do things manually, Go to draft branch of
> > > https://github.com/apache/incubator-weex-site/tree/draft.
> > >
> > > I normally prefer the first choice unless I have to write a totally new
> > > article.
> > >
> > > BTW, the following approach is described in the docs, too. Ref
> > >
> > https://weex.apache.org/guide/contribute/how-to-contribute.html#contribute-code-or-document
> > >
> > > Best Regards,
> > > YorkShen
> > >
> > > 申远
> > >
> > >
> > > Jan Piotrowski  于2019年2月25日周一 下午5:46写道：
> > >
> > > > Nice.
> > > >
> > > > Which is the repository and branch to send PRs with typo fixes etc to?
> > > >
> > > > Am Mo., 25. Feb. 2019 um 10:18 Uhr schrieb 申远 :
> > > > >
> > > > > Hi, there
> > > > >
> > > > > I had fix the 404 error and updated the website of weex.apache.org,
> > > > which
> > > > > content should be the same as weex.io now. I will configure a 302
> > > > > redirection later, which will make all the mirror site redirects to
> > > > > weex.apache.org.
> > > > >
> > > > > Best Regards,
> > > > > YorkShen
> > > > >
> > > > > 申远
> > > > >
> > > > >
> > > > > 申远  于2019年2月22日周五 下午8:46写道：
> > > > >
> > > > > > As there is a wired 404 problem under Apache domain, which works
> > fine
> > > > > > under weex.io domain, I have to revert all the changes on
> > > > weex.apache.org .
> > > > > > I will publish it again when I find out what is happening here.
> > > > Meanwhile,
> > > > > > one may take https://weex.io as the preview version of new weex
> > > > website
> > > > > > before the republish.
> > > > > >
> > > > > > Sorry for the inconvenience.
> > > > > >
> > > > > > Best Regards,
> > > > > > YorkShen
> > > > > >
> > > > > > 申远
> > > > > >
> > > > > >
> > > > > > Willem Jiang  于2019年2月22日周五 下午8:08写道：
> > > > > >
> > > > > >> FYI, there is a tool[1] to check if the website is following the
> > > > Apache
> > > > > >> rules.
> > > > > >> Please take a look and fix them ASAP. The website issues need to
> &g

Re: [DISCUSS] can we use weex.io as the short domain name for the apache project

[Jan Piotrowski]

Yeah, the homepage is unfortunately missing that button ;)
As the content is still in the `draft` branch, I also can't just
search for a sub string of the headlines to fine the page that
represents the homepage - could you please point me to the correct
file?

-J

Am Mo., 25. Feb. 2019 um 10:59 Uhr schrieb 申远 :
>
> There are two options.
>
> 1. On the bottom of each page, there is a button called *Edit this page.* Just
> click it, then you will be navigated to the right branch and file on the
> github.
> 2. If you prefer do things manually, Go to draft branch of
> https://github.com/apache/incubator-weex-site/tree/draft.
>
> I normally prefer the first choice unless I have to write a totally new
> article.
>
> BTW, the following approach is described in the docs, too. Ref
> https://weex.apache.org/guide/contribute/how-to-contribute.html#contribute-code-or-document
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Jan Piotrowski  于2019年2月25日周一 下午5:46写道：
>
> > Nice.
> >
> > Which is the repository and branch to send PRs with typo fixes etc to?
> >
> > Am Mo., 25. Feb. 2019 um 10:18 Uhr schrieb 申远 :
> > >
> > > Hi, there
> > >
> > > I had fix the 404 error and updated the website of weex.apache.org,
> > which
> > > content should be the same as weex.io now. I will configure a 302
> > > redirection later, which will make all the mirror site redirects to
> > > weex.apache.org.
> > >
> > > Best Regards,
> > > YorkShen
> > >
> > > 申远
> > >
> > >
> > > 申远  于2019年2月22日周五 下午8:46写道：
> > >
> > > > As there is a wired 404 problem under Apache domain, which works fine
> > > > under weex.io domain, I have to revert all the changes on
> > weex.apache.org .
> > > > I will publish it again when I find out what is happening here.
> > Meanwhile,
> > > > one may take https://weex.io as the preview version of new weex
> > website
> > > > before the republish.
> > > >
> > > > Sorry for the inconvenience.
> > > >
> > > > Best Regards,
> > > > YorkShen
> > > >
> > > > 申远
> > > >
> > > >
> > > > Willem Jiang  于2019年2月22日周五 下午8:08写道：
> > > >
> > > >> FYI, there is a tool[1] to check if the website is following the
> > Apache
> > > >> rules.
> > > >> Please take a look and fix them ASAP. The website issues need to be
> > > >> addressed before graducation.
> > > >>
> > > >> [1]https://whimsy.apache.org/pods.cgi/project/weex
> > > >>
> > > >>
> > > >>
> > > >> Willem Jiang
> > > >>
> > > >> Twitter: willemjiang
> > > >> Weibo: 姜宁willem
> > > >>
> > > >> On Fri, Feb 22, 2019 at 7:58 PM 申远  wrote:
> > > >> >
> > > >> > It seems like INFRA is not ok the mirror site in China.
> > > >> >
> > > >> > Anyway, I have updated the content of https://weex.apache.org/,
> > which
> > > >> is
> > > >> > the same as https://weex.io now. *As there is a
> > > >> > privilege issue, https://weex-project.io/ <https://weex-project.io/
> > >
> > > >> is not
> > > >> > updated yet.*
> > > >> >
> > > >> > Later, I will redirect https://weex.io and https://weex-project.io/
> > to
> > > >> > https://weex.apache.org/ using 302 redirection and configure
> > robots.
> > > >> >
> > > >> > Feedback of the new design for https://weex.apache.org/ is
> > welcomed.
> > > >> >
> > > >> > Thanks
> > > >> >
> > > >> > Best Regards,
> > > >> > YorkShen
> > > >> >
> > > >> > 申远
> > > >> >
> > > >> >
> > > >> > Jan Piotrowski  于2019年2月20日周三 下午8:02写道：
> > > >> >
> > > >> > > Good question comment you posted on the INFRA post.
> > > >> > >
> > > >> > > I hope they will agree, that there is no problem at all as long
> > as the
> > > >> > > official website is at weex.apache.org.
> > > >> > >
> > > >> > > -J
> > > >> > >
> > > >> > > Am Mi., 20. F

Re: [DISCUSS] can we use weex.io as the short domain name for the apache project

[Jan Piotrowski]

Nice.

Which is the repository and branch to send PRs with typo fixes etc to?

Am Mo., 25. Feb. 2019 um 10:18 Uhr schrieb 申远 :
>
> Hi, there
>
> I had fix the 404 error and updated the website of weex.apache.org, which
> content should be the same as weex.io now. I will configure a 302
> redirection later, which will make all the mirror site redirects to
> weex.apache.org.
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> 申远  于2019年2月22日周五 下午8:46写道：
>
> > As there is a wired 404 problem under Apache domain, which works fine
> > under weex.io domain, I have to revert all the changes on weex.apache.org .
> > I will publish it again when I find out what is happening here. Meanwhile,
> > one may take https://weex.io as the preview version of new weex website
> > before the republish.
> >
> > Sorry for the inconvenience.
> >
> > Best Regards,
> > YorkShen
> >
> > 申远
> >
> >
> > Willem Jiang  于2019年2月22日周五 下午8:08写道：
> >
> >> FYI, there is a tool[1] to check if the website is following the Apache
> >> rules.
> >> Please take a look and fix them ASAP. The website issues need to be
> >> addressed before graducation.
> >>
> >> [1]https://whimsy.apache.org/pods.cgi/project/weex
> >>
> >>
> >>
> >> Willem Jiang
> >>
> >> Twitter: willemjiang
> >> Weibo: 姜宁willem
> >>
> >> On Fri, Feb 22, 2019 at 7:58 PM 申远  wrote:
> >> >
> >> > It seems like INFRA is not ok the mirror site in China.
> >> >
> >> > Anyway, I have updated the content of https://weex.apache.org/, which
> >> is
> >> > the same as https://weex.io now. *As there is a
> >> > privilege issue, https://weex-project.io/ <https://weex-project.io/>
> >> is not
> >> > updated yet.*
> >> >
> >> > Later, I will redirect https://weex.io and https://weex-project.io/ to
> >> > https://weex.apache.org/ using 302 redirection and configure robots.
> >> >
> >> > Feedback of the new design for https://weex.apache.org/ is welcomed.
> >> >
> >> > Thanks
> >> >
> >> > Best Regards,
> >> > YorkShen
> >> >
> >> > 申远
> >> >
> >> >
> >> > Jan Piotrowski  于2019年2月20日周三 下午8:02写道：
> >> >
> >> > > Good question comment you posted on the INFRA post.
> >> > >
> >> > > I hope they will agree, that there is no problem at all as long as the
> >> > > official website is at weex.apache.org.
> >> > >
> >> > > -J
> >> > >
> >> > > Am Mi., 20. Feb. 2019 um 09:48 Uhr schrieb 申远 :
> >> > > >
> >> > > > >
> >> > > > > But until this happens I think an absolutely practical solution
> >> would
> >> > > > > be to use a second host in China with a separate domain that can
> >> > > > > provide better speeds to Chinese users. It just has to show the
> >> exact
> >> > > > > same content as the official site (and be hidden from search
> >> engines
> >> > > > > via robots.txt to not confuse them). INFRA should have no real
> >> problem
> >> > > > > with that (as it is a appropriate workaround for their slow
> >> response
> >> > > > > times in China - and no branding stuff is ignored).
> >> > > >
> >> > > >
> >> > > > 1. Deploying the same content to two different host and domains is
> >> what
> >> > > we
> >> > > > are planning to do until we understand it may still break one domain
> >> > > rule.
> >> > > >
> >> > > > 2. According to https://issues.apache.org/jira/browse/INFRA-17872
> >> , I
> >> > > think
> >> > > > INFRA have different point of view on separate domain with same
> >> content.
> >> > > >
> >> > > > 3. Personally speaking, I understand a world wide CDN is not
> >> practical
> >> > > now
> >> > > > and sometimes one may give up a better engineer solution due to law
> >> > > issue.
> >> > > > From user points, we need to give a brief explanation of the latency
> >> > > > problem.
> >> > > >
> >> > > > Best Regards,
> >> &

Re: [DISCUSS] Language used in Mail/Github/etc..

[Jan Piotrowski]

After further thinking about it I think I agree with Myrle:
If you can answer a Chinese issue in Chinese, just do so.
If you want, you can translate both question and answer to English
manually or automatically as well.
I don't read any Chinese, so I would definitely have to translate to
English and then write my response in English. As a service (and
respect) to the user I then also might translate my response to
Chinese automatically and post that as well.

Real rules on languages will probably only be required for formal
discussions and votes here on the mailing list.

-J

Am Fr., 22. Feb. 2019 um 09:38 Uhr schrieb Willem Jiang
:
>
> It may relate to audience which we are target. If the target audience
> doesn't speak English it could be challenge for him to get the answer
> in English. It's natural to fill strange if you just see a bunch of
> Chinese sitting together using their unfluent English talk to each
> other.
>
> But as you may not know there could be other people who try to find
> information in the mailing list by using the search engine.   As an
> apache project, there are lots of potential users who speak English,
> using English to answer the question could help them to understand the
> who pictures more easily.
>
> Most of Chinese developer can read and write English document, as we
> spend more than 6 years to study English. I don't think it could be a
> blocker for us to build the community by answering the question in
> English. But we need to keep in mind that the discussion we have is
> not just for us, it's could for the community to catch up later.
>
> FYI, there are some discussions[1] years ago about using IM (such as
> QQ and WeChat) and Chinese, you may take a look at them.
>
> [1]https://www.mail-archive.com/general@incubator.apache.org/msg57192.html
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Fri, Feb 22, 2019 at 4:05 PM 申远  wrote:
> >
> > >
> > > I saw some people using Google Translate to translate the question,
> > > then repost the question in English before answering. That makes it
> > > clear(er), that English is the preferred language and also allows
> > > people like me to participate.
> >
> >
> > I used to paste the result of Google Translate from Chinese question to
> > English, then answer it in English, until I realized that the users who
> > post the question may not understand my answer in English, which doesn't
> > fulfill the goal of helping user at all. Besides, from our users' point,
> > choosing a language the original user may not understand by deliberately
> > may be a arrogant behavior.
> >
> > Maybe I should answer Chinese Question with English and then Google
> > translate back to English, which is still a little wired and complicated
> > though.
> >
> > Best Regards,
> > YorkShen
> >
> > 申远
> >
> >
> > Willem Jiang  于2019年2月22日周五 上午10:48写道：
> >
> > > I think using the English to discuss is consider for more audiences
> > > across the world,  with the help of translator service it's not big
> > > challenge for the average chinese developer to get involved.
> > > We could set up a rule in the mailing list or gitter to discuss the
> > > question in English. From my experience it's a big first step to build
> > > the  internationalized community.
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Thu, Feb 21, 2019 at 12:21 PM 申远  wrote:
> > > >
> > > > As we all know, there are many users of Weex are Chinese.
> > > >
> > > > As a result, there are many user expresses their opinion using Chinese 
> > > > in
> > > > Github . What should
> > > we do
> > > > under this situation?
> > > >
> > > > 1. Answering their question with English, which is wired as original 
> > > > post
> > > > is Chinese. Moreover, it may be a little arrogant as answering Chinese
> > > > question with English shows the person written the answer understand
> > > > Chinese but somehow choose a language(English) deliberately the original
> > > > poster may not understand.
> > > >
> > > > 2. Answering questions with Chinese, which is a easy work for me and
> > > other
> > > > Chinese users. But other users that who doesn't speak Chinese will have 
> > > > a
> > > > difficult time to understand what is happening here.
> > > >
> > > > Best Regards,
> > > > YorkShen
> > > >
> > > > 申远
> > >

Re: [FEATURE] Add a new component to support Html tags(can custom tag's implement)

[Jan Piotrowski]

There also seems to be a related documentation PR at
https://github.com/apache/incubator-weex-site/pull/308

-J

Am Do., 21. Feb. 2019 um 09:41 Uhr schrieb 申远 :
>
> It would be better if you could share your feature with more detail here,
> like document so that everyone can understand what is happening here.
>
> Thanks
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Bruce too  于2019年2月21日周四 下午3:08写道：
>
> > We can check this PR 
> >

Re: Update weex descriptions on Apache site

[Jan Piotrowski]

Ha, good that you got some practice in then - you will probably also need
SVN to publish the releases to be voted on ;)

(Using TortoiseSVN for me was a really nostalgic moment. So many years
working with that software - all forgotten now)

-J

Am Do., 21. Feb. 2019 um 07:31 Uhr schrieb 申远 :

> I have updated the website of
> http://incubator.apache.org/projects/weex.html according
> to monthly incubator PMC report from Jan, 2017 to now.
>
> It may take a while before the website updated.
>
> BTW: This is the first time I used svn after I had got graduated from
> college, which reminds me of school time.
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Willem Jiang  于2019年2月13日周三 下午12:38写道：
>
> > You can send me the diff file if you don't have the right to change.
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> >
> > On Wed, Feb 13, 2019 at 11:41 AM 申远  wrote:
> >
> > > It seems like that XML file hosted on SVN, which is a quite classic
> way.
> > 
> > >
> > > I will try later after I get my SVN environment installed.
> > >
> > > Best Regards,
> > > YorkShen
> > >
> > > 申远
> > >
> > >
> > > Willem Jiang  于2019年2月2日周六 上午11:49写道：
> > >
> > > > Yes, the website is generated from the XML file. Can you try to
> update
> > > > the file yourself?
> > > > The Apache Member has the right to change it but I'm such if the PPMC
> > > > has the same right to updated the file.
> > > >
> > > >
> > > > Willem Jiang
> > > >
> > > > Twitter: willemjiang
> > > > Weibo: 姜宁willem
> > > >
> > > > On Thu, Jan 31, 2019 at 11:10 AM York Shen 
> > wrote:
> > > > >
> > > > > I found the content of the weex website (
> > > > http://incubator.apache.org/projects/weex.html <
> > > > http://incubator.apache.org/projects/weex.html>) is written by XML
> > > >
> > >
> >
> https://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/weex.xml
> > > > <
> > > >
> > >
> >
> https://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/weex.xml
> > > >
> > > > .
> > > > >
> > > > > Do I need to change the XML file directly or is the XML file
> > generated
> > > > by another file like xxx.html and I should change xxx.html?
> > > > >
> > > > > Best Regards,
> > > > > York Shen
> > > > >
> > > > > 申远
> > > > >
> > > > > > 在 2019年1月29日，09:00，Willem Jiang  写道：
> > > > > >
> > > > > > The website is generated from the here[1]. You may need to Apache
> > > > > > member right to edit it.
> > > > > > If you cannot change it, please let me know the change, I'd happy
> > to
> > > > > > update it for you.
> > > > > >
> > > > > > [1]https://svn.apache.org/repos/asf/incubator/public/trunk
> > > > > > [2]
> > > >
> > >
> >
> https://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/weex.xml
> > > > > >
> > > > > > Willem Jiang
> > > > > >
> > > > > > Twitter: willemjiang
> > > > > > Weibo: 姜宁willem
> > > > > >
> > > > > > On Wed, Jan 16, 2019 at 8:49 PM 申远  wrote:
> > > > > >>
> > > > > >> Hi, there
> > > > > >>
> > > > > >> I’d like to update the page of weex
> > > > http://incubator.apache.org/projects/weex.html <
> > > > http://incubator.apache.org/projects/weex.html> , it seems like
> > > outdated.
> > > > I didn’t find any editing button on the page, it would be great if
> some
> > > > could tell me how to edit that page.
> > > > > >>
> > > > > >> Thanks
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Language used in Mail/Github/etc..

[Jan Piotrowski]

Difficult situation.

Apache projects definitely use English as the default language, but
with an existing userbase that is used to create issue in Chinese,
this would be negative to enforce.

I saw some people using Google Translate to translate the question,
then repost the question in English before answering. That makes it
clear(er), that English is the preferred language and also allows
people like me to participate.

Then you can answer in English and optionally also include an
automated translation again.
If you know both languages, then you can quickly check of the
translations make sense.

I on the other hand, would probably just answer in English and leave
the translation up to the user as I have no grasp at all of Chinese.

It might help to make more people create English issues by mentioning
that English issues are preferred in
https://github.com/apache/incubator-weex/blob/master/.github/ISSUE_TEMPLATE/bug-report.md

What do you think how many of the users actually have no understanding
of English?

-J

Am Do., 21. Feb. 2019 um 05:21 Uhr schrieb 申远 :
>
> As we all know, there are many users of Weex are Chinese.
>
> As a result, there are many user expresses their opinion using Chinese in
> Github . What should we do
> under this situation?
>
> 1. Answering their question with English, which is wired as original post
> is Chinese. Moreover, it may be a little arrogant as answering Chinese
> question with English shows the person written the answer understand
> Chinese but somehow choose a language(English) deliberately the original
> poster may not understand.
>
> 2. Answering questions with Chinese, which is a easy work for me and other
> Chinese users. But other users that who doesn't speak Chinese will have a
> difficult time to understand what is happening here.
>
> Best Regards,
> YorkShen
>
> 申远

Re: [DISCUSS] can we use weex.io as the short domain name for the apache project

[Jan Piotrowski]

Good question comment you posted on the INFRA post.

I hope they will agree, that there is no problem at all as long as the
official website is at weex.apache.org.

-J

Am Mi., 20. Feb. 2019 um 09:48 Uhr schrieb 申远 :
>
> >
> > But until this happens I think an absolutely practical solution would
> > be to use a second host in China with a separate domain that can
> > provide better speeds to Chinese users. It just has to show the exact
> > same content as the official site (and be hidden from search engines
> > via robots.txt to not confuse them). INFRA should have no real problem
> > with that (as it is a appropriate workaround for their slow response
> > times in China - and no branding stuff is ignored).
>
>
> 1. Deploying the same content to two different host and domains is what we
> are planning to do until we understand it may still break one domain rule.
>
> 2. According to https://issues.apache.org/jira/browse/INFRA-17872 , I think
> INFRA have different point of view on separate domain with same content.
>
> 3. Personally speaking, I understand a world wide CDN is not practical now
> and sometimes one may give up a better engineer solution due to law issue.
> From user points, we need to give a brief explanation of the latency
> problem.
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Jan Piotrowski  于2019年2月20日周三 上午2:24写道：
>
> > Uh, the _domain name_ is not actually at all related to the speed of
> > the site - the _hosting_ is.
> >
> > My results for those two domains from Germany, Berlin for example:
> >
> > C:\Users\Jan>ping weex.io
> >
> > Pinging weex.io [47.75.160.176] with 32 bytes of data:
> > Reply from 47.75.160.176: bytes=32 time=327ms TTL=46
> > Reply from 47.75.160.176: bytes=32 time=327ms TTL=46
> > Reply from 47.75.160.176: bytes=32 time=327ms TTL=46
> > Reply from 47.75.160.176: bytes=32 time=335ms TTL=46
> >
> > Ping statistics for 47.75.160.176:
> > Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
> > Approximate round trip times in milli-seconds:
> > Minimum = 327ms, Maximum = 335ms, Average = 329ms
> >
> > C:\Users\Jan>ping weex.apache.org
> >
> > Pinging weex.apache.org [2a01:4f9:2a:185f::2] with 32 bytes of data:
> > Reply from 2a01:4f9:2a:185f::2: time=46ms
> > Reply from 2a01:4f9:2a:185f::2: time=46ms
> > Reply from 2a01:4f9:2a:185f::2: time=49ms
> > Reply from 2a01:4f9:2a:185f::2: time=46ms
> >
> > Ping statistics for 2a01:4f9:2a:185f::2:
> > Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
> > Approximate round trip times in milli-seconds:
> > Minimum = 46ms, Maximum = 49ms, Average = 46ms
> >
> > So you should be aware that the actual problem (Apache server is slow
> > from China) is a different one that is now discussed with INFRA (Can
> > project use a different domain).
> >
> > The only real solution is for INFRA to use a world wide CDN that is
> > fast everywhere.
> >
> > But until this happens I think an absolutely practical solution would
> > be to use a second host in China with a separate domain that can
> > provide better speeds to Chinese users. It just has to show the exact
> > same content as the official site (and be hidden from search engines
> > via robots.txt to not confuse them). INFRA should have no real problem
> > with that (as it is a appropriate workaround for their slow response
> > times in China - and no branding stuff is ignored).
> >
> > -J
> >
> > Am Di., 19. Feb. 2019 um 12:57 Uhr schrieb Myrle Krantz  > >:
> > >
> > > I've created an INFRA ticket:
> > >
> > > https://issues.apache.org/jira/browse/INFRA-17872
> > >
> > > I won't promise that INFRA can solve this, but hopefully they'll at least
> > > look at it.
> > >
> > > Feel free to add any details you have.
> > >
> > > Best Regards,
> > > Myrle
> > >
> > > On Tue, Feb 19, 2019 at 7:18 AM Dan  wrote:
> > >
> > > > Thanks, Jan, I will take a look at this.
> > > >
> > > > Jan Piotrowski  于2019年2月18日周一 下午6:15写道：
> > > >
> > > > > Cordova uses the npm package `insight` for telemetry, you can see
> > more
> > > > > in these two files:
> > > > > https://github.com/apache/cordova-cli/blob/master/src/telemetry.js
> > > > > https://github.com/apache/cordova-cli/blob/master/src/cli.js
> > > > > The data being tracked is very limited, and all done only after
> > > > > explici

Re: [DISCUSS] can we use weex.io as the short domain name for the apache project

[Jan Piotrowski]

Uh, the _domain name_ is not actually at all related to the speed of
the site - the _hosting_ is.

My results for those two domains from Germany, Berlin for example:

C:\Users\Jan>ping weex.io

Pinging weex.io [47.75.160.176] with 32 bytes of data:
Reply from 47.75.160.176: bytes=32 time=327ms TTL=46
Reply from 47.75.160.176: bytes=32 time=327ms TTL=46
Reply from 47.75.160.176: bytes=32 time=327ms TTL=46
Reply from 47.75.160.176: bytes=32 time=335ms TTL=46

Ping statistics for 47.75.160.176:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 327ms, Maximum = 335ms, Average = 329ms

C:\Users\Jan>ping weex.apache.org

Pinging weex.apache.org [2a01:4f9:2a:185f::2] with 32 bytes of data:
Reply from 2a01:4f9:2a:185f::2: time=46ms
Reply from 2a01:4f9:2a:185f::2: time=46ms
Reply from 2a01:4f9:2a:185f::2: time=49ms
Reply from 2a01:4f9:2a:185f::2: time=46ms

Ping statistics for 2a01:4f9:2a:185f::2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 46ms, Maximum = 49ms, Average = 46ms

So you should be aware that the actual problem (Apache server is slow
from China) is a different one that is now discussed with INFRA (Can
project use a different domain).

The only real solution is for INFRA to use a world wide CDN that is
fast everywhere.

But until this happens I think an absolutely practical solution would
be to use a second host in China with a separate domain that can
provide better speeds to Chinese users. It just has to show the exact
same content as the official site (and be hidden from search engines
via robots.txt to not confuse them). INFRA should have no real problem
with that (as it is a appropriate workaround for their slow response
times in China - and no branding stuff is ignored).

-J

Am Di., 19. Feb. 2019 um 12:57 Uhr schrieb Myrle Krantz :
>
> I've created an INFRA ticket:
>
> https://issues.apache.org/jira/browse/INFRA-17872
>
> I won't promise that INFRA can solve this, but hopefully they'll at least
> look at it.
>
> Feel free to add any details you have.
>
> Best Regards,
> Myrle
>
> On Tue, Feb 19, 2019 at 7:18 AM Dan  wrote:
>
> > Thanks, Jan, I will take a look at this.
> >
> > Jan Piotrowski  于2019年2月18日周一 下午6:15写道：
> >
> > > Cordova uses the npm package `insight` for telemetry, you can see more
> > > in these two files:
> > > https://github.com/apache/cordova-cli/blob/master/src/telemetry.js
> > > https://github.com/apache/cordova-cli/blob/master/src/cli.js
> > > The data being tracked is very limited, and all done only after
> > > explicit opt-in by the user. (You get a prompt when you first install
> > > Cordova).
> > > The dashboard itself is built on the Google Analytics data source that
> > > collects the data for pretty graphs.
> > >
> > > One problem: I am under the impression that Google Analytics is
> > > blocked for good parts of Chinese users, so Cordova's data regarding
> > > usage in China is probably very broken.
> > >
> > > -J
> > >
> > > Am Mo., 18. Feb. 2019 um 08:29 Uhr schrieb Dan :
> > > >
> > > > Hi Jan,
> > > >
> > > > Thanks for getting back to me.
> > > >
> > > > Your opinion has helped us a lot. We will migrate the deployment of the
> > > > document to weex.apache.org in these two days.
> > > >
> > > > BTW, do you know the detail about how to do the user-track bellow the
> > > > apache way, I know the Cordova has telemetry.cordova.io to record it,
> > > and
> > > > we also want to record the user's behavior in the weex-toolkit to help
> > us
> > > > better improve the tool experience.
> > > >
> > > > Thanks,
> > > > Dan
> > > >
> > > > Jan Piotrowski  于2019年2月15日周五 下午7:42写道：
> > > >
> > > > > Besides what the rules say (which I don't really know):
> > > > >
> > > > > An apache.org domain has an incredible effect on credibility and
> > > > > trust. Apache is a really strong brand with developers, and
> > especially
> > > > > new projects like Weex can benefit from that.
> > > > >
> > > > > (The project will be called "Apache Weex" anyway)
> > > > >
> > > > > Apache Cordova owns the cordova.io domain and uses it as a redirect
> > to
> > > > > cordova.apache.org. That way we can still tell people to go to
> > > > > "cordova.io", but on Google and in user's browser everything happens
> 

Re: [DISCUSS] can we use weex.io as the short domain name for the apache project

[Jan Piotrowski]

Cordova uses the npm package `insight` for telemetry, you can see more
in these two files:
https://github.com/apache/cordova-cli/blob/master/src/telemetry.js
https://github.com/apache/cordova-cli/blob/master/src/cli.js
The data being tracked is very limited, and all done only after
explicit opt-in by the user. (You get a prompt when you first install
Cordova).
The dashboard itself is built on the Google Analytics data source that
collects the data for pretty graphs.

One problem: I am under the impression that Google Analytics is
blocked for good parts of Chinese users, so Cordova's data regarding
usage in China is probably very broken.

-J

Am Mo., 18. Feb. 2019 um 08:29 Uhr schrieb Dan :
>
> Hi Jan,
>
> Thanks for getting back to me.
>
> Your opinion has helped us a lot. We will migrate the deployment of the
> document to weex.apache.org in these two days.
>
> BTW, do you know the detail about how to do the user-track bellow the
> apache way, I know the Cordova has telemetry.cordova.io to record it, and
> we also want to record the user's behavior in the weex-toolkit to help us
> better improve the tool experience.
>
> Thanks,
> Dan
>
> Jan Piotrowski  于2019年2月15日周五 下午7:42写道：
>
> > Besides what the rules say (which I don't really know):
> >
> > An apache.org domain has an incredible effect on credibility and
> > trust. Apache is a really strong brand with developers, and especially
> > new projects like Weex can benefit from that.
> >
> > (The project will be called "Apache Weex" anyway)
> >
> > Apache Cordova owns the cordova.io domain and uses it as a redirect to
> > cordova.apache.org. That way we can still tell people to go to
> > "cordova.io", but on Google and in user's browser everything happens
> > on apache.cordova.org. We also have loads of subdomains like
> > blog.cordova.io issues.cordova.io, slack.cordova.io,
> > telemetry.cordova.io and so on as shortcuts which is very handy.
> >
> > Using the domains you mentioned, weex.io could redirect to
> > weex.apache.org, docs.weex.io redirects to weex.apache.org/docs,
> > blog.weex.io to weex.apache.org/blog and so on. Then cn.weex.io could
> > redirect to weex-project.io for easier finding of the Chinese domain.
> >
> > -J
> >
> >
> >
> >
> >
> >
> >
> > > On 15. Feb 2019, at 07:38, Dan  wrote:
> > >
> > > Hi, Myrle/Willem,
> > >
> > > Currently, we have a domain name of weex.io and want to use it to
> > replace
> > > the previous weex-project.io domain name for the following reasons:
> > >
> > > 1. The domain name is shorter and easier to remember.
> > > 2. Apache's website has slower access to the developer in China, so there
> > > is a mirror website weex-project.io for Chinese developer.
> > > 3. We expect to support https on this website and support some of our own
> > > server functions, such as Q robots, article blog posts, etc.
> > >
> > > I would like to ask if apache has any restrictions on this third-party
> > > domain name, and look forward to hearing from you.
> > >
> > > Thanks,
> > > Dan
> >

Re: [DISCUSS] can we use weex.io as the short domain name for the apache project

[Jan Piotrowski]

Besides what the rules say (which I don't really know):

An apache.org domain has an incredible effect on credibility and
trust. Apache is a really strong brand with developers, and especially
new projects like Weex can benefit from that.

(The project will be called "Apache Weex" anyway)

Apache Cordova owns the cordova.io domain and uses it as a redirect to
cordova.apache.org. That way we can still tell people to go to
"cordova.io", but on Google and in user's browser everything happens
on apache.cordova.org. We also have loads of subdomains like
blog.cordova.io issues.cordova.io, slack.cordova.io,
telemetry.cordova.io and so on as shortcuts which is very handy.

Using the domains you mentioned, weex.io could redirect to
weex.apache.org, docs.weex.io redirects to weex.apache.org/docs,
blog.weex.io to weex.apache.org/blog and so on. Then cn.weex.io could
redirect to weex-project.io for easier finding of the Chinese domain.

-J







> On 15. Feb 2019, at 07:38, Dan  wrote:
>
> Hi, Myrle/Willem,
>
> Currently, we have a domain name of weex.io and want to use it to replace
> the previous weex-project.io domain name for the following reasons:
>
> 1. The domain name is shorter and easier to remember.
> 2. Apache's website has slower access to the developer in China, so there
> is a mirror website weex-project.io for Chinese developer.
> 3. We expect to support https on this website and support some of our own
> server functions, such as Q robots, article blog posts, etc.
>
> I would like to ask if apache has any restrictions on this third-party
> domain name, and look forward to hearing from you.
>
> Thanks,
> Dan

Re: Weex, Apache and outside code

[Jan Piotrowski]

I read through the links you provided Willem, and extracted the following
questions that have to be answered:

1. What repositories should be imported? (=> List of repositories)
2. Who contributed to theses repositories? Who are active and relevant
contributors? (Individuals and companies) (=> List of names)
3. Are all names from that list joining as contributors / PMC members? (=>
Yes/No)
4. If yes: ICLA for all have to be available
5. If no: SGA
6. Is gene...@incubator.apache.org ok with the ICLAs and SGAs on hand?

I assume that the existing weex Apache codebase went through the same
process, so this shouldn't actually be too hard if only the same people
worked on the additional repositories that should be moved.

When the questions above are answered, it should be pretty easy for one of
the mentors to start the code acceptance process, correct?

J

Am Do., 14. Feb. 2019 um 08:03 Uhr schrieb Willem Jiang <
willem.ji...@gmail.com>:

> We need to do the IP Clearance[1] first. To be honest, it's my first
> time to go through this process.
> We could take the others project path[2] as an example.
>
> [1]https://incubator.apache.org/guides/ip_clearance.html
> [2]http://incubator.apache.org/ip-clearance/
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Thu, Feb 14, 2019 at 10:48 AM 申远  wrote:
> >
> > According to dependency in package.json
> > <https://github.com/weexteam/weex-toolkit/blob/master/package.json>, I
> > don't think there is a IP issue. Maybe Dan could do a double check.
> >
> > BTW, what's the standard procedure if we want to move a repo to Apache
> > project ?
> >
> > Best Regards,
> > YorkShen
> >
> > 申远
> >
> >
> > Willem Jiang  于2019年2月13日周三 下午2:35写道：
> >
> > > If we want to move the repo, we need to address the SGA problem first.
> > > It has nothing to do with the committer right yet, we just need to
> > > make sure the IP issue is resolved before moving forward.
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Wed, Feb 13, 2019 at 11:41 AM Dan  wrote:
> > > >
> > > > Hi Jan,
> > > >
> > > > > Definitely include INFRA in the move of the repositories, they can
> > > > probably
> > > > make it a normal move/transfer of a GitHub repository between two
> orgs,
> > > so
> > > > not only the stars, but also issues, PRs etc are moved and the old
> URLs
> > > are
> > > > automatically forwarded. The only thing one has to do manually, is to
> > > > update the user/repository name if you use it in the code somewhere
> - but
> > > > probably also not _right now_, but whenever you have the time to do
> so -
> > > as
> > > > all the links, repository clones etc. should be forwarded.
> > > >
> > > > Did you mean to transfer the `weexteam/weex-toolkit` project to the
> link
> > > > like `apache/incubator-weex-tools`?  This seems to be a relatively
> > > low-cost
> > > > method at present. I only need someone to help me check the
> > > specifications
> > > > of the project.
> > > >
> > > > By the way, after that, there will be three git repo on the
> > > > `apache/weex` team, like `apache/incubator-weex`, `apache/incubator-
> > > > weex-site` and `apache/incubator-weex-tools`,  I don't know that's
> ok or
> > > > not, just tell the situation.
> > > >
> > > > I am not a committer for the apache/weex now, also I am not very
> familiar
> > > > with the apache process.
> > > >
> > > > Maybe someone can list what we need to do next?
> > > >
> > > > Thanks,
> > > > Dan
> > > >
> > > > Jan Piotrowski  于2019年2月12日周二 下午9:20写道：
> > > >
> > > > > If I may give some input here as well:
> > > > > Definitely include INFRA in the move of the repositories, they can
> > > probably
> > > > > make it a normal move/transfer of a GitHub repository between two
> > > orgs, so
> > > > > not only the stars, but also issues, PRs etc are moved and the old
> > > URLs are
> > > > > automatically forwarded. The only thing one has to do manually, is
> to
> > > > > update the user/repository name if you use it in the code
> somewhere -
> > > but
> > > > > probably also not _right now_, but whenever you have the time to
> do so
> >

Re: Weex, Apache and outside code

[Jan Piotrowski]

If I may give some input here as well:
Definitely include INFRA in the move of the repositories, they can probably
make it a normal move/transfer of a GitHub repository between two orgs, so
not only the stars, but also issues, PRs etc are moved and the old URLs are
automatically forwarded. The only thing one has to do manually, is to
update the user/repository name if you use it in the code somewhere - but
probably also not _right now_, but whenever you have the time to do so - as
all the links, repository clones etc. should be forwarded.

-J

Am Di., 12. Feb. 2019 um 13:43 Uhr schrieb Willem Jiang <
willem.ji...@gmail.com>:

> I don't aware the git repository transfer issue, if it related to the
> snapshot release, I think we can work out a solution for it.
> If it relates to SGA things, I think we need to dig more detail about that.
> Anyway, I'd happy to help you to do the code transfer work.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Tue, Feb 12, 2019 at 5:33 PM Myrle Krantz  wrote:
> >
> > Hey Dan,
> >
> > On Tue, Feb 12, 2019 at 4:46 AM Dan  wrote:
> >
> > > Hi, Myrle
> > >
> > > Sorry for the delay getting back to you.
> > >
> >
> > No problem.  I hope you enjoyed Chinese New Year!
> >
> > > Normally repo history can also be imported to an Apache repository.  Is
> > > that what you mean by warehouse?
> > >
> > > The `warehouse` is caused by incorrect translation, it should means git
> > > repo, don't mind. I know there has a way to import history into Apache
> > > repo, but based on the experience of the last weex repo migration, some
> > > developers will be very uncomfortable with this change, and may even
> feel
> > > that this is an unstable performance. At the same time, some developers
> > > will still feedback new project issues in the old project. We need to
> > > conduct reasonable and effective guidance, I think this is not a matter
> > > that can be decided immediately, I will initiate a vote on this matter.
> > >
> >
> > I'm sorry to hear that things didn't go smoothly in the first transfer.
> I
> > don't know the details, since I wasn't mentoring then.
> >
> > As I understand it, Infra can also do a repository move, which would
> bring
> > over all the stars, etc.  Would you like me to ask?
> >
> > Best Regards,
> > Myrle
>

Re: Weex, Apache and outside code

[Jan Piotrowski]

Good point re the subdomain, I didn't think about that. Best open an
issue at https://issues.apache.org/jira/projects/INFRA/issues and ask
if this is possible and how.

Have a nice holiday you all!

-J

Am Fr., 1. Feb. 2019 um 14:40 Uhr schrieb York Shen :
>
> > Who goes ahead and does the first version as a PR?
> May be Dan could the job?
>
> BTW, as Chinese lunar year is coming, some of weex’s committers & contributor 
> (include Dan and me) may take a vacation for one or two weeks. We may finish 
> the document work when vacation is over.
>
> > Thanks for the explanation of the domain. Confusing.
> > draft.weex.apache.org <http://draft.weex.apache.org/> would work and 
> > communicate much better.
> Actually, I couldn’t find a way to deploy to draft.weex.apache.org 
> <http://draft.weex.apache.org/>. It seems like Gitpubsub will deploy the 
> asf-site branch of incubator-weex-site 
> <https://github.com/apache/incubator-weex-site/> to weex.apache.org 
> <http://weex.apache.org/> automatically. In order to have more fine control 
> when deploying, we use another domain called https://weex.io 
> <https://weex.io/> .
>
> If there is a way to deploy website to draft.weex.apache.org 
> <http://draft.weex.apache.org/> , I’d really like to learn. Any help or 
> advise on the domain issue?
>
>
> > 在 2019年2月1日，19:55，Jan Piotrowski  写道：
> >
> >> I totally agree with you. I think the first step is listing all the 
> >> corresponding toolchain and their relationship between weex in the 
> >> document clearly(e.g. xxx is official, and  is third party plugin). 
> >> Moving weex-toolkit to Apache repos will be a huge according to my 
> >> understanding, maybe we should talk this later in another thread after we 
> >> finished the document work first.
> >
> > Awesome. Who goes ahead and does the first version as a PR? I am happy
> > to jump in when something is up and give feedback on how to improve
> > the list - but you are probably _much_ faster in collecting the
> > relevant repos and giving them a bit of context.
> >
> >> weex.io is based on ...
> >
> > Thanks for the explanation of the domain. Confusing.
> > draft.weex.apache.org would work and communicate much better.
> >
> > You should check with Apache Incubator first if weex.io as a domain
> > will work. Cordova is officially cordova.apache.org although we have
> > cordova.io as a short domain. This might be required for Apache
> > projects - and actually makes sense from a branding perspective!
> >
> > -J
> >
> >
> > Am Fr., 1. Feb. 2019 um 12:19 Uhr schrieb York Shen :
> >>
> >> Hi, Jan.
> >>
> >>> that are _currently_ connected to Weex and list them on a page on the
> >>> documentation. Just a link to the repo and a short description what it
> >>> does ("weex-toolkit - A CLI for creating and managing Weex based
> >>> applications", "weex-pack - Scripts to run and build Weex apps for
> >>> different platforms (used by weex-toolkit)" etc). That would give a
> >>> first overview and help to decide which should be migrated when.
> >>
> >> I totally agree with you. I think the first step is listing all the 
> >> corresponding toolchain and their relationship between weex in the 
> >> document clearly(e.g. xxx is official, and  is third party plugin). 
> >> Moving weex-toolkit to Apache repos will be a huge according to my 
> >> understanding, maybe we should talk this later in another thread after we 
> >> finished the document work first.
> >>
> >>
> >>> PS: What is https://weex.io/ <https://weex.io/> based on?
> >> https://weex.io <https://weex.io/> is based on the draft branch of 
> >> https://github.com/apache/incubator-weex-site 
> >> <https://github.com/apache/incubator-weex-site> , other website like 
> >> http://weex.incubator.apache.org <http://weex.incubator.apache.org/> and 
> >> https://weex-project.io <https://weex-project.io/> are based on the master 
> >> branch. We are trying to rewrite weex's website and host it on 
> >> https://weex.io <https://weex.io/> . Other URL will be redirect to 
> >> https://weex.io <https://weex.io/> when all the job are done. You may 
> >> think https://weex.io <https://weex.io/> is in beta stage and will be the 
> >> weex’s website. We would like to publish https://weex.io 
> >> <https://weex.io/> on Weex conf 2019. Ref this 
> >

Re: Weex, Apache and outside code

[Jan Piotrowski]

> I totally agree with you. I think the first step is listing all the 
> corresponding toolchain and their relationship between weex in the document 
> clearly(e.g. xxx is official, and  is third party plugin). Moving 
> weex-toolkit to Apache repos will be a huge according to my understanding, 
> maybe we should talk this later in another thread after we finished the 
> document work first.

Awesome. Who goes ahead and does the first version as a PR? I am happy
to jump in when something is up and give feedback on how to improve
the list - but you are probably _much_ faster in collecting the
relevant repos and giving them a bit of context.

> weex.io is based on ...

Thanks for the explanation of the domain. Confusing.
draft.weex.apache.org would work and communicate much better.

You should check with Apache Incubator first if weex.io as a domain
will work. Cordova is officially cordova.apache.org although we have
cordova.io as a short domain. This might be required for Apache
projects - and actually makes sense from a branding perspective!

-J


Am Fr., 1. Feb. 2019 um 12:19 Uhr schrieb York Shen :
>
> Hi, Jan.
>
> > that are _currently_ connected to Weex and list them on a page on the
> > documentation. Just a link to the repo and a short description what it
> > does ("weex-toolkit - A CLI for creating and managing Weex based
> > applications", "weex-pack - Scripts to run and build Weex apps for
> > different platforms (used by weex-toolkit)" etc). That would give a
> > first overview and help to decide which should be migrated when.
>
> I totally agree with you. I think the first step is listing all the 
> corresponding toolchain and their relationship between weex in the document 
> clearly(e.g. xxx is official, and  is third party plugin). Moving 
> weex-toolkit to Apache repos will be a huge according to my understanding, 
> maybe we should talk this later in another thread after we finished the 
> document work first.
>
>
> > PS: What is https://weex.io/ <https://weex.io/> based on?
> https://weex.io <https://weex.io/> is based on the draft branch of 
> https://github.com/apache/incubator-weex-site 
> <https://github.com/apache/incubator-weex-site> , other website like 
> http://weex.incubator.apache.org <http://weex.incubator.apache.org/> and 
> https://weex-project.io <https://weex-project.io/> are based on the master 
> branch. We are trying to rewrite weex's website and host it on 
> https://weex.io <https://weex.io/> . Other URL will be redirect to 
> https://weex.io <https://weex.io/> when all the job are done. You may think 
> https://weex.io <https://weex.io/> is in beta stage and will be the weex’s 
> website. We would like to publish https://weex.io <https://weex.io/> on Weex 
> conf 2019. Ref this <http://weex-project.io/weexConf2018/index-en.html> to 
> have a deeper view of weex conf 2018.
>
> Best Regards,
> York Shen
>
> 申远
>
> > 在 2019年2月1日，18:30，Jan Piotrowski  写道：
> >
> > Hi,
> >
> > awesome discussion I started here. Really like your responses.
> >
> > To add some context on the "unreleased code" discussion: For Apache
> > Cordova we have official, voted releases, but all tooling can also be
> > installed from git directly (`npm install -g cordova` vs. `npm install
> > -g https://github.com/apache/cordova-cli` or even `git clone
> > https://github.com/apache/cordova-cli` with `npm link`). We also have
> > a cronjob that creates nightly builds and pushes them to npm, so those
> > can be tested. That way normal users do use the normal, stable, voted
> > Apache releases - and maintainers and more active users can still use
> > the newest stuff. For Apache it is only important that only the
> > official releases are marketed to users, because only those have the
> > "seal of approval" from the PMC by voting.
> >
> > Maybe a freat first step would be to identify all the repositories
> > that are _currently_ connected to Weex and list them on a page on the
> > documentation. Just a link to the repo and a short description what it
> > does ("weex-toolkit - A CLI for creating and managing Weex based
> > applications", "weex-pack - Scripts to run and build Weex apps for
> > different platforms (used by weex-toolkit)" etc). That would give a
> > first overview and help to decide which should be migrated when.
> >
> > Thanks to Dan for explaining a bit about _why_ stuff is how it is. As
> > usual, it can be summarized as "it just grew that way" and that is
> > perfectly fine. One of the benefits of being an Apache project is tha

Re: Weex, Apache and outside code

[Jan Piotrowski]

Hi,

awesome discussion I started here. Really like your responses.

To add some context on the "unreleased code" discussion: For Apache
Cordova we have official, voted releases, but all tooling can also be
installed from git directly (`npm install -g cordova` vs. `npm install
-g https://github.com/apache/cordova-cli` or even `git clone
https://github.com/apache/cordova-cli` with `npm link`). We also have
a cronjob that creates nightly builds and pushes them to npm, so those
can be tested. That way normal users do use the normal, stable, voted
Apache releases - and maintainers and more active users can still use
the newest stuff. For Apache it is only important that only the
official releases are marketed to users, because only those have the
"seal of approval" from the PMC by voting.

Maybe a freat first step would be to identify all the repositories
that are _currently_ connected to Weex and list them on a page on the
documentation. Just a link to the repo and a short description what it
does ("weex-toolkit - A CLI for creating and managing Weex based
applications", "weex-pack - Scripts to run and build Weex apps for
different platforms (used by weex-toolkit)" etc). That would give a
first overview and help to decide which should be migrated when.

Thanks to Dan for explaining a bit about _why_ stuff is how it is. As
usual, it can be summarized as "it just grew that way" and that is
perfectly fine. One of the benefits of being an Apache project is that
the rules force a bit of clarity here and make you clean up, so users
don't send emails like the one I did. I am happy you are all moving
forward here instead of just blocking. I think this could be really
great for the Weex project.

Best,
Jan

PS: What is https://weex.io/ based on?


Am Fr., 1. Feb. 2019 um 11:13 Uhr schrieb Adam Feng :
>
> Hi, all
>
> I suppose it's not just about the workload for Dan， it’s what do we think of 
> the project.
>
> At first, Weex has no toolkits,  and thanks for Dan and other maintainer’s 
> work, Weex has a good tool for starting guide,  and we link to it in our 
> official site .
>
> Maybe there should be a more in-depth discussion about whether toolkit should 
> be a part of Apache Weex， in my opinion,  it should be but is not yet,  at 
> present Weex focus on “framework” and focus on how to be integrated into 
> mobile environment ,  which is used without toolkit,  toolkit is a pluses but 
> not a requirement.
>
> Dan is a strong developer and develop toolkit almost by himself,  but we need 
> more discussions and interactions between Weex repo and toolkit repo,  not 
> only just a link and a part of document. I’m looking forward to the 
> “official” toolkit.
>
>  Other opinions are really important,  maybe I’m too “cleanliness”.
>
>
>
> Thanks.
> Adam Feng
> 在 2019年2月1日 +0800 PM5:29，Dan ，写道：
> > Hi Myrle,
> >
> > At present, I can think of the difficulties mainly in the following aspects:
> >
> > 1. I'm not very understanding of apache's workflow at present, and also I'm
> > not a committer for Apache weex now, I should be voted to be a committer
> > firstly.
> > 2. The migration of the warehouse may cause some historical issues to
> > continue to track, the new repo will start from 0 (that's no bad, but a big
> > change).
> > 3. I need to re-adjust my code and follow the apache approach, which also
> > has a certain cost for me, and now I was the only one who works on the
> > weex toolchain.
> >
> > Maybe this issue can be resolved, but I'm not sure how much time I need to
> > complete this thing.
> >
> > I look forward to more comments and discussions to get this matter going.
> >
> > Thanks.
> > Dan
> >
> > Myrle Krantz  于2019年2月1日周五 下午4:32写道：
> >
> > > Hello Dan,
> > >
> > > One answer inline below.
> > >
> > > On Fri, Feb 1, 2019 at 8:07 AM Dan  wrote:
> > >
> > > > > About move weex-toolkit project into the Apache repo.
> > > >
> > > > For now, this is a little difficult and also inconvenient thing cause 
> > > > the
> > > > current 2.0 tools are in a state of rapid iteration, and I also hope to
> > > > get
> > > > the user's usage from the tool, this may not be allowed by apache, I
> > > > prefer
> > > > to develop these tools as a third-party developer, it should be ok to
> > > > remind users in the documentation that it's not part of Apache
> > >
> > >
> > > This is a common misconception. Code does not have to be complete to be
> > > developed at Apache. Rapid prototyping and user feedback are important
> > > parts of all software development whether at Apache or elsewhere. For an
> > > example of a project currently doing this in incubation see PLC4X.
> > >
> > > Can you explain in more detail what makes development within an Apache
> > > GitHub repository difficult for you? Perhaps it’s an issue that can be
> > > resolved?
> > >
> > > It’s important that the Weex PPMC resolves this. A project which is split
> > > in this way cannot be effectively governed by the Weex PMC. The governance
> > > imbalance 

Re: Weex, Apache and outside code

[Jan Piotrowski]

github.com/apache/incubator-weex-site 
> >>> <https://github.com/apache/incubator-weex-site>>  is the repos for weex’s 
> >>> website as you mentioned.
> >>> The repo for weex is  https://github.com/apache/incubator-weex 
> >>> <https://github.com/apache/incubator-weex> 
> >>> <https://github.com/apache/incubator-weex 
> >>> <https://github.com/apache/incubator-weex>>, from where weex community 
> >>> generates apache release.
> >>> All the other repos is not officially belong to weex, though some of are 
> >>> useful tools for debug, development purpose. They are just useful tools, 
> >>> one can using weex framework without these tools with no problem. I will 
> >>> consider these tools as useful plugins, and there are perhaps tens of 
> >>> such plugins, so they are not under Apache repositories.
> >>> 
> >>> 
> >>> 2. All website you listed is coming 
> >>> https://github.com/apache/incubator-weex-site 
> >>> <https://github.com/apache/incubator-weex-site> 
> >>> <https://github.com/apache/incubator-weex-site 
> >>> <https://github.com/apache/incubator-weex-site>> . As there are many Weex 
> >>> users coming from China and the GFW is a huge problem for them, so we 
> >>> create several website for users from China to have the right access. You 
> >>> can choose whatever you want, as the three websites are all the same.
> >>> 
> >>> 3. Feel free to ask anything about weex, I am glad to answer these 
> >>> questions.
> >>> 
> >>> Best Regards,
> >>> York Shen
> >>> 
> >>> 申远
> >>> 
> >>>> 在 2019年1月31日，20:31，Jan Piotrowski  >>>> <mailto:piotrow...@gmail.com>> 写道：
> >>>> 
> >>>> Hey,
> >>>> 
> >>>> I recently spent some time looking into Weex (I am a PMC member of
> >>>> committer to Apache Cordova and was interested how you do things). But I
> >>>> quickly noticed, that although Weex being an Apache Incubator project, 
> >>>> most
> >>>> of the code of Weex seems to come from an outside Github organization. 
> >>>> This
> >>>> left me a bit confused what is going on, and where what code is coming 
> >>>> from
> >>>> and what it is used for.
> >>>> 
> >>>> There are only 2 Apache (Incubator) repositories for Weex:
> >>>> https://github.com/apache/incubator-weex 
> >>>> <https://github.com/apache/incubator-weex>
> >>>> https://github.com/apache/incubator-weex-site
> >>>> 
> >>>> The main repository https://github.com/apache/incubator-weex quickly 
> >>>> links
> >>>> me to https://github.com/weexteam/weex-toolkit which seems to be a CLI
> >>>> (toolkit = CLI?) to create and build Weex based apps. Its npm 
> >>>> dependencies
> >>>> are pretty light, but it seems to download many more code via
> >>>> https://github.com/weexteam/xtoolkit anyway and cache it with some custom
> >>>> mechanism, like e.g. https://github.com/weexteam/weex-pack that seems to
> >>>> contain the code to create, run, build native apps.
> >>>> 
> >>>> Is this redirection and inclusion of outside code intentional?
> >>>> Is this temporary or meant to be permanent?
> >>>> 
> >>>> There are also many more repositories at https://github.com/weexteam 
> >>>> that I
> >>>> have no idea what they are used for.
> >>>> 
> >>>> (That being said, the guide at http://weex.apache.org/guide/ is really 
> >>>> good
> >>>> and gives a very clear picture what steps need to be taken to developer a
> >>>> Weex app - it just all breaks down if you look behind the curtain and try
> >>>> to understand where all the code comes from and what is going on a level
> >>>> deeper.)
> >>>> 
> >>>> The website also seems to be available under several domains:
> >>>> http://weex.incubator.apache.org
> >>>> https://weex.apache.org
> >>>> https://weex-project.io
> >>>> Do these all host the same content from
> >>>> https://github.com/apache/incubator-weex-site? Or are those different
> >>>> things?
> >>>> 
> >>>> Best,
> >>>> Jan
> >>> 
> > 
> 
> 

Weex, Apache and outside code

[Jan Piotrowski]

Hey,

I recently spent some time looking into Weex (I am a PMC member of
committer to Apache Cordova and was interested how you do things). But I
quickly noticed, that although Weex being an Apache Incubator project, most
of the code of Weex seems to come from an outside Github organization. This
left me a bit confused what is going on, and where what code is coming from
and what it is used for.

There are only 2 Apache (Incubator) repositories for Weex:
https://github.com/apache/incubator-weex
https://github.com/apache/incubator-weex-site

The main repository https://github.com/apache/incubator-weex quickly links
me to https://github.com/weexteam/weex-toolkit which seems to be a CLI
(toolkit = CLI?) to create and build Weex based apps. Its npm dependencies
are pretty light, but it seems to download many more code via
https://github.com/weexteam/xtoolkit anyway and cache it with some custom
mechanism, like e.g. https://github.com/weexteam/weex-pack that seems to
contain the code to create, run, build native apps.

Is this redirection and inclusion of outside code intentional?
Is this temporary or meant to be permanent?

There are also many more repositories at https://github.com/weexteam that I
have no idea what they are used for.

(That being said, the guide at http://weex.apache.org/guide/ is really good
and gives a very clear picture what steps need to be taken to developer a
Weex app - it just all breaks down if you look behind the curtain and try
to understand where all the code comes from and what is going on a level
deeper.)

The website also seems to be available under several domains:
http://weex.incubator.apache.org
https://weex.apache.org
https://weex-project.io
Do these all host the same content from
https://github.com/apache/incubator-weex-site? Or are those different
things?

Best,
Jan