Re: Concerned about the LGPL dependency in Webkit

[Myrle Krantz]

Thanks YorkShen,

This is an answer I can live with.  Let's see if legal can live with it
too.  I've pinged the ticket you made.  Let me see if I can get it
unblocked.

Best,
Myrle

On Mon, Jul 22, 2019 at 9:30 AM 申远  wrote:

> >
> > The source I'm referring to says otherwise[1], but you may have a better
> > source.
>
> After carefully review License File in Webkit source code [1], I didn't
> find any fact could support the idea that JavaScriptCore is under LGPL as
> there is no standalone LICENSE file for JavaScriptCore. *So I think that
> JavaScriptCore is also under dual-license as Webkit does.*
>
> This would still be OK if, at runtime, another implementation could be used
> > in place of this LGPL component.
>
>  There is another implementation for JavaScript interpretator called V8 ,
> which is under BSD License [2]. But users must write some extra code to
> switch to V8 as the header files between V8 and JavaScriptCore are not
> compatible. I'm not sure whether we could call it runtime replaceable.
>
> [1]
>
> https://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.17.4/Source/JavaScriptCore/
> [2] https://chromium.googlesource.com/v8/v8.git/+/master/LICENSE
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Myrle Krantz  于2019年7月19日周五 下午7:57写道：
>
> > On Thu, Jul 18, 2019 at 5:22 AM York Shen  wrote:
> >
> > > Just some further information about what @ddy199726 said.
> > >
> > > The relationship between weex and JavaScriptCore is similar to the
> > > relationship between any Java Project and JDK.
> > >
> > > If one want to run a Java program, he/she must have a JDK/JRE to
> > interpret
> > > Java byte code.
> > > If one want to run a Weex program, he/she must have a JavaScript
> > > interpretator to interpret JavaScript. Here we choose JavaScriptCore.
> > >
> >
> > If it is the case that this can be done with any JavaScript interpreter,
> > then you are working within the Apache licensing policies.  You're doing
> > great.  Thank you for answering my questions.
> >
> > It is a real pleasure working with you York Shen and ddy!
> > Myrle
> >
>

Re: Concerned about the LGPL dependency in Webkit

[Myrle Krantz]

On Thu, Jul 18, 2019 at 5:22 AM York Shen  wrote:

> Just some further information about what @ddy199726 said.
>
> The relationship between weex and JavaScriptCore is similar to the
> relationship between any Java Project and JDK.
>
> If one want to run a Java program, he/she must have a JDK/JRE to interpret
> Java byte code.
> If one want to run a Weex program, he/she must have a JavaScript
> interpretator to interpret JavaScript. Here we choose JavaScriptCore.
>

If it is the case that this can be done with any JavaScript interpreter,
then you are working within the Apache licensing policies.  You're doing
great.  Thank you for answering my questions.

It is a real pleasure working with you York Shen and ddy!
Myrle

Re: Concerned about the LGPL dependency in Webkit

[Myrle Krantz]

Hello dyy,

Thank you for your reply.  It's entirely possible that my understanding
incomplete and that you do not need to change anything.  Please let me ask
a couple of questions:

On Wed, Jul 17, 2019 at 9:17 AM  wrote:

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

I believe this is the point at which my understanding diverges from what
you have written.  I believe that JavaScriptCore is not BSD licensed, but
rather LGPL licensed (1).  This means that Weex is directly dependent on
LGPL code and thus, indirectly, any source dependent on Weex is dependent
on LGPL.

This would still be OK if, at runtime, another implementation could be used
in place of this LGPL component.  (much like OpenJDK can be used)  My
current understanding is that it cannot be.  I may be misunderstanding.


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

Acknowledged.


>
> you can checkout the source code from here
> https://weex.apache.org/download/download.html#_0-26-0 <
> https://weex.apache.org/download/download.html#_0-26-0>
> javaScriptCore's api directory is
> weex_core/Source/include/JavaScriptCore/API
>
> Weex's logic that use JavaScriptCore's api is here
> weex_core/Source/js_runtime
>

I didn't go through all the code, but I looked at some of it.  It's quite
lovely.  You make me miss programming C++ : o)


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

The source I'm referring to says otherwise[1], but you may have a better
source.

Best,
Myrle

[1] "WebKit is available under a BSD-form license[11] with the exception of
the WebCore and JavaScriptCore components, which are available under the
GNU Lesser General Public License. As of March 7, 2013, WebKit is a
trademark of Apple, registered with the U.S. Patent and Trademark
Office.[12] "  https://en.wikipedia.org/wiki/WebKit

Concerned about the LGPL dependency in Webkit

[Myrle Krantz]

Hey all,

First of all: congratulations on your recent release!

I wanted to circle back to this to make sure it gets resolved before the
next release.

First a summary of what has happened as I see it.  If my summary is
incorrect, please let me know:
* At some point in the past Weex introduced a run-time and a compile-time
dependency to Webkit.  When adding the Webkit *.h to the repo, the correct
license of those files was accidentally overwritten.
* More recently, this mistake was discovered and a license review of Webkit
as a dependency was made in which it was realized that Webkit:
"As Webkit is under dual license, and it's almost impossible for us to
figure out whether there is an function call chain like
Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL.apiD. I'd like to
know our proposed change is enough to fix the Category X dependency."
(
https://lists.apache.org/thread.html/babe010a7814d4cf3d3d92588bee9dd22277b610daf83733d2622c91@%3Cgeneral.incubator.apache.org%3E
)
* The question of whether Webkit could release like this was raised to the
incubator and then to legal.
* Despite the lack of resolution to this question, Weex was still allowed
to make it's most recent release, because Weex is still in incubation.

While reviewing the release, it became clear to me that Weex is including
WebKit for it's JavaScriptCore.  Within WebKit, JavaScriptCore is
LGPL-licensed.  So it is likely that your functional call chains will
include LGPL-licensed code (after all that's the code you're including
WebKit for).

Is there an alternative implementation of JavaScriptCore that a user could
use in place of the LGPL-licensed portions of WebKit?

Best Regards,
Myrle

Re: Podling Report Reminder - July 2019

[Myrle Krantz]

Hey YorkShen,

I use Confluence.  Weex does have a confluence space:
https://cwiki.apache.org/confluence/display/WEEX

Best,
Myrle

On Wed, Jul 3, 2019 at 9:23 AM York Shen  wrote:

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

Re: Podling Report Reminder - July 2019

[Myrle Krantz]

Hey all,

I've signed off with the following comment:

"Weex is doing an excellent job of identifying their own  issues, and
seeking solutions in the broader foundation.  I concur that they are
nearing graduation."

Best,
Myrle

On Mon, Jul 1, 2019 at 9:04 AM 申远  wrote:

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

Re: [DISCUSS] Release Weex 0.26

[Myrle Krantz]

Hey York Shen,

Cut the release please.  I'll stand up for you in the incubator if there's
a problem.  You've already made releases containing webkit, and you are
still in incubation.  You are aware of the problem and working with the
relevant parties.  It's not ideal, but we live in an imperfect world.  It
is good enough.

Best Regards,
Myrle

On Fri, Jun 28, 2019 at 12:04 PM 王乾元  wrote:

> I will manage the releasing of 0.26. Thanks YorkShen for his excellent work
> for Weex community.
>
> On Fri, Jun 28, 2019 at 4:25 PM York Shen  wrote:
>
> > Hi, theere
> >
> > As Google will ban Android Apps without 64bit support in Google Play from
> > August 1st[1], we need to publish next release which including Android
> > 64bit supports ASAP to give our users enough time to upgrade. The only
> > thing that blocks us from next release is Weex Android bundled Webkit in
> > its convenience binary. I am still try to get an exemption[2] from
> > Incubator only for our next release. Until now, there are no response in
> > this thread.
> >
> > As you might see, I am busying fixing license, package name and IP issues
> > around Weex these days. I’m really appreciated that if someone on the
> > mailing list would volunteer to be release manager. There is nothing need
> > to do for release manager until we got response from general@incubator.
> >
> > BTW, I have already checked out release/0.26 [3] as the release branch
> and
> > the release document is here[4]. As I am a little overloaded these days,
> I
> > only wrote down the release document of English version. Feel free to ask
> > me if there is something missed in the release document.
> >
> > [1]
> https://developer.android.com/distribute/best-practices/develop/64-bit
> > 
> > [2]
> >
> https://lists.apache.org/thread.html/babe010a7814d4cf3d3d92588bee9dd22277b610daf83733d2622c91@%3Cgeneral.incubator.apache.org%3E
> > <
> >
> https://lists.apache.org/thread.html/babe010a7814d4cf3d3d92588bee9dd22277b610daf83733d2622c91@%3Cgeneral.incubator.apache.org%3E
> > >
> > [3] https://github.com/apache/incubator-weex/tree/release/0.26 <
> > https://github.com/apache/incubator-weex/tree/release/0.26>
> > [4] https://weex.apache.org/community/release-procedure.html <
> > https://weex.apache.org/community/release-procedure.html>
> >
> > Best Regards,
> > York Shen
> >
> > 申远
> >
> >
>

Re: [DISCUSS] Package name in Java code

[Myrle Krantz]

There are cases in which packages don't get renamed upon acceptance to the
incubator, precisely because of the backwards compatibility question.  An
example of a TLP which doesn't use "apache" in its namespaces is groovy (
https://github.com/apache/groovy).  But it *usually* isn't a company name
there instead.

Putting a company name there might make it more difficult to attract
contributors who don't work for alibaba.  They might believe that only
employees of alibaba are welcome.

What have communicated you communicated to your current users in the past
about the stability of your APIs?  Jan is right that you could,
theoretically replace your alibaba classes with shells to redirect,.  But
depending on the surface area of your API, this could be a very large
amount of work, and the result might *still* not be completely backwards
compatible.  If you are going to change the package names, it is good
practice to at least indicate with semantic versioning or some other
mechanism that the new version isn't backwards compatible (you probably
already know that).

One possibility is to just copy *everything* and let it exist under two
package names.  Then you mark the classes in the alibaba packages as
deprecated, and don't make future enhancements to those classes.  Users
will be incentivized to change to the new packages, but not forced to.  You
can go a few cycles like that until you believe most users have adjusted
their code, and then delete the alibaba classes.  Occasional backwards
incompatible changes made in a controlled, well-communicated manner do not
have to be deadly sins for every project.  You will have to decide what you
feel is appropriate for your project.  It *is* important that you
communicate to your users how you intend to handle situations like this
though.  People find it easier to accept things when they are not surprised.

So, the first question is: what do you think is right for your project?

Best Regards,
Myrle

On Fri, Jun 28, 2019 at 9:58 AM Jan Piotrowski  wrote:

> As a new user, I would probably be confused to find a
> `com.taobao.xxx/com.alibaba.xxx` package name in an Apache Software
> Foundation project.
>
> As a a developer, I have no idea how to rename a Java package in a
> backwards compatible way though. Proxy classes maybe that just import
> and "redirect" to the new packages?
>
> I don't know if there were earlier Java/Android projects added to
> Apache after they already had packages names in use. Might be worth
> asking on the incubator mailing list, maybe someone can remember
> something.
>
> Best,
> Jan
>
> Am Fr., 28. Juni 2019 um 04:45 Uhr schrieb York Shen  >:
> >
> > Hi, community
> >
> > As Jan pointed out[1], the Android package name in Weex is
> com.taobao.xxx/com.alibaba.xxx .
> >
> > I’d like to know whether there are rules about package name in ASF’s
> project must starts with org.apache.xxx . If so, I’d like to know if there
> is a zero-cost/low-cost upgrading method for renaming package names. It’s
> easy to rename all Android package to org.apache.xxx , but users would
> probably have a lot of complains about this renaming, which should cause
> compiling error when our users are building Android App with latest Weex.
> >
> > BTW: This is only for Android(Java Code), as there is no such
> concept(Package Name) in C++/C/Objective C/JavaScript.
> >
> > [1] https://github.com/apache/incubator-weex/issues/2148 <
> https://github.com/apache/incubator-weex/issues/2148>
> > [2]
> https://github.com/apache/incubator-weex/blob/master/android/sdk/src/main/java/com/taobao/weex/WXSDKEngine.java
> <
> https://github.com/apache/incubator-weex/blob/master/android/sdk/src/main/java/com/taobao/weex/WXSDKEngine.java
> >
> >
> > Best Regards,
> > York Shen
> >
> > 申远
> >
>

Re: Why is the error code the same when the error is different, weex version is 0.24.0

[Myrle Krantz]

BTW, your English is perfect.

: o),
Myrle

On Thu, Jun 20, 2019 at 8:26 AM ? ??  wrote:

> Hi everyone,
> I found that in the 0.24 version, different errors use the same error
> code. e.g.
>
> WX_DEGRAD_ERR_INSTANCE_CREATE_FAILED("-1001", "degradeToH5|createInstance
> fail|wx_create_instance_error",ErrorType.DEGRAD_ERROR,ErrorGroup.NATIVE)
> and
>
> WX_JS_FRAMEWORK_REINIT_SUCCESS("-1001", "js framework reinit
> success",ErrorType.NATIVE_ERROR,ErrorGroup.NATIVE)
>
> Both error codes are “-1001”, but the semantics are reversed, one is
> success and the other is failure.
> This problem exists in several error codes:-1000, -1001, -1002, -1003,
> -1004, -1005, -1006, -2299.
> This design can be confusing.
>
> BTW,forgive my English ability, my first language is Chinese ;)
>

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

[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: [ANNOUNCEMENT] The minute of Weex Meetup - June 10th, 2019

[Myrle Krantz]

On Mon, Jun 10, 2019 at 3:01 PM York Shen  wrote:

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

If it is possible for your end user to replace your runtime dependencies
with component which is ALv2-licensed (or compatible), then that is an
allowed dependency.  Otherwise, unfortunately, it is not.  The issue is
that we at the ASF want to keep the downstream consumers of our code "safe"
from viral licenses.  While it is true that LGPL is less viral than GPL, it
is nonetheless a so-called Category X license.  From your text above, I
suspect that this is not an allowed dependency.

https://apache.org/legal/resolved.html#category-x

What makes GLIC different is that there are other c-runtime implementations
out there, so users of our project aren't required to use that particular
implementation.  (JPA -> OpenJPA/Hibernate is another example of an
application of this principle.)

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?

Best,
Myrle

Fwd: Missing podling logos

[Myrle Krantz]

Did y'all want Weex laptop stickers?

If so, see the forwarded e-mail below.

: o),
Myrle

(I currently only have one sticker on my laptop: an Apache feather.  But if
Weex prints stickers, I hereby commit to adding the Weex sticker to my
laptop at the next conference I see it.)

-- Forwarded message -
From: Justin Mclean 
Date: Sun, Jun 2, 2019 at 4:37 AM
Subject: Re: Missing podling logos
To: 


Hi,

It’s good to see some podling have added their logos, but we’re still
missing a few.

Missing logo are:
amaterasu
annotator
batchee
brpc
datasketches
dlab
flagon
gobblin
hudi
omid
pinot
s2graph
samoa
sdap
tuweni
tvm
weex
zipkin

With some conferences coming up there's going to be stickers made and we'll
need your logo there for that to happen.

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

Re: [ANNOUNCEMENT] Weex 0.24.0 Released

[Myrle Krantz]

Hi YorkShen,

On Wed, May 29, 2019 at 3:29 PM 申远  wrote:

> >
> > What's more: a convenience binary shouldn't contain the compilation of
> > anything not in the code release.  It sounds like what you're publishing
> > there isn't actually Apache Weex, but "based on Apache Weex".
>
>
> Well, what happens here is that there are two libraries in the git repo of
> incubator-weex, namely weex_sdk and weex playground. Apache Weex release
> only contains weex_sdk, and we publish weex_sdk as a convenience binary
> after the Apache Release as well. Then we used to publish weex playground
> to ios App Store in the name of Taobao(China) as we need an apple
> developer/enterprise account to do so.
>

You'll need to send weex playground through your voting and release process
as a source code release too, otherwise you can't call the binary release
Weex to the rest of the world.  Since you're already doing releases for
weex_sdk, though, you know how to do this.  It's not uncommon for a single
project to release multiple code bases, sometimes on inconsistent
schedules.  Although it might be a challenge with only one release manager.


>
> As INFRA[1] owned an Apple developer account,


Thank you, I learned something.


> I think we could separate
> weex_sdk and weex playground into two repos and publish Weex playground in
> the name of ASF.


I personally prefer the multi-repo development model, and Apache does
support it.  But it's not a requirement.  It's up to y'all.  If you need
help getting another repo, let me know.

Best Regards,
Myrle

Re: [ANNOUNCEMENT] Weex 0.24.0 Released

[Myrle Krantz]

On Fri, May 24, 2019 at 12:20 PM 申远  wrote:

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

It is allowed to remove files from your final release.  But only the files
in the release are covered by the ASF legal shield.  It is only those files
which the Weex PMC officially makes any claims about.  This is similar to
all the files you add to the repo before the next release.


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

I do not know of iOS enterprise certificates under the ASF.  In general,
the convenience binary is currently not considered to be an act of the
foundation.  I agree with Jan that you should ask INFRA, but I believe the
answer will be "no."

What's more: a convenience binary shouldn't contain the compilation of
anything not in the code release.  It sounds like what you're publishing
there isn't actually Apache Weex, but "based on Apache Weex".

Best Regards,
Myrle

Re: [DISCUSS] Summer Program of Students for Weex

[Myrle Krantz]

Hey YorkShen,

That's fine and it sounds like Apache already has some representation which
makes me happy.

But I would be very interested in increasing visibility of this for next
year.  How do projects apply, and when does the process start?

Best,
Myrle

On Fri, May 10, 2019 at 5:18 AM 申远  wrote:

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

Re: [DISCUSS] Summer Program of Students for Weex

[Myrle Krantz]

Wonderful!  If you do need anything from the board, please let me know.
I'll be happy to help.

Best,
Myrle

On Thu, May 9, 2019 at 11:51 AM 申远  wrote:

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

Re: [DISCUSS] Summer Program of Students for Weex

[Myrle Krantz]

Well, I am on the board, but I don't think you need board approval.  I
suggest bringing it to ComDev (d...@community.apache.org).
ComDev is where GSoC is also managed, so it seems like a natural home for
this.

This is really good news!

Thank you,
Myrle

On Thu, May 9, 2019 at 10:26 AM 申远  wrote:

> For now, I think Apache Flink, Apache RocketMQ, Apache Incubator-Dubbo and
> Apache Incubator-Weex projects have or would have joined the Summer
> Program.
>
> I could ask the possibility of all Apache project participating the Summer
> Program, but maybe someone on behalf of the ASF Board could have the final
> decision.
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Myrle Krantz  于2019年5月9日周四 下午4:03写道：
>
> > That's pretty awesome!  Is this something that could benefit other Apache
> > projects too?
> >
> > Best Regards,
> > Myrle
> >
> > On Thu, May 9, 2019 at 9:51 AM 申远  wrote:
> >
> > > Hi, community
> > >
> > > I'm informed by an employee of Alibaba Group that they are hosting a
> > summer
> > > program intended to engage undergraduates/postgraduates into open
> source
> > > software development. He offered me a chance to include Weex in their
> > > summer program and in my opinion it would be great if Weex could
> > > participate as we do need more developers from community.
> > >
> > > As far as my knowledge, it is similar to Google summer of Code
> > > <https://summerofcode.withgoogle.com/>, one can look the detail
> proposal
> > > of
> > > Weex summer of Code on our Github site
> > > <https://github.com/apache/incubator-weex/issues/2422>.
> > >
> > > Best Regards,
> > > YorkShen
> > >
> > > 申远
> > >
> >
>

Re: [DISCUSS] Summer Program of Students for Weex

[Myrle Krantz]

That's pretty awesome!  Is this something that could benefit other Apache
projects too?

Best Regards,
Myrle

On Thu, May 9, 2019 at 9:51 AM 申远  wrote:

> Hi, community
>
> I'm informed by an employee of Alibaba Group that they are hosting a summer
> program intended to engage undergraduates/postgraduates into open source
> software development. He offered me a chance to include Weex in their
> summer program and in my opinion it would be great if Weex could
> participate as we do need more developers from community.
>
> As far as my knowledge, it is similar to Google summer of Code
> , one can look the detail proposal
> of
> Weex summer of Code on our Github site
> .
>
> Best Regards,
> YorkShen
>
> 申远
>

Re: [VOTE] Release Apache Weex (Incubating) 0.24.0-RC1

[Myrle Krantz]

Hey Weex PMC,

I'm concerned by the lack of voting here.  Creating a release candidate as
YorkShen has done here requires a fair bit of effort.

Please check the release and vote on it.

YorkShen, you don't have to close the vote after 72 hours.  72 is a
minimum, not a maximum.  You can wait until people have voted.  Perhaps
there is a holiday there that prevented people from getting to this in the
72 hours?

Best,
Myrle
Mentor, Apache Weex (Incubating)

On Mon, Apr 29, 2019 at 10:43 AM 申远  wrote:

> Hi, community.
>
> I am going to call a vote for release Apache Weex (Incubating) 0.24.0 as
> mentioned before.
>
>
>- Git tag for this Release:
>https://github.com/apache/incubator-weex/releases/tag/0.24.0-RC1
>- The source tarball could be found at :
>
> https://dist.apache.org/repos/dist/dev/incubator/weex/0.24.0/RC1/apache-weex-incubating-0.24.0-RC1-src.tar.gz
>- The signature of the source tarball could be found at :
>
> https://dist.apache.org/repos/dist/dev/incubator/weex/0.24.0/RC1/apache-weex-incubating-0.24.0-RC1-src.tar.gz.asc
>- The SHA-512 checksum of the source tarball could be found at :
>
> https://dist.apache.org/repos/dist/dev/incubator/weex/0.24.0/RC1/apache-weex-incubating-0.24.0-RC1-src.tar.gz.sha512
>- The source tarball is signed with Key: EC0B28566883F364, which could
>be found in the key file:
>https://dist.apache.org/repos/dist/release/incubator/weex/KEYS
>
> One can build the binary from source according to
> https://github.com/apache/incubator-weex/blob/0.24.0-RC1/HOW-TO-BUILD.md
> with
> corresponding compiling tools.
>
> Note:* As the compiling tools relies on XCode/NDK 13/NDK 16, it would not
> be a surprise if your build fails on a non-Mac environment or without
> corresponding NDK tools.*
>
> This vote will remain open for at least 72 hours. Please vote on releasing
> this RC.
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Best Regards,
> YorkShen
>
> 申远
>

Re: New Committer: Peihan Chen

[Myrle Krantz]

Congratulations!

On Tue, Apr 9, 2019 at 9:39 AM Willem Jiang  wrote:

> Welcome aboard!
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Tue, Apr 9, 2019 at 10:33 AM 申远  wrote:
> >
> > The Podling Project Management Committee (PPMC) for Apache Weex has
> invited
> > Peihan Chen to become a committer and we are pleased to announce that he
> > has accepted.
> >
> > Peihan Chen is a great Android Developer and give weex project many
> useful
> > PRs. He focuses on improving the stability, utility of Weex and the
> > following is part of his commit:
> >
> >- https://github.com/apache/incubator-weex/pull/1425, task may be
> null,
> >should be check, not try/catch
> >- https://github.com/apache/incubator-weex/pull/1835, edit
> interaction
> >logic && edit exception report logic #1835
> >- https://github.com/apache/incubator-weex/pull/2029, fix multithread
> >task crash after instance crash && rm unnecessary exception
> >
> > 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: Podling Report Reminder - April 2019

[Myrle Krantz]

Hey York Shen,

I think your report is correct and comprehensive.  Good job!

Best,
Myrle

On Tue, Mar 26, 2019 at 4:31 AM York Shen  wrote:

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

Re: [DISCUSS] Apache Project Maturity Model

[Myrle Krantz]

On Tue, Mar 12, 2019 at 12:58 PM 申远  wrote:

> But one person is not (fkysly).  You'll want to try to resolve that before
> > you go to graduation.
>
> He is not active for over a year. Anyway, I will try to contact him
> personally, but I am not sure whether there would be a response.
>

This isn't going to block your graduation.  You will just need to decide if
you want to include him in your initial PMC when you write your graduation
proposal.


>
> On the other hand, you have three people subscribed to your private list
> > who don't belong there.
>
> Is there an document for moderators ? How should I do that.
>

There is, but I actually find this more helpful:
https://whimsy.apache.org/committers/moderationhelper

There are also links from there to the documentation you're asking for.

Are you familiar with Whimsy?

As I am writing a blog for Apache 20th Anniversary and the deadline is
> coming, I will look into the above problem when I am available. I'm also
> glad if someone could give me a hand.
>

No hurry on this.  I'm interested to read your blog post!

Best Regards,
Myrle

Re: Weex, Apache and outside code

[Myrle Krantz]

Going back through my mails, I realized I failed to answer one of your
questions.  My apologies.

On Wed, Feb 20, 2019 at 9:24 AM 申远  wrote:

> 1. If the corresponding code is owned by Alibaba, and someone represented
> the company would sign the SGA, is there any necessary to have all the
> contributors signed the SGA again?
>

I believe that would be sufficient, but you should ask the legal
committee.  (See below.)

2. From my point of view, there will be lots of copyright  / trademark
> issues around, as none of the PPMC member is lawyer, Is there anyone from
> Apache we can consult about the law issue?
>

There is!  This is one of the services ASF provides for its projects.  You
can email legal-disc...@apache.org or, if it's something that needs to be
kept private legal-inter...@apache.org.  You may prefer to submit a JIRA
ticket (https://issues.apache.org/jira/projects/LEGAL)  You can get more
information here: https://www.apache.org/legal/


> 3. weex-toolkit is already an open source project under MIT license, would
> it violate any copyright  / trademark rules/laws if we fork the original
> weex-toolkit and push it to Apache repos.
>

I believe it would be allowed, because the MIT license is a category A
license.  But I suggest you ask someone with more legal know-how (see
above).  It may not accomplish your purposes unless you convince the
developers there to start doing their work here.  If they were to continue
working over there, it would be problematic because the Weex PMC wouldn't
be able to participate in decisions about who commits or what they commit.

Best Regards,
Myrle

Re: [DISCUSS] Apache Project Maturity Model

[Myrle Krantz]

I think y'all are making *excellent* progress.  You seem worried about the
number of committers, and I'm glad you're keeping an eye on that issue, but
for me it wouldn't be a graduation blocker.  Community building isn't
something you really "finish" before you leave the incubator.

As to listing the members of the PPMC, keep in mind that that incubator
page will no longer be relevant to you when you graduate.  You may want to
find a different location for the information already.  But this would not
block you from graduating.

You've successfully done three releases.  (With three different release
managers!  Good job!)  I think that is also enough to demonstrate
graduation readiness on that aspect.

You're right that you need to continue to work on keeping your
communication on the list.  But I do think you've improved, and you've
certainly demonstrated that you understand why you need it.

I am concerned about the trademark issues we've already discussed.  I want
to see you at least make some progress on that before you graduate.  Right
now that's the only thing I see stopping you from graduating.  Others may
not share my opinion that this is a graduation blocker.

Almost all of your PMC members are subscribed to the private list, which is
very good.  But one person is not (fkysly).  You'll want to try to resolve
that before you go to graduation.  On the other hand, you have three people
subscribed to your private list who don't belong there.  I'm guessing these
are your inactive mentors.  This is an easy issue to resolve.  The list
moderators should unsubscribe them.  If you need help, let me know.

I may be missing something.  I hope the other mentors chime in.  But on the
whole, you're in really good shape.  Congratulations on having a healthy
project community!

Best Regards,
Myrle

On Thu, Mar 7, 2019 at 4:54 AM 申远  wrote:

> Hi, there
>
> It took me a few hours to evaluate the maturity for Weex according to The
> Apache Project Maturity Model (
> http://community.apache.org/apache-way/apache-project-maturity-model.html
> ),
> it seems like there is still a big improvement space for Weex. The detail
> is listed below:
> Document issueReleaseRE50
>
> The release process is documented and repeatable to the extent that someone
> new to the project is able to independently generate the complete set of
> artifacts required for a release.
>
> We should list the Apache Release procedure clearly in the document.
> QualityQU30
>
> The project provides a well-documented, secure and private channel to
> report security issues, along with a documented way of responding to them.
>
> Again, we should list the report channel clearly in the document.
> CommunityCO50
>
> The way in which contributors can be granted more rights such as commit
> access or decision power is clearly documented and is the same for all
> contributors.
>
> Still, we need to list some basic requirement to be a committers.
> Consensus BuildingCS10
>
> The project maintains a public list of its contributors who have decision
> power -- the project's PMC (Project Management Committee) consists of those
> contributors.
>
> The PPMC & Committer is listed in in the weex status page
> , I think adding a link to
> weex status page in our document is enough.
> CS20
>
> Decisions are made by consensus among PMC members and are documented on the
> project's main communications channel. Community opinions are taken into
> account but the PMC has the final word if needed.
>
> Though we follow the normal Apache consensus building and voting procedure,
> but we should make it clear in our document.
> Long time issueCommunity
>
> The community is meritocratic and over time aims to give more rights and
> responsibilities to contributors who add value to the project.
>
> The active committer of Weex is not enough, we need get more people
> involved, and find more contributors and committers from weex users.
> Consensus building
>
> All "important" discussions happen asynchronously in written form on the
> project's main communications channel. Offline, face-to-face or private
> discussions that affect the project are also documented on that channel.
>
> We are getting better at this part, but not enough.
> Release
>
> We may need more release.
>
> Guys, what do you think of ?
>
> Best Regards,
> YorkShen
>
> 申远
>

Re: Question about the website of weex

[Myrle Krantz]

This might also be useful:

http://www.apache.org/foundation/marks/reporting.html

Best Regards,
Myrle

On Wed, Mar 6, 2019 at 4:14 PM Myrle Krantz  wrote:

> Hey YorkShen,
>
> If someone is misusing your brand and ignoring your requests to stop
> branding violations, the law is on your side.  This is a point on which the
> Apache Software Foundation can help:
>
> http://www.apache.org/foundation/marks/responsibility#responsible
>
> If you need help with this, you can send an email to
> legal-disc...@apache.org  If you ignore abuse of your brand, you will
> eventually lose the exclusive right to that brand.  Then you would lose the
> ability to protect your users against abuse done in your name by third
> parties who co-opted your brand.
>
> Best Regards,
> Myrle
>
> On Wed, Mar 6, 2019 at 4:03 PM 申远  wrote:
>
>> 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 

Re: Question about the website of weex

[Myrle Krantz]

Hey YorkShen,

If someone is misusing your brand and ignoring your requests to stop
branding violations, the law is on your side.  This is a point on which the
Apache Software Foundation can help:

http://www.apache.org/foundation/marks/responsibility#responsible

If you need help with this, you can send an email to
legal-disc...@apache.org  If you ignore abuse of your brand, you will
eventually lose the exclusive right to that brand.  Then you would lose the
ability to protect your users against abuse done in your name by third
parties who co-opted your brand.

Best Regards,
Myrle

On Wed, Mar 6, 2019 at 4:03 PM 申远  wrote:

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

Re: New Committer: He Ling

[Myrle Krantz]

Congratulations He Ling!!

Greets,
Myrle

On Wed, Mar 6, 2019 at 11:46 AM Jan Piotrowski  wrote:

> 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: Question about the website of weex

[Myrle Krantz]

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

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

[Myrle Krantz]

This is just my personal opinion, but:

I'd talk about development in English, but answer users in Chinese if they
ask their question in Chinese.  I know that makes for some awkward
transitions since the shift between explaining something to a user, and
recognizing an area where improvement is needed is sometimes gradual.  But
some users won't speak English, and you want to be able to help them, or
capture their needs.  Google translate is something anyone can do after the
fact too, and translations are constantly improving, so why freeze the
translation in time?

If you'd like more opinions (and can accept that they are likely to be
contradictory : o), consider asking the incubator community at large.

Best Regards,
Myrle


On Thu, Feb 21, 2019 at 5:21 AM 申远  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: [DISCUSS] can we use weex.io as the short domain name for the apache project

[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
> > > > 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&A 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

[Myrle Krantz]

More information,

here are the steps that will have to be completed for the IP clearance:

http://incubator.apache.org/ip-clearance/ip-clearance-template.html

I think finding out who currently *owns* the code is a good first step.  My
suspicion is that most of it is work-for-hire performed for Alibaba.  That
would mean Alibaba owns the code.  Please use your contacts inside that
company to find out.

Best Regards,
Myrle


On Tue, Feb 19, 2019 at 12:30 PM Myrle Krantz  wrote:

> Hi YorkShen,
>
> You may not need to contact all of the contributors.  Some of the
> contributions may not pass the threshold of originality which is commonly
> applied in copyright law.
>
> For example:
> https://github.com/weexteam/weex-toolkit/commits?author=RiverCheng0825
>
> This contributor only provided two commits and both were minor wording
> changes.  My initial guess looking at the contributors list is that you'll
> need to contact roughly half of the contributors.  If you're lucky, some of
> them are already part of the Weex project.
>
> That's the copyright law side of things.  On the trademark law side of
> things you have a different problem.  As far as I know, the weex name
> belongs to Apache.  Naming an account weexteam, and a project weex-toolkit
> violates that trademark.  It implies that a thing is Apache Weex which is
> clearly not, since
> * the license of the code isn't Apache,
> * the code doesn't belong to Apache,
> * the contributors aren't discussing their changes on the Apache mailing
> lists, and
> * the Apache Weex PMC can't decide who is allowed to contribute to the
> code.
>
> I'm guessing that you want most of that code to actually be part of the
> Apache Weex project.  If you can get it donated, that will be a much nicer
> way to resolve the problem.  But if you can't get it resolved that way, the
> names of the things that aren't Weex will have to be changed so that they
> aren't misleading.  In short you have two options:
>
> * Get the code donated and make the contributors Weex committers, or
> * Change the names in the code so that it doesn't call itself Weex.
>
> I believe getting the code donated would be better for the community.  But
> it's up to you.  Either way, I'll help you navigate Apache in the steps
> involved.
>
> You have time to do this, so you can do it repository by repository if you
> need to.  But you'll have to get it done before Weex can graduate.
>
> Best Regards,
> Myrle
>
> On Mon, Feb 18, 2019 at 8:29 AM 申远  wrote:
>
>> It took me some time to read things about IP Clearance
>> <https://incubator.apache.org/guides/ip_clearance.html>, and I think
>> https://github.com/weexteam/weex-toolkit is the only repo we should move.
>> The following problems may prevent us from moving weex-toolkit to apache
>>
>>1. According to informations on github
>><https://github.com/weexteam/weex-toolkit/graphs/contributors>, there
>>are 25 contributors, it is almost impossible to notify all them to
>> sign the
>>SGA.
>>2. weex-toolkit is owned not by Alibaba Group
>><https://github.com/alibaba> but a custom weexteam
>><https://github.com/weexteam> organization among which many developers
>>are employees of Alibaba Group. As I am not an IP lawyer, I don't know
>>whether there is a potential IP issues or how to solve this issue.
>>
>> Best Regards,
>> YorkShen
>>
>> 申远
>>
>>
>> Jan Piotrowski  于2019年2月15日周五 下午7:44写道：
>>
>> > Is weexteam/weex-toolkit really the only repo that should be included?
>> > If you go through this process, better make sure all the relevant
>> > stuff is included. If you plan to deprecate or remove things in the
>> > future, you can still do so. But for now _all_ the used code should be
>> > moved over to Apache.
>> >
>> > For the details on SGA/MIT etc the mentors will have to help. Usually
>> > there are practical and simple solutions to these things.
>> >
>> > J
>> >
>> > Am Fr., 15. Feb. 2019 um 05:16 Uhr schrieb 申远 :
>> > >
>> > > >
>> > > > 1. What repositories should be imported? (=> List of repositories)
>> > >
>> > >
>> > > https://github.com/weexteam/weex-toolkit
>> > >
>> > > 2. Who contributed to theses repositories? Who are active and relevant
>> > > > contributors? (Individuals and companies) (=> List of names)
>> > > >
>> > >
>> > > 25 individuals, maybe two or t

Re: Weex, Apache and outside code

[Myrle Krantz]

; > > > > > > >
> > > > > > > > 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
> > > > > > > - 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 <
> > my...@apache.org
> > > > >
> > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hey Dan,
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Feb 12, 2019 at 4:46 AM Dan <
> faterr...@gmail.com
> > >
> > > > > 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
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > > >
> >
>

Fwd: PMCs: share your Project's experience with The Apache Way

[Myrle Krantz]

Hi all,

Hello Weex,

This invitation is for the Weex PMC as well.  Would anyone here like to
write a blog?  In addition to being good publicity for Apache, it's also
good publicity for your project.

Best Regards,
Myrle

- Original message -
From: Sally Khudairi 
To: "ASF Marketing & Publicity" 
Subject: PMCs: share your Project's experience with The Apache Way
Date: Wed, 13 Feb 2019 00:45:48 -0500

Hello Apache PMCs --you are invited to participate in the ASF's upcoming
promotions for its 20th Anniversary on 26 March.

We will be having numerous publicity activities leading up to the date, and
throughout the year.

One way Apache PMCs can participate is by writing a post that will be
published on blogs.apache.org (and possibly other outlets) on how The
Apache Way has helped Apache Projects and their communities.

There is no restriction on participation --every Apache project,
sub-project, incubating podling, Labs initiative, and committee is welcome
to submit their experience. The important point is that it represents a
*community* perspective. You may choose a single author to write the piece
but it needs to be approved by the PMC (or equivalent) prior to publishing.

We are seeking at least 3 submissions in advance of the Anniversary date
(will be due no later than 15 March). The rest of the articles will be
paced for publishing throughout the year.

We prefer articles with a positive angle throughout, but understand that
our projects have unique experiences. We'd love to hear your perspectives
on how The Apache Way makes your project work, whether you've come to the
ASF as a brand new project, an established code base and community, or
emerged from an existing TLP. Even projects that are now in the Attic may
have a great story. Target article length ~800-1,600 words (longer is fine;
don't stress over this).

Pitch me your ideas and let's make this happen!

If you're interested in this opportunity, please send me:

1) Project Name and of primary point of contact;
2) Date that you will be submitting your article (to confirm, if for the
20th Anniversary, it is due NO LATER than 15 March);
3) Topic(s) that you'd like to address.

Thanks in advance for your interest and participation. I look forward to
working with you!

Warm regards,
Sally

- - -
Vice President Marketing & Publicity
Vice President Sponsor Relations
The Apache Software Foundation

Tel +1 617 921 8656 | s...@apache.org

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

Re: Weex, Apache and outside code

[Myrle Krantz]

Hi YorkShen,

If you’re ready, I’ll file a Jira ticket with INFRA. Or would you like to
do it?

Best Regards,
Myrle

On Thu, Feb 14, 2019 at 3: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
> > - 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 impor

Re: Weex, Apache and outside code

[Myrle Krantz]

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

Fwd: [DISCUSS] Guidelines for distribution of incubating artefacts on other platforms

[Myrle Krantz]

Hey all,

Since this topic impacts you, I hope you’ll read what Justin wrote and
object if it doesn’t cover your project needs. I know English is hard for
many of you and Apache's processes are also new for you.  If you need help
understanding anything written here or help formulating your thoughts, I
will be happy to provide it.

Best Regards,
Myrle

-- Forwarded message -
From: Justin Mclean 
Date: Fri, Feb 8, 2019 at 8:08 AM
Subject: [DISCUSS] Guidelines for distribution of incubating artefacts on
other platforms
To: 


Hi,

Feedback welcome. If you think anything here is not in line with the ASF
release and distribution policy please speak up. Currently it’s not clear
to me if RCs, snapshots or nightlys would be allowed on these platforms so
some changes may need to be made.

If you want to add another platform please do so, but these are one we’ve
recently had issues with that I’m aware of.

Currently not many projects would be complying with this, for instance most
likely missing the incubator disclaimer, which I think is importtant.

Does the IPMC think we need to have a vote on approving this?

I've added a harsh non-compliance to hopefully smart how important this is
and to reduce the risk to the ASF. If you think it is too harsh or not
needed speak up.

--
Guidelines to help you comply with the ASF release and distribution policies

In addition to the Apache mirror system incubating projects may distribute
artefacts on other platforms as long as they follow these general
guidelines:
- Unofficial releases need to be made from approved voted on approved ASF
releases.
- An incubating disclaimer must be clearly be displayed where the artefacts
are made available.
- Release candidates, nightlys and snapshots must not be advertised to the
general public.
- Apache project branding and naming needs to be respected.
- It should be clear that the artefact in under the ALv2 license.
- Where possible these artefacts should not be referred to as releases.

If any podling is found not to comply they will be asked to fix it, if a
fix doesn’t happen with a week they will be asked to remove the offending
artefact(s), if a podling commits serial offences or fails to remove
artefacts when asked to within a week they will be banned from using that
distribution mechanism altogether.

GitHub

Artifacts show up on https://github.com/apache/incubator-/releases

To comply with ASF release and distributions please ensue the following:
- Any releases need to include the text of the incubation disclaimer.
- The release page must not contain release candidates, nightly or
snapshots releases.
- Any releases that exist before coming into incubation need to be clearly
described and tagged as such on https://github.com/apache/incubator-
/tags.
- Release candidates, nightly or snapshots releases can be tagged and
appear on https://github.com/apache/incubator-/tags.

Docker

Artefacts need to be placed in https://hub.docker.com/r/apache/ or
https://hub.docker.com/u/apache/

To comply with ASF release and distributions please ensue the following:
- The overview should include the incubator disclaimer.
- The docker file should include an ASF header.
- The docker file should include the incubator disclaimer.
- "docker pull apache/" should not install an artefact containing
unapproved code.
- Release candidates, nightly or snapshots need to be clearly tagged.
- The latest tag should not point to an artefact containing unapproved code
e.g. to master or dev branches or to a RC or snapshot.

NPM

Artefacts  show up on https://www.npmjs.com/package/apache version
page

To comply with ASF release and distributions please ensue the following:
- The readme tab needs to include the text of the incubation disclaimer.
- “npm install apache” should not install an artefact containing
unapproved code.
- The latest release should not point to an artefact containing unapproved
code e.g. a release candidate or snapshot.
- Release candidates, nightly or snapshots need to be clearly tagged.
- The license field should display the ALv2 license.

PiPy

Artefacts need to be placed in https://pypi.org/project/apache/

To comply with ASF release and distributions please ensue the following:
- The project description should include the incubator disclaimer.
- “pip install apache" should not install an artefact containing
unapproved code.
- Release candidates, nightly or snapshots need to be clearly tagged as
pre-release on https://pypi.org/project/apaceh/#history
- The latest version should not point to an artefact containing unapproved
code e.g. to a release candidate or snapshot
- The meta license field should display the ALv2 license.
—

Once the discussion has died down I'll run this past infra and legal and
see if they are fine with it and then bring it to the boards attention.

Thanks

Re: Weex, Apache and outside code

[Myrle Krantz]

Hi Dan,

Some answers inline:

On Fri, Feb 1, 2019 at 10:29 AM Dan  wrote:

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

Normally repo history can also be imported to an Apache repository.  Is
that what you mean by warehouse?


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

Which kinds of adjustments do you need to make for an Apache project?
Generally, as long as the code is legally licenseable with the ApacheV2
license, Apache doesn't set technical requirements.  The Weex project may
have technical requirements, but I haven't heard anyone espress any here.


> I look forward to more comments and discussions to get this matter going.
>

Thank you for being so open to considering this!

Best Regards,
Myrle

Re: Weex, Apache and outside code

[Myrle Krantz]

Hey York Shen,

I can understand why you're concerned, but nightly builds are a normal
process for a lot of projects.

A nightly build isn't a release, and getting user input can still be
considered an "internal" process.  We want to protect our users against a
situation in which they thought they had Apache licensed code, but are sued
for intellectual property theft.  As long as your testers are just trying
out your nightly build that shouldn't be a danger, right?

Best Regards,
Myrle

On Fri, Feb 1, 2019 at 9:44 AM York Shen  wrote:

> According to my understanding and what Justin Mclean wrote
> https://lists.apache.org/thread.html/5c5a75f00d78211f75e10d17bfeb05bc7b0b4f9e8416fa602b0ebb54@%3Cgeneral.incubator.apache.org%3E
> <
> https://lists.apache.org/thread.html/5c5a75f00d78211f75e10d17bfeb05bc7b0b4f9e8416fa602b0ebb54@%3Cgeneral.incubator.apache.org%3E>
> , any format of unofficial release is forbidden, all release must be voted
> before we publish it.
>
> Correct me if I am wrong.
>
>
> Best Regards,
> York Shen
>
> 申远
>
> > 在 2019年2月1日，16:27，Willem Jiang  写道：
> >
> > A lot of Apache project has the SNAPSHOT release to get quick feedback
> > from the community.
> > It's OK if we don't announce the  SNAPSHOT release as an office Apache
> release.
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Fri, Feb 1, 2019 at 3:07 PM Dan  wrote:
> >>
> >> Hey
> >>
> >> I'm the author of the weex-toolkit, also the main developer of the tools
> >> around weex, I need to explain the questions you mentioned above.
> >>
> >>> Is this redirection and inclusion of outside code intentional? Is this
> >> temporary or meant to be permanent?
> >> Early in the development and maintenance of this project, the project
> was
> >> designed to support package integration of multiple command line tools,
> and
> >> to manage mappings between them through xtoolkit module, the idea is
> good,
> >> but too many projects are scattered into the various git repo, such as
> >> weex-debugger, weex-pack and so on.
> >>
> >> On the weex-toolkit@2.0,  I'm split each function module into separate
> >> parts, and manage multiple separate releases in the repository via
> Lerna,
> >> after that you can find all the module you want in the weex-toolkit repo
> >> (currently in the alpha process), you can enjoy it follow the document
> >> here: https://weex.io/tools/toolkit.html, it also supports the
> thrid-part
> >> extensions, the document will be further supplemented
> >>
> >>> 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 Weex.
> >>
> >>> why the module called toolkit but not cli?
> >>
> >> This is the name defined by the previous module creator. I personally
> think
> >> it might be better to call it weex-cli. Maybe I will consider renaming
> the
> >> module soon.
> >>
> >> Thanks
> >> Dan
> >>
> >> Jan Piotrowski  于2019年2月1日周五 上午3:13写道：
> >>
> >>> (Answering from my Apache address as my Gmail didn't receive your
> >>> responses - I can only see them in the list archive. Strange.)
> >>>
> >>> Thanks York Shen and Willem Jiang for your answers.
> >>>
>  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.
> >>>
> >>> Thanks for that explanation.
> >>>
> >>> In my opinion (and maybe Apache guidelines?) there should only be _one_
> >>> domain per Apache project, so you know you can trust the content of
> that
> >>> domain. You (the team) should probably decide which one of the two
> >>> apache.org domains you should use (and can use per incubation rules!),
> >>> and redirect the other one. Otherwise both Google and users can be
> >>> confused.
> >>> For the non-Apache mirrors for Chinese users you could maybe add a
> banner
> >>> that this is a mirror of *.apache.org for Chinese users and link to it
> >>> from somewhere _on_ the site so it is discoverable? Additionally maybe
> >>> no-index the domain, so Google doesn't list them? Then it is all
> >>> transparent and there is no confusion.
> >>>
>  The repo for weex is 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 the

Re: Weex, Apache and outside code

[Myrle Krantz]

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 can cause distortions in the code architecture. More important:
it can damage the community.

Best Regards,
Myrle

(I speak from experience: I made exactly this mistake when I first became
involved with Apache.)

Re: prerender discuss

[Myrle Krantz]

Happy New Year!
新年快乐

: o),
Myrle

On Thu, Jan 31, 2019 at 2:02 PM York Shen  wrote:

> Thanks, I will try later.
>
> As Chinese lunar year is coming, some of weex contributors I known
> (including me) will take a vacation for one or two weeks.
>
> Best Regards,
> York Shen
>
> 申远
>

Re: prerender discuss

[Myrle Krantz]

Hey York Shen,

You should now have both write permissions and permissions to add other
users.  You can administer the space.

If something doesn't work right, just ask.

A word to the wise: don't add write permissions for anonymous users.  That
eventually gets abused for spamming.

Best Regards,
Myrle


On Thu, Jan 31, 2019 at 4:00 AM York Shen  wrote:

> My user name on confluence is Kyork
>
> Thanks.
>
> Best Regards,
> York Shen
>
> 申远
>
> > 在 2019年1月29日，01:13，Myrle Krantz  写道：
> >
> > Hi,
> >
> > I just got myself admin access, and made the WEEX confluence space
> viewable
> > for anonymous users.  (IE you don't have to log in any more to see the
> > contents.)
> >
> > Now I can give you admin access if you can tell me the name of your
> > confluence account.
> >
> > Best Regards,
> > Myrle
> >
> > On Fri, Jan 25, 2019 at 5:13 AM 申远  wrote:
> >
> >> It seems like a great tool, how do apply for admin right?
> >>
> >>> 在 2019年1月25日，08:05，Willem Jiang  写道：
> >>>
> >>> +1 to use the Confluence for the design proposal discussion.
> >>> FYI, we just open a whitelist to the user to have the write access
> >>> right to avoid the spam.
> >>> You can add the user here with below link[1], if you have the admin
> >> right.
> >>>
> >>> [1]
> >>
> https://cwiki.apache.org/confluence/spaces/spacepermissions.action?key=WEEX
> >>>
> >>>
> >>> Willem Jiang
> >>>
> >>> Twitter: willemjiang
> >>> Weibo: 姜宁willem
> >>>
> >>> On Thu, Jan 24, 2019 at 6:53 PM Myrle Krantz  wrote:
> >>>>
> >>>> On Thu, Jan 24, 2019 at 4:09 AM 申远  wrote:
> >>>>
> >>>>> Thanks.
> >>>>>
> >>>>> There are two types of document for weex now
> >>>>> API/FAQ documents,  which we hosted it in another git repos.
> >>>>> https://github.com/apache/incubator-weex-site/ <
> >>>>> https://github.com/apache/incubator-weex-site/>
> >>>>> System design documents, which is the case happening here.
> >>>>>
> >>>>> There is no suitable place to write system design documents now. Is
> >> there
> >>>>> any advice or where will other Apache project host their system
> design
> >>>>> documents.
> >>>>>
> >>>>
> >>>> Everyone makes their own decisions, but many projects use Confluence
> for
> >>>> this purpose.  There are draw.io and Gliffy integrations which can
> >> both be
> >>>> used to collaboratively edit design proposals.
> >>>>
> >>>> For example: https://cwiki.apache.org/confluence/display/FINERACT
> >>>>
> >>>> You already have: https://cwiki.apache.org/confluence/display/WEEX
> but
> >> the
> >>>> permissions are very restrictive.
> >>>>
> >>>> Would this be useful to you?  Should we look into making the WEEX
> >>>> confluence space a bit more open?
> >>>>
> >>>> Best Regards,
> >>>> Myrle
> >>
> >>
>
>

Re: Update weex descriptions on Apache site

[Myrle Krantz]

I'm just guessing, but you're probably looking for this:

https://github.com/apache/incubator-weex-site

Greets,
Myrle

On Mon, Jan 28, 2019 at 10:30 AM York Shen  wrote:

> Well, it seems like that this thread is quiet for a while. It would be
> great if someone could give it a hand.
>
> Best Regards,
> York Shen
>
> 申远
>
> > 在 2019年1月16日，20:49，申远  写道：
> >
> > 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: prerender discuss

[Myrle Krantz]

Hi,

I just got myself admin access, and made the WEEX confluence space viewable
for anonymous users.  (IE you don't have to log in any more to see the
contents.)

Now I can give you admin access if you can tell me the name of your
confluence account.

Best Regards,
Myrle

On Fri, Jan 25, 2019 at 5:13 AM 申远  wrote:

> It seems like a great tool, how do apply for admin right?
>
> > 在 2019年1月25日，08:05，Willem Jiang  写道：
> >
> > +1 to use the Confluence for the design proposal discussion.
> > FYI, we just open a whitelist to the user to have the write access
> > right to avoid the spam.
> > You can add the user here with below link[1], if you have the admin
> right.
> >
> > [1]
> https://cwiki.apache.org/confluence/spaces/spacepermissions.action?key=WEEX
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Thu, Jan 24, 2019 at 6:53 PM Myrle Krantz  wrote:
> >>
> >> On Thu, Jan 24, 2019 at 4:09 AM 申远  wrote:
> >>
> >>> Thanks.
> >>>
> >>> There are two types of document for weex now
> >>> API/FAQ documents,  which we hosted it in another git repos.
> >>> https://github.com/apache/incubator-weex-site/ <
> >>> https://github.com/apache/incubator-weex-site/>
> >>> System design documents, which is the case happening here.
> >>>
> >>> There is no suitable place to write system design documents now. Is
> there
> >>> any advice or where will other Apache project host their system design
> >>> documents.
> >>>
> >>
> >> Everyone makes their own decisions, but many projects use Confluence for
> >> this purpose.  There are draw.io and Gliffy integrations which can
> both be
> >> used to collaboratively edit design proposals.
> >>
> >> For example: https://cwiki.apache.org/confluence/display/FINERACT
> >>
> >> You already have: https://cwiki.apache.org/confluence/display/WEEX but
> the
> >> permissions are very restrictive.
> >>
> >> Would this be useful to you?  Should we look into making the WEEX
> >> confluence space a bit more open?
> >>
> >> Best Regards,
> >> Myrle
>
>

Committer access to Apache github repositories

[Myrle Krantz]

Hi all,

Your mentor tip of the day:

When someone has been added to the committer roster they may still not be
able to merge github pull requests.  Committers need to follow certain
steps to be able to interact with Apache github repositories:

https://gitbox.apache.org/setup
https://github.com/settings/two_factor_authentication/configure

Best Regards,
Myrle

Re: prerender discuss

[Myrle Krantz]

On Thu, Jan 24, 2019 at 4:09 AM 申远  wrote:

> Thanks.
>
> There are two types of document for weex now
> API/FAQ documents,  which we hosted it in another git repos.
> https://github.com/apache/incubator-weex-site/ <
> https://github.com/apache/incubator-weex-site/>
> System design documents, which is the case happening here.
>
> There is no suitable place to write system design documents now. Is there
> any advice or where will other Apache project host their system design
> documents.
>

Everyone makes their own decisions, but many projects use Confluence for
this purpose.  There are draw.io and Gliffy integrations which can both be
used to collaboratively edit design proposals.

For example: https://cwiki.apache.org/confluence/display/FINERACT

You already have: https://cwiki.apache.org/confluence/display/WEEX but the
permissions are very restrictive.

Would this be useful to you?  Should we look into making the WEEX
confluence space a bit more open?

Best Regards,
Myrle

Re: prerender discuss

[Myrle Krantz]

Hey all,

Generally Apache mailing lists don't allow attachments.  It may be possible
to change this; I'd have to ask infra.  But since this is a design
discussion, perhaps you wish to document your design in confluence?  Weex
does have a confluence space with fairly limited permissions.  We could
explore making the permissions of the confluence space more expansive if
you're interested.

Best Regards,
Myrle

On Wed, Jan 23, 2019 at 4:51 AM 申远  wrote:

> 1. Image is still missing
> 2. Document is needed for such features, you may provide the image in the
> document if there is a problem with your email server.
> https://github.com/apache/incubator-weex-site/tree/draft <
> https://github.com/apache/incubator-weex-site/tree/draft>
>
> > 在 2019年1月22日，20:28，龙泉 <284437...@qq.com> 写道：
> >
> >
> 要解决的问题是weex页面render耗时长的问题，这里定义从WXSDKInstance的render方法开始到onRenderSuccess执行中间的时间为渲染的耗时。
> >
> > 有了耗时的定义再来看看weex正常的render过程:
> > > render -> http请求JsBundle -> weexcore createInstance ->
> jsCore执行jsBundle -> 创建虚拟dom action -> weex frameWork执行dom action ->
> 创建component、view、更新layout等 -> android系统渲染view
> >
>
>

Re: How to complete the Weex report for the board before the deadline of January 2?

[Myrle Krantz]

On Mon, Dec 24, 2018 at 2:18 PM Adam Feng  wrote:

> Finding a place to save the draft is a good idea,  I think there can be a
> wiki place in our official site to save the reports and let other
> contributors edit it.  Any ideas ?
>

I see you already have a wiki space:
https://cwiki.apache.org/confluence/display/WEEX/Weex+Home

You've already used it for a couple of reports too.

But it seems to not be public.  There appears to be at least one PPMC
member on the administrator list, so y'all should be able to use it.  If
you need help, just ask.

Best Regards,
Myrle

How to complete the Weex report for the board before the deadline of January 2?

[Myrle Krantz]

Hey all,

When do you usually start your board report?  For Fineract I generally aim
to finish it 2 days before it is due.  This gives me a couple of days extra
in case something comes up (and something always seems to come up).  For
the upcoming Weex report that would be December 31st.

I also generally put up a template a week or two before that.  I send it
out so PMC members can collaborate with me on it.  People don't always
participate, but they should at least have the opportunity.

See here for an example of how Fineract does this:
https://cwiki.apache.org/confluence/display/FINERACT/2018-10+October+Report

We prepare it in confluence and then copy it into the big report once it's
done.

Best Regards,
Myrle
Incubator Mentor, Apache Weex
V.P. Emeritus, Apache Fineract

Re: [ANNOUNCE] Welcome new committer Douma Fang

[Myrle Krantz]

Congratulations Douma!

-Myrle

On Wed, Dec 12, 2018 at 1:08 PM George Xu  wrote:

> Congratulations!!👍👍 @doumafang
>
> 方曦(千之)  于2018年12月12日周三 下午1:42写道：
>
> > Hey, developers in Weex community,
> >
> > I am Douma Fang. Thanks a lot for the trust you showed me during my work
> > for Incubator Weex project. I think this project is very promising and is
> > very worth invseting energy.
> >
> > And it was also nice of Adam to send me an invitation to become Incubator
> > Weex committer.
> >
> > I come from China and focus on developing components and modules of
> > WeexSDK, now I am working for Alibaba,Inc. Also I will continue
> > contributing code to Incubator Weex project. I sincerely wish we can
> have a
> > great cooperation relationship in Weex community.
> >
> > Very sincerely yours,
> >
> > Douma Fang.
> >
> > > 在 2018年12月12日，12:43，Adam Feng  写道：
> > >
> > > Hi, Community,
> > >
> > > I am pleased to announce that Douma Fang, whose Apache JIRA user name
> is
> > @qz and Github user name is @doumafang, has been voted in as a new
> > Incubator Weex committer.
> > >
> > > He has did and is doing a great job on Weex,  especially in iOS part,
> > and I just want to say thanks and congratulations. Please join me to say
> > congratulations to Douma Fang!
> > >
> > > Douma, would you please briefly introduce yourself to the community?
> > >
> > > Thanks.
> > > Adam Feng
> >
> >
>
> --
> Thanks.
> George Xu
>

Re: New committer : Wang Qianyuan

[Myrle Krantz]

Congratulations Qianyuan!

: o),
Myrle

On Mon, Dec 10, 2018 at 8:35 AM Adam Feng  wrote:

> Congratulations!
>
> Thanks.
> Adam Feng
> 在 2018年12月10日 +0800 PM1:59，Willem Jiang ，写道：
> > Welcome aboard Qianyuan！
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Mon, Dec 10, 2018 at 12:10 PM shihan zheng 
> wrote:
> > >
> > > The Project Management Committee (PMC) for Apache Weex
> > > has invited Wang Qianyuan to become a committer and we are pleased
> > > to announce that he has accepted.
> > >
> > > We look forward to Wang Qianyuan classmates making greater
> contributions to
> > > the Weex community.
> > >
> > > Being a committer enables easier contribution to the
> > > project since there is no need to go via the patch
> > > submission 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!
> > > -
> > > Shihan Zheng (Weex project team member )
>

Thank you all for welcoming me as your mentor

[Myrle Krantz]

I was wondering.  Are you familiar with the maturity model?

https://community.apache.org/apache-way/apache-project-maturity-model.html

This is not required for graduation. But it can help you determine your
level of readiness. It can also help you find what your project might want
to improve before (or after) graduation.

Best Regards,
Myrle
Weex Mentor

Re: [NEW MENTOR REQUIRED] Apache Weex (incubating)

[Myrle Krantz]

I would be interested in helping out as a mentor with Weex.

I've never mentored a project before, but I have brought my own project
through the incubator.

Best Regards,
Myrle


On Tue, Nov 20, 2018 at 3:38 AM Willem Jiang  wrote:

> There could be some new IPMC member onboard recently.  It could be
> good opportunity for Weex to look for new mentor.
> I appreciate any help you can provide.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Nov 19, 2018 at 7:54 PM Adam Feng  wrote:
> >
> > +1
> >
> > We would be grateful to anyone who can volunteer time to help. A few of
> us are still
> > new to the ASF processes and need guidance.
> >
> >
> > Thanks.
> > Adam Feng
> > 在 2018年11月14日 +0800 AM11:03，Hanks Zhang ，写道：
> > > +1.
> > >
> > > I also think Weex needs more guidance from more mentors, they can give
> > > advice from different perspectives. On the other hand, most PPMC and
> > > committers of Weex are Chinese, we wish Weex can absorb ideas form
> > > more world-wide developers from different cultures. Looking forward to
> your
> > > opinions.
> > >
> > > Best Regards,
> > > Hanks Zhang
> > >
> > > Jonathan Dong  于2018年11月12日周一 下午7:32写道：
> > >
> > > > Hi Folks,
> > > >
> > > > I’m writing to seek for new motivated mentors for the Apache Weex
> > > > (incubating) project, to drive and mentor the community and project
> to
> > > > graduate.
> > > >
> > > > Weex is a project aims to build high-performance mobile applications
> by
> > > > leveraging mobile web development experience. It was accepted into
> the
> > > > Apache Incubator since Nov. 30, 2016, there are 2 Apache releases
> during
> > > > the incubation period, and 11 PPMC and 3 committers by now. We have
> been
> > > > struggling with the active mentorship which could lead us through the
> > > > podling process and push the project to the graduation, for now we
> only
> > > > have one active mentor Willem Jiang (who helps a lot to grow the
> community
> > > > as well as the processes, thanks), and we believe it’s the right
> time to
> > > > invite one more mentor or two to offload some mentoring duty from
> Willem
> > > > and push us through the graduation.
> > > >
> > > > If you are interested, please let use know at
> > > > dev@weex.incubator.apache.org. Looking forward to your guidance.
> > > >
> > > > Cheers,
> > > >
> > > > Jonathan Dong
> > > >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>