Re: [DISCUSS] Transfer an iOS App to ASF's Apple account ?
Thanks, Justin I will bring this back to d...@weex.asf . Currently, I prefer deleting existing App, which would solve us from the trademark issue. Best Regards, YorkShen 申远 Justin Mclean 于2019年12月1日周日 上午8:35写道： > Hi, > > > So, which way is better? > > That is really up to the PPMC to decide. Some other projects have left > product names in package name (and the like), so it might be OK to leave it > in there, but I would rename it if you can. You may want to ask trademarks > their opinion. > > Thanks, > Justin > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
[DISCUSS] Transfer an iOS App to ASF's Apple account ?
Hi, community There is an iOS App called Weex Playground[1] built from the source code of incubator-weex-playground [2]. According to my knowledge, the App was uploaded before Weex donated to ASF under the bundle ID of `com.taobao.weexplayground`. Currently we are trying to solve the problems, and here are the solutions we have: - Delete the existing Weex Playground, then do a source code release for incubator-weex-playground, finally publish a new Weex Playground in ASF's Apple account with the bundleID of `org.apache.weexplayground`. - Transfer the existing Weex Playground to ASF, then do a source code release for incubator-weex-playground, finally publish a new Weex Playground in ASF's Apple account with the bundleID of `org.apache.weexplayground`. After the new one(org.apache.weexplayground) published, we would delete the old one(com.taobao.weexplayground). As suggested in dev@weex.apache, it would be easy to pass the App review of Apple if there are two Apps which only differs in bundleID. As Apple just doesn't allow rename bundleID, I don't know whether it's suitable to have an App whose bundleID is `com.taobao.weexplayground` in ASF's Apple account. I also contact the current owner of Weex Playground [1], they are willing to cooperate with ASF no matter we choose opinion 1 or 2. So, which way is better? [1] https://apps.apple.com/cn/app/weex-playground/id1130862662 [2] https://github.com/apache/incubator-weex-playground/ Best Regards, YorkShen 申远
Re: [DISCUSS] Host Dynamic Content on Apache Sever?
Hi, Justin > The disclaimer text is a little odd "and are used with permission as of > 2014.”? Is this actually correct? > There is a disclaimer template [1], and we just changed some words to fit the situation of Weex. There might be a bit of a Catch 22 here in that that policy also states: > "Note that podlings in the Apache Incubator may not grant permission for > third party requests for their podling trademarks, only VPs of top level > projects may do so.” > Understood of that, and I just sent a formal request [2] for using weex.io to VP, Brand management days ago. [1] http://www.apache.org/foundation/marks/domains.html#attributions [2] https://lists.apache.org/thread.html/78122338690c154ce1637bb0509edb948724fe98b61c7632e91cfc53@%3Cprivate.weex.apache.org%3E Best Regards, YorkShen 申远 Justin Mclean 于2019年11月17日周日 上午8:48写道： > Hi, > > > The website [1] is updated after negotiation with the maintainer. If > > everything is fine to you, I'd like to start request a formal approval > from > > VP, Brand Management according to domain name policy [2]. > > The disclaimer text is a little odd "and are used with permission as of > 2014.”? Is this actually correct? > > There might be a bit of a Catch 22 here in that that policy also states: > "Note that podlings in the Apache Incubator may not grant permission for > third party requests for their podling trademarks, only VPs of top level > projects may do so.” > > I would formally ask on tradmarks@ anyway, however be aware that IMO it’s > unlikely they will allow the “weex.io” domain, but may allow something > like “weexexamples.com” or something similar. > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [DISCUSS] Host Dynamic Content on Apache Sever?
Hi, Bertrand Delacretaz The website [1] is updated after negotiation with the maintainer. If everything is fine to you, I'd like to start request a formal approval from VP, Brand Management according to domain name policy [2]. [1] http://editor.weex.io/ [2] http://www.apache.org/foundation/marks/domains.html#permission Best Regards, YorkShen 申远 申远 于2019年11月6日周三 上午11:17写道： > Thanks > > I will talk to the maintainer of the website [1], maybe they could do some > change to solve the branding issue. > > Best Regards, > YorkShen > > 申远 > > > Bertrand Delacretaz 于2019年11月5日周二 下午7:12写道： > >> Hi, >> >> On Tue, Nov 5, 2019 at 4:33 AM 申远 wrote: >> >... Is there a way to migrate such dynamic content to >> https://weex.apache.org ?.. >> >> A project can get virtual machines, not sure what the current flavor >> of that is but https://www.apache.org/dev/services#virtual-servers >> mentions FreeBSD jails and Ubuntu VMs. See >> https://www.apache.org/dev/infra-contact for how to ask for that. >> >> In the specific case of [1] I think some rebranding would allow it to >> remain separate form Apache Weex, mainly saying it's an editor "for >> Apache Weex" and adding the usual disclaimers and a link to >> https://weex.apache.org/ - https://www.apache.org/foundation/marks/ >> has more details. >> >> > [1] http://editor.weex.io/ >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >>
Re: [IP CLEARANCE] Accepting Donation from Weex UI to Apache Weex
If there is no other issue, then the IP clearance passed based on lazy consensus (120 hours passed). Best Regards, YorkShen 申远 申远 于2019年11月10日周日 下午5:20写道： > I'm not 100% sure what you mean by that. Only the project has that right, >> the author (once the code is decorated) has no more or less rights than >> anyone else. >> > > Rephrase myselft. After the donation, the project(Weex UI) could remain > its name as it is. > > Best Regards, > YorkShen > > 申远 > > > Justin Mclean 于2019年11月10日周日 上午5:08写道： > >> Hi, >> >> > By donating, the author of Weex UI will have the right of using the >> trademark of Weex. >> >> I'm not 100% sure what you mean by that. Only the project has that right, >> the author (once the code is decorated) has no more or less rights than >> anyone else. >> >> > There are some other projects may violate the trademark of ASF, I'm >> really >> > appreciated if someone could help append the list [3] I created. >> >> Who are you asking here? As I’ve mentioned before this would be up to the >> Weex PMC not just you. >> >> Thanks, >> Justin >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >>
Re: [IP CLEARANCE] Accepting Donation from Weex UI to Apache Weex
> > I'm not 100% sure what you mean by that. Only the project has that right, > the author (once the code is decorated) has no more or less rights than > anyone else. > Rephrase myselft. After the donation, the project(Weex UI) could remain its name as it is. Best Regards, YorkShen 申远 Justin Mclean 于2019年11月10日周日 上午5:08写道： > Hi, > > > By donating, the author of Weex UI will have the right of using the > trademark of Weex. > > I'm not 100% sure what you mean by that. Only the project has that right, > the author (once the code is decorated) has no more or less rights than > anyone else. > > > There are some other projects may violate the trademark of ASF, I'm > really > > appreciated if someone could help append the list [3] I created. > > Who are you asking here? As I’ve mentioned before this would be up to the > Weex PMC not just you. > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [DISUCSS] Is there any neccessary to do an Apache Release if we publish an App to Apple Store?
So, what's the step? 1. Call a normal Apache Vote 2. Build the App and upload to App Store with ASF's Apple Developer Account using the code in step 1 Best Regards, YorkShen 申远 Greg Stein 于2019年11月8日周五 上午8:57写道： > We're trying to do better on what services are available, so consider this > "step one" :-) > > > On Thu, Nov 7, 2019 at 1:19 PM Julian Feinauer < > j.feina...@pragmaticminds.de> > wrote: > > > Thanks Greg, I didn't know that! > > > > Julian > > > > Am 07.11.19, 19:24 schrieb "Greg Stein" : > > > > > > > https://cwiki.apache.org/confluence/display/INFRA/Distribution+via+the+Apple+App+Store > > > > On Thu, Nov 7, 2019 at 12:14 PM Greg Stein wrote: > > > > > An app signed by the Foundation is most definitely associated with > > the > > > ASF. The Foundation has an Apple Developer Account for exactly this > > reason. > > > > > > > > > On Thu, Nov 7, 2019 at 9:17 AM Justin Mclean < > > jus...@classsoftware.com> > > > wrote: > > > > > >> Hi, > > >> > > >> A binary convenance release needs to be created from released > voted > > on > > >> code. [1] > > >> > > >> However if some 3rd party (not the PPMC) wants to use unreleased > > code and > > >> make a “release” from it and put that somewhere but it needs to be > > clear > > >> that this is not in anyway associated with the ASF and it needs to > > respects > > >> ASF branding and trademarks.Doing [1] is probably easier so I > > suggest you > > >> go down that path. > > >> > > >> Thanks, > > >> Justin > > >> > > >> 1. > > http://www.apache.org/legal/release-policy.html#compiled-packages > > >> > > - > > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > >> For additional commands, e-mail: > general-h...@incubator.apache.org > > >> > > >> > > > > > > >
Re: [DISUCSS] Is there any neccessary to do an Apache Release if we publish an App to Apple Store?
I am OK with the normal release procedure if we have to. But I'd like to know the boundary line here, why we don't need go though the release procedure for Apache Project Website and why we need it for an App built from Apache code. What's the difference here? Best Regards, YorkShen 申远 Jamie G. 于2019年11月7日周四 下午9:07写道： > The App should follow a release process - vetting, vote, signatures, > tag on source repository, etc. > > The community should approve its release. > > On Thu, Nov 7, 2019 at 9:29 AM 申远 wrote: > > > > Hi, there > > > > I'd like to know whether it's necessary to do an Apache Release if we > > publish an App to Apple Store using the code of Apache Weex [1]. I > > understand there is no need to do an Apache Release if we publish > projects > > website, but what if we publish an App to iOS Apple Store? > > > > [1] https://github.com/apache/incubator-weex-playground/tree/master/ios > > > > Best Regards, > > YorkShen > > > > 申远 > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
[DISUCSS] Is there any neccessary to do an Apache Release if we publish an App to Apple Store?
Hi, there I'd like to know whether it's necessary to do an Apache Release if we publish an App to Apple Store using the code of Apache Weex [1]. I understand there is no need to do an Apache Release if we publish projects website, but what if we publish an App to iOS Apple Store? [1] https://github.com/apache/incubator-weex-playground/tree/master/ios Best Regards, YorkShen 申远
Re: [IP CLEARANCE] Accepting Donation from Weex UI to Apache Weex
Forwarding to the wrong mailing list, never mind. Best Regards, YorkShen 申远 申远 于2019年11月6日周三 下午8:39写道： > I am forwarding this message to d...@weex.asf as Weex UI is under IP > clearance [1] process now. > > We have some concerns about Weex branding, and I think donation like this > would solve this kinds of concern. > > The organization using the mark must do nothing that would, in conjunction >> with the mark, suggest sponsorship or endorsement by the trademark holder. >> [2] >> > > FYI: Weex is a trademark of Apache Software Foundation, any the > combination of Weex UI is a violation of ASF's branding, and Weex PMC is > responsible for solving this kinds of problems. By donating, the author of > Weex UI will have the right of using the trademark of Weex. > > There are some other projects may violate the trademark of ASF, I'm really > appreciated if someone could help append the list [3] I created. > > [1] https://incubator.apache.org/ip-clearance/ > [2] http://www.apache.org/foundation/marks/ > [3] > https://cwiki.apache.org/confluence/display/WEEX/CheckList#third-party-ip-solved > > Best Regards, > YorkShen > > 申远 > > > -- Forwarded message - > 发件人： 申远 > Date: 2019年11月6日周三 下午8:28 > Subject: [IP CLEARANCE] Accepting Donation from Weex UI to Apache Weex > To: > > > Hi community, > > The Weex community has made consensus about accepting donation of Weex UI > [1]. > > Weex UI is a rich interaction, lightweight, high performance UI library > based for Apache Weex. > > The IP clearance form can be found at: > https://incubator.apache.org/ip-clearance/weex_ui.html once the website > updates. One can view the xml version at: > https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/weex_ui.xml > > The git commit containing the donation can be found > https://github.com/alibaba/weex-ui/commit/cb845a41e1b7cb9acff133f152996d8d03d05beb > . The git repo will be transferred to ASF at the end of the process. > > Please vote to approve this contribution. Lazy consensus applies: > > If no -1, votes are being cast within the next 72 hours, the vote passes. > > [1] > https://mail-archives.apache.org/mod_mbox/weex-dev/201910.mbox/%3Ctencent_52455495A38322341536DC76283B69A47607%40qq.com%3E > > Best Regards, > YorkShen > > 申远 >
Fwd: [IP CLEARANCE] Accepting Donation from Weex UI to Apache Weex
I am forwarding this message to d...@weex.asf as Weex UI is under IP clearance [1] process now. We have some concerns about Weex branding, and I think donation like this would solve this kinds of concern. The organization using the mark must do nothing that would, in conjunction > with the mark, suggest sponsorship or endorsement by the trademark holder. > [2] > FYI: Weex is a trademark of Apache Software Foundation, any the combination of Weex UI is a violation of ASF's branding, and Weex PMC is responsible for solving this kinds of problems. By donating, the author of Weex UI will have the right of using the trademark of Weex. There are some other projects may violate the trademark of ASF, I'm really appreciated if someone could help append the list [3] I created. [1] https://incubator.apache.org/ip-clearance/ [2] http://www.apache.org/foundation/marks/ [3] https://cwiki.apache.org/confluence/display/WEEX/CheckList#third-party-ip-solved Best Regards, YorkShen 申远 -- Forwarded message ----- 发件人： 申远 Date: 2019年11月6日周三 下午8:28 Subject: [IP CLEARANCE] Accepting Donation from Weex UI to Apache Weex To: Hi community, The Weex community has made consensus about accepting donation of Weex UI [1]. Weex UI is a rich interaction, lightweight, high performance UI library based for Apache Weex. The IP clearance form can be found at: https://incubator.apache.org/ip-clearance/weex_ui.html once the website updates. One can view the xml version at: https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/weex_ui.xml The git commit containing the donation can be found https://github.com/alibaba/weex-ui/commit/cb845a41e1b7cb9acff133f152996d8d03d05beb . The git repo will be transferred to ASF at the end of the process. Please vote to approve this contribution. Lazy consensus applies: If no -1, votes are being cast within the next 72 hours, the vote passes. [1] https://mail-archives.apache.org/mod_mbox/weex-dev/201910.mbox/%3Ctencent_52455495A38322341536DC76283B69A47607%40qq.com%3E Best Regards, YorkShen 申远
[IP CLEARANCE] Accepting Donation from Weex UI to Apache Weex
Hi community, The Weex community has made consensus about accepting donation of Weex UI [1]. Weex UI is a rich interaction, lightweight, high performance UI library based for Apache Weex. The IP clearance form can be found at: https://incubator.apache.org/ip-clearance/weex_ui.html once the website updates. One can view the xml version at: https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/weex_ui.xml The git commit containing the donation can be found https://github.com/alibaba/weex-ui/commit/cb845a41e1b7cb9acff133f152996d8d03d05beb . The git repo will be transferred to ASF at the end of the process. Please vote to approve this contribution. Lazy consensus applies: If no -1, votes are being cast within the next 72 hours, the vote passes. [1] https://mail-archives.apache.org/mod_mbox/weex-dev/201910.mbox/%3Ctencent_52455495A38322341536DC76283B69A47607%40qq.com%3E Best Regards, YorkShen 申远
Re: [DISCUSS] Host Dynamic Content on Apache Sever?
Thanks I will talk to the maintainer of the website [1], maybe they could do some change to solve the branding issue. Best Regards, YorkShen 申远 Bertrand Delacretaz 于2019年11月5日周二 下午7:12写道： > Hi, > > On Tue, Nov 5, 2019 at 4:33 AM 申远 wrote: > >... Is there a way to migrate such dynamic content to > https://weex.apache.org ?.. > > A project can get virtual machines, not sure what the current flavor > of that is but https://www.apache.org/dev/services#virtual-servers > mentions FreeBSD jails and Ubuntu VMs. See > https://www.apache.org/dev/infra-contact for how to ask for that. > > In the specific case of [1] I think some rebranding would allow it to > remain separate form Apache Weex, mainly saying it's an editor "for > Apache Weex" and adding the usual disclaimers and a link to > https://weex.apache.org/ - https://www.apache.org/foundation/marks/ > has more details. > > > [1] http://editor.weex.io/ > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
[DISCUSS] Host Dynamic Content on Apache Sever?
Hi, there During solving brand issue for Apache Weex, I found there is a website [1] that could violate the brand of Apache Weex. After some communication, I learnt they use Node.JS to develop the website site. Is there a way to migrate such dynamic content to https://weex.apache.org ? According to my understanding, the Apache project website are only allowed to host static content. How could we solve this problem if they create a dynamic website with Node.JS? [1] http://editor.weex.io/ Best Regards, YorkShen 申远
Re: [VOTE] Graudate Apache Weex (Incubating) as a Top Level Project
Hi, Dave and Justin. Thanks to both of you, I‘m really appreciated your help. Just have a nice conversation with Dave, I think Weex still needs to be in the Incubator for some time. I replied earlier in the thread, but the response from Weex really should > be to complete a Podling Name Search - > https://incubator.apache.org/guides/names.html < > https://incubator.apache.org/guides/names.html> > I will do it and discuss it in another mailing list, as this list is too long already. At ApacheCon Shane gavse a version of this talk which also may help: > http://shaneslides.com/fossbackstage/Who-Owns-That-FOSS-Brand.pdf > Thanks, Justin, this talk really taught me something, I really wish I could read it years before. Best Regards York Shen 申远 Dave Fisher 于2019年11月1日 周五11:28写道： > Hi YorkShen, > > > On Nov 1, 2019, at 10:33 AM, 申远 wrote: > > > > Hi, Justin. > > > > After serious thinking these days, I decided to withindraw the graduation > > vote. We need spend more time in Incubator, this graduation vote is a > > little hurry. > > > > I admitted your concerns about diverse and independent community have > some > > points, Weex still needs to impove in this apsect. > > > > For branding part, I have some reservations about it, but I will see > what I > > can do to make things better. > > I replied earlier in the thread, but the response from Weex really should > be to complete a Podling Name Search - > https://incubator.apache.org/guides/names.html < > https://incubator.apache.org/guides/names.html> > > An issue is created here - > https://issues.apache.org/jira/projects/PODLINGNAMESEARCH < > https://issues.apache.org/jira/projects/PODLINGNAMESEARCH> > > Someone on the Podling needs to do the research which should reveal any > conflicts. The VP, Brand will approve or ask questions. It may be that some > of these issues may require discussion about brand risk. Until the research > is complete it is hard to know. > > The Board is unlikely to approve graduation without the brand name being > approved by the VP, Brand. > > > > > Is there any other concerns you have about Weex towards graduation ? > > These are the two. They are important. You are to be congratulated for > overcoming the LGPL issue! > > > > FYI: Weex needs more active mentors, if possible. That would denifitely > > help. > > Regards, > Dave > > > > Best Regards, > > YorkShen > > > > 申远 > > > > > > ซ่อยค่อย ลืมเขาแน่ <0989132858...@gmail.com> 于2019年10月30日周三 下午9:20写道： > > > >> เมื่อ 30 ต.ค. 2019 7:52 PM "申远" เขียนว่า > >> > >>> FYI: If the initial committers really matter, maybe we could ask > >> secretary > >>> to help us find out how many individuals signed the ICLA when Weex > >> entered > >>> the Incubator. > >>> > >>> Best Regards, > >>> YorkShen > >>> > >>> 申远 > >>> > >>> > >>> ซ่อยค่อย ลืมเขาแน่ <0989132858...@gmail.com> 于2019年10月30日周三 下午8:35写道： > >>> > >>>> เมื่อ 30 ต.ค. 2019 7:16 PM "申远" เขียนว่า > >>>> > >>>>>> > >>>>>> The PPMC needs to protect their brand in particular from their own > >>>>> company. > >>>>> > >>>>> > >>>>> Agree with that, and this is exactly why I am persuading project like > >>>>> Weex-UI [1] donated to ASF instead of making them changing their name > >>> to > >>>>> "XXX powered by Apache Weex" and then pretend there is no problem. > >>>>> > >>>>> Anyone on the Initial list are committers I assume you mean they see > >>> not > >>>>>> contributing? > >>>>>> > >>>>> > >>>>> No, some [2] of them are never committers of Weex according to our > >>>> whimsy. > >>>>> For example, the top 2 names on the initial developer list are not > >>>>> committers of Weex according to whimsy and they didn't contribute, of > >>>>> course. Some of other names, like me, are also on the initial > >> developer > >>>>> list, but I was actually elected as Weex committer four months after > >> it > >>>>> into incubator. There is a vote for nominating me as a Weex committer > >>>> [3]. > >>>>> I don't know what happened here, as I am not the initial committer in > >>&
Re: [VOTE] Graudate Apache Weex (Incubating) as a Top Level Project
Hi, Justin. After serious thinking these days, I decided to withindraw the graduation vote. We need spend more time in Incubator, this graduation vote is a little hurry. I admitted your concerns about diverse and independent community have some points, Weex still needs to impove in this apsect. For branding part, I have some reservations about it, but I will see what I can do to make things better. Is there any other concerns you have about Weex towards graduation ? FYI: Weex needs more active mentors, if possible. That would denifitely help. Best Regards, YorkShen 申远 ซ่อยค่อย ลืมเขาแน่ <0989132858...@gmail.com> 于2019年10月30日周三 下午9:20写道： > เมื่อ 30 ต.ค. 2019 7:52 PM "申远" เขียนว่า > > > FYI: If the initial committers really matter, maybe we could ask > secretary > > to help us find out how many individuals signed the ICLA when Weex > entered > > the Incubator. > > > > Best Regards, > > YorkShen > > > > 申远 > > > > > > ซ่อยค่อย ลืมเขาแน่ <0989132858...@gmail.com> 于2019年10月30日周三 下午8:35写道： > > > > > เมื่อ 30 ต.ค. 2019 7:16 PM "申远" เขียนว่า > > > > > > > > > > > > > The PPMC needs to protect their brand in particular from their own > > > > company. > > > > > > > > > > > > Agree with that, and this is exactly why I am persuading project like > > > > Weex-UI [1] donated to ASF instead of making them changing their name > > to > > > > "XXX powered by Apache Weex" and then pretend there is no problem. > > > > > > > > Anyone on the Initial list are committers I assume you mean they see > > not > > > > > contributing? > > > > > > > > > > > > > No, some [2] of them are never committers of Weex according to our > > > whimsy. > > > > For example, the top 2 names on the initial developer list are not > > > > committers of Weex according to whimsy and they didn't contribute, of > > > > course. Some of other names, like me, are also on the initial > developer > > > > list, but I was actually elected as Weex committer four months after > it > > > > into incubator. There is a vote for nominating me as a Weex committer > > > [3]. > > > > I don't know what happened here, as I am not the initial committer in > > > fact. > > > > But the initial developer list [2] is incorrect, I'm sure about that. > > > > > > > > [1] > > > > https://lists.apache.org/thread.html/ab1cdf009697ac261e10c8963ed9ad > > > > fe226edeee056f0c7dabb780c0@%3Cdev.weex.apache.org%3E > > > > [2] > > > > https://lists.apache.org/thread.html/b53537fea384f1d75c9921f71e13d1 > > > > 7780381504cff971e5f18bda96@%3Cgeneral.incubator.apache.org%3E > > > > [3] > > > > https://lists.apache.org/thread.html/8ebbd2fb5fb85c1da4328685859ae1 > > > > bb365a8b6253772c9e06940a39@%3Cprivate.weex.apache.org%3E > > > > > > > > Best Regards, > > > > YorkShen > > > > > > > > 申远 > > > > > > > > > > > > Justin Mclean 于2019年10月30日周三 下午7:32写道： > > > > > > > > > Hi, > > > > > > > > > > It seems like there are two concerns around Weex, branding and > > > > independent > > > > > > community. > > > > > > > > > > > > > > > > I'd still like to hear what your mentors think. Are they active? > > > > > > > > > > For branding part, I understand this is a serious issue, and it > takes > > > me > > > > > > months to solve this kinds of issues > > > > > > > > > > > > > > > > This needs to be the PPMC not just you. I chose some of those links > > on > > > > > purpose as they belong to the company they belong to. The PPMC > needs > > to > > > > > protect their brand in particular from their own company. > > > > > > > > > >- Though there are 13 committers according to the initial > proposal > > > > [5], > > > > > >but many of them are not committers today. > > > > > > > > > > > > > > > Anyone on the Initial list are committers I assume you mean they > see > > > not > > > > > contributing? > > > > > > > > > > Just take the committers on the initial proposal as an inacurrate > > > > records, > > > > > > there are some mistakes on this list. > > > > > > > > > > > > > > > This seems concerning. > > > > > > > > > > > > > > > > >- There are developers out of the comany make their own tools > > > around > > > > > >Weex > > > > > > > > > > > > > > > > Which is great but they are external to the project. Whats the > > barriers > > > > (if > > > > > any) that stopped them from doing this development inside the > > project? > > > > > > > > > > Thanks, > > > > > Justin > > > > > > > > > > > > > > >
Re: [VOTE] Graudate Apache Weex (Incubating) as a Top Level Project
FYI: If the initial committers really matter, maybe we could ask secretary to help us find out how many individuals signed the ICLA when Weex entered the Incubator. Best Regards, YorkShen 申远 ซ่อยค่อย ลืมเขาแน่ <0989132858...@gmail.com> 于2019年10月30日周三 下午8:35写道： > เมื่อ 30 ต.ค. 2019 7:16 PM "申远" เขียนว่า > > > > > > > The PPMC needs to protect their brand in particular from their own > > company. > > > > > > Agree with that, and this is exactly why I am persuading project like > > Weex-UI [1] donated to ASF instead of making them changing their name to > > "XXX powered by Apache Weex" and then pretend there is no problem. > > > > Anyone on the Initial list are committers I assume you mean they see not > > > contributing? > > > > > > > No, some [2] of them are never committers of Weex according to our > whimsy. > > For example, the top 2 names on the initial developer list are not > > committers of Weex according to whimsy and they didn't contribute, of > > course. Some of other names, like me, are also on the initial developer > > list, but I was actually elected as Weex committer four months after it > > into incubator. There is a vote for nominating me as a Weex committer > [3]. > > I don't know what happened here, as I am not the initial committer in > fact. > > But the initial developer list [2] is incorrect, I'm sure about that. > > > > [1] > > https://lists.apache.org/thread.html/ab1cdf009697ac261e10c8963ed9ad > > fe226edeee056f0c7dabb780c0@%3Cdev.weex.apache.org%3E > > [2] > > https://lists.apache.org/thread.html/b53537fea384f1d75c9921f71e13d1 > > 7780381504cff971e5f18bda96@%3Cgeneral.incubator.apache.org%3E > > [3] > > https://lists.apache.org/thread.html/8ebbd2fb5fb85c1da4328685859ae1 > > bb365a8b6253772c9e06940a39@%3Cprivate.weex.apache.org%3E > > > > Best Regards, > > YorkShen > > > > 申远 > > > > > > Justin Mclean 于2019年10月30日周三 下午7:32写道： > > > > > Hi, > > > > > > It seems like there are two concerns around Weex, branding and > > independent > > > > community. > > > > > > > > > > I'd still like to hear what your mentors think. Are they active? > > > > > > For branding part, I understand this is a serious issue, and it takes > me > > > > months to solve this kinds of issues > > > > > > > > > > This needs to be the PPMC not just you. I chose some of those links on > > > purpose as they belong to the company they belong to. The PPMC needs to > > > protect their brand in particular from their own company. > > > > > >- Though there are 13 committers according to the initial proposal > > [5], > > > >but many of them are not committers today. > > > > > > > > > Anyone on the Initial list are committers I assume you mean they see > not > > > contributing? > > > > > > Just take the committers on the initial proposal as an inacurrate > > records, > > > > there are some mistakes on this list. > > > > > > > > > This seems concerning. > > > > > > > > > > >- There are developers out of the comany make their own tools > around > > > >Weex > > > > > > > > > > Which is great but they are external to the project. Whats the barriers > > (if > > > any) that stopped them from doing this development inside the project? > > > > > > Thanks, > > > Justin > > > > > >
Re: [VOTE] Graudate Apache Weex (Incubating) as a Top Level Project
> > The PPMC needs to protect their brand in particular from their own company. Agree with that, and this is exactly why I am persuading project like Weex-UI [1] donated to ASF instead of making them changing their name to "XXX powered by Apache Weex" and then pretend there is no problem. Anyone on the Initial list are committers I assume you mean they see not > contributing? > No, some [2] of them are never committers of Weex according to our whimsy. For example, the top 2 names on the initial developer list are not committers of Weex according to whimsy and they didn't contribute, of course. Some of other names, like me, are also on the initial developer list, but I was actually elected as Weex committer four months after it into incubator. There is a vote for nominating me as a Weex committer [3]. I don't know what happened here, as I am not the initial committer in fact. But the initial developer list [2] is incorrect, I'm sure about that. [1] https://lists.apache.org/thread.html/ab1cdf009697ac261e10c8963ed9adfe226edeee056f0c7dabb780c0@%3Cdev.weex.apache.org%3E [2] https://lists.apache.org/thread.html/b53537fea384f1d75c9921f71e13d17780381504cff971e5f18bda96@%3Cgeneral.incubator.apache.org%3E [3] https://lists.apache.org/thread.html/8ebbd2fb5fb85c1da4328685859ae1bb365a8b6253772c9e06940a39@%3Cprivate.weex.apache.org%3E Best Regards, YorkShen 申远 Justin Mclean 于2019年10月30日周三 下午7:32写道： > Hi, > > It seems like there are two concerns around Weex, branding and independent > > community. > > > > I'd still like to hear what your mentors think. Are they active? > > For branding part, I understand this is a serious issue, and it takes me > > months to solve this kinds of issues > > > > This needs to be the PPMC not just you. I chose some of those links on > purpose as they belong to the company they belong to. The PPMC needs to > protect their brand in particular from their own company. > >- Though there are 13 committers according to the initial proposal [5], > >but many of them are not committers today. > > > Anyone on the Initial list are committers I assume you mean they see not > contributing? > > Just take the committers on the initial proposal as an inacurrate records, > > there are some mistakes on this list. > > > This seems concerning. > > > > >- There are developers out of the comany make their own tools around > >Weex > > > > Which is great but they are external to the project. Whats the barriers (if > any) that stopped them from doing this development inside the project? > > Thanks, > Justin >
Re: [VOTE] Graudate Apache Weex (Incubating) as a Top Level Project
It seems like there are two concerns around Weex, branding and independent community. For branding part, I understand this is a serious issue, and it takes me months to solve this kinds of issues, like donating weex-loader[1], weex-cli [2] to ASF, upgrading POM meta [3], changing package name [4], etc.. Again, there are over 1 million pages of Weex in Google, I can't promosie all of them are fine(without branding issue). And due to the fact that Weex once belongs to a company, not ASF, there are some NPM/POM publishing records reflects that Weex once belongs to a commnay, and I can't undo or delete that history. But we shall fix the brand issues once we know it, maybe we could also write down a brand protection procedure. For independent community part, I think there are two issues need to solve, and two issues to make it clear. - Many committers were coming from the same company, though some of them (3 or 4, including some 2 PPMC members) have resigned from the commany. But still to many, I guess. - We used to ignore the difference between committers and PPMC members, that's reason why so many new committers and so less PPMC members. We are tyring to fix this issue by inviting all committers to Weex PMC during its graduaiton procedure. But we could fix it in another way, if its' needed. - Though there are 13 committers according to the initial proposal [5], but many of them are not committers today. Even me, listed as an inital commiter of Weex, but actually joined Weex community 4 months aftter its into the incubator. Just take the committers on the initial proposal as an inacurrate records, there are some mistakes on this list. Actually, if you considered fact that Weex Joined the Incubator in Dec, 2016, there are 4 committer account created at that time [6]. So I guess the four of them are actually the inital committers(or PPMC members), rest of them are not (including me). - There are developers out of the comany make their own tools around Weex, and try to donate it to Weex. Currently, we're trying to encourage them to go through the IP clearance procedure and then nominate them as committer [7]. I guess this is some kinds of proof for independency, or diverse and active community at least. [1] https://incubator.apache.org/ip-clearance/weex_loader.html [2] https://incubator.apache.org/ip-clearance/weex_cli.html [3] https://bintray.com/weex/Android/sdk [4] https://weex.apache.org/download/major_change.html#_0-28 [5] https://lists.apache.org/thread.html/b53537fea384f1d75c9921f71e13d17780381504cff971e5f18bda96@%3Cgeneral.incubator.apache.org%3E [6] https://whimsy.apache.org/roster/ppmc/weex [7] https://mail-archives.apache.org/mod_mbox/weex-dev/201910.mbox/%3Ctencent_EA5069E21326C37D64F20CC18D885B3BAE05%40qq.com%3E Best Regards, YorkShen 申远 Justin Mclean 于2019年10月29日周二 下午4:04写道： > Hi, > > If the project can show they are acting independently of a single company > that would help them convince the board/IPMC they can graduate. What has > the project done to attract developers out side of that company to work on > the project? > > Are there any barriers that hinders outside involvement? e.g. off list or > internal communication or having synchronous meetings can be an issue. (I > don’t know this is happening on this project. These are just suggestions to > the type of things that might hinder outside involvement.) > > Of the committers voted in during incubation, do all work for the same > company? Could any be considered as candidates for PPMC membership? > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Graudate Apache Weex (Incubating) as a Top Level Project
> > 1. I’m a little confused the email says " 11 PPMC members, 8 committers”, > 11+8 == 19 where have the extras come from? (3 mentors?) Yes, three of them are mentors. 2. You also didn’t answer how many PMC members you have added during > incubation. According to the whimsy page of Weex, there are 5 committers' account created at the day of Weex donated to ASF, so, I guess we added 21-3(mentors)-5 = 13 committers(including PPMC) 3. I also notice 2 of your PPMC are not signed up to your price list is it > expected that these be on the initial list of PMC members They are initial committer/PPMC of Weex, and I can't get in touched for a long time(over a year). Based on "merit doesn't expire" rule, I think we'd better keep them as they are. 4. I see by you reply some work needs to be done here and I suggest you > also read those branding and trademark links. Most of them are fine, but there is some work to be done. I guess one week would be enough. I can't guarantee all pages in the WWW(things you can google) doesn't violate the brand of ASF, as there are over 1 million pages of Weex in Google search. But I could check top 20 or 30 pages of Google search to make sure they doesn't violate the brand of ASF, and we will try to solve any problems that reported to Weex PPMC. Best Regards, YorkShen 申远 Justin Mclean 于2019年10月28日周一 下午5:31写道： > Hi, > > > I also notice 2 of your PPMC are not signed up to your price list is it > expected that these be on the initial list of PMC members? > > Thanks autocorrect :-) I meant to say “are not signed up to your private > list”. > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [DISCUSS] Maven account for publishing convience binary
Just add maven distribution in link [2]. I'm glad if someone could reword the content for me, as I am not a native English speaker. Best Regards, YorkShen 申远 Justin Mclean 于2019年10月16日周三 上午11:52写道： > Hi, > > > Could you please considering add Jcenter/MavenCentral in the list? Or > could > > I adding Jcenter/MavenCentral related page myself if you agree? > > You're welcome to add something. > > Thanks, > Justin > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Graudate Apache Weex (Incubating) as a Top Level Project
> > How many PMC members and committer have been added since starting > graduation? > According to whismy page of Weex, there are 23 committer(including PPMC member) of Weex. Considering the fact that there are around 200 contributors, 10% of them are committers, I think this is a normal situation(maybe other projects have higher percent of committers?), IMO. A quick search showed that there is also some branding/trademark issues > with these pages: > I can explain them one by, if this is needed. - https://github.com/weexteam This Github organization is created before Weex donation, and as you can see, most of the projects in this organization is archived, which means they are no longer maintained by the original authors, and the rest of them have proper name. I can delete this organization (After some negotiation, I am admin of the organization now) if it's needed. But someone else we don't know may create it again without our control. - https://developer.alibabacloud.com/opensource/project/weex This is a just introduction page of Weex in someone else's server, I don't see anything violate the brand of ASF. And a URL contained weex in a third-party server is not a problem(also far more beyond our control), IMO. - https://www.npmjs.com/package/weex-ui The author of the repo agree to donate [2] it to ASF, and I'm helping them in IP clearance procdure. - https://cocoapods.org/pods/WeexSDK *I agree with you*, there are some branding problems in this page, I will see what I can do. - https://bintray.com/alibabaweex/maven/weex_sdk/view This is the pom artificat of Weex before , and we're using a new address now [3]. I can add some exlanplation to address, but I can't change what is published. - https://natjs.com/#/ Another third-party project, and I don't see any problem here. Its name has nothing to do with Weex, and its introduction page "A powerful kit for adding native functionalities to your weex app." is fine to me, IMO. - https://github.com/natjs/nat Same above. - https://github.com/tralves/weex-todo-list Another third-party project, Its name has nothing to do with Weex, and its introduction page "A demo to-do list app, powered by Weex and Vue." is fine to me, IMO. - http://dotwe.org/vue We have marked it as third party in our website. [1] https://whimsy.apache.org/roster/ppmc/weex [2] https://mail-archives.apache.org/mod_mbox/weex-dev/201910.mbox/%3Ctencent_52455495A38322341536DC76283B69A47607%40qq.com%3E [3] https://bintray.com/weex/Android/sdk [4] https://weex.apache.org/tools/dotwe.html Best Regards, YorkShen 申远 Justin Mclean 于2019年10月26日周六 上午1:16写道： > Hi, > > > - There are 11 PPMC members, 8 committers (excluding PPMC members) [2], > > and 192 Github contributors [3] > > How many PMC members and committer have been added since starting > graduation? > > Having 200 odd contributors and only 8 committers seems like it could be > an issue to me. > > Name wise these may be issues: > https://play.google.com/store/apps/details?id=mx.weex.ss=en_US > https://apkpure.com/weex-wallet/mx.weex.appwallet > https://apps.apple.com/us/app/weex/id1036040019 > http://weex.mx > > A quick search showed that there is also some branding/trademark issues > with these pages: > https://github.com/weexteam > https://developer.alibabacloud.com/opensource/project/weex > https://www.npmjs.com/package/weex-ui > https://cocoapods.org/pods/WeexSDK > https://bintray.com/alibabaweex/maven/weex_sdk/view > https://natjs.com/#/ > https://github.com/natjs/nat > https://github.com/tralves/weex-todo-list > http://dotwe.org/ > (and others!) > > Until we have seen the actual proposal there may be other issues. For > instance we would need to know the makeup of the new PMC. > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [PROPOSAL] sparklyr
You could also read the documentation[1] here about what license is allowed in ASF project. [1] https://apache.org/legal/resolved.html#category-a Best Regards, YorkShen 申远 申远 于2019年10月22日周二 下午2:49写道： > Base on my experience (wearing my Apache Weex's hat), GPL/LGPL dependency > is not compatible with ASF's policy, and you may want to fix the License > problem at the beginning, even before into Incubator. Otherwise, GPL/LGPL > dependency will give you a lot of pain than you'd ever expect. > > Best Regards, > YorkShen > > 申远 > > > Javier Luraschi 于2019年10月22日周二 上午2:55写道： > >> Regarding licenses, dplyr is under MIT, see: >> https://github.com/tidyverse/dplyr/blob/master/LICENSE.md. However, other >> packages are under GPL2. >> >> Here are all the packages that sparklyr currently depends on and their >> associated license (This was retrieved from >> https://CRAN.R-project.org/package=, since R package repo >> (CRAN) requires their license to be clearly defined). >> >> assertthat: GPL-3 >> base64enc: GPL-2 | GPL-3 >> config: GPL-3 >> DBI: LGPL-2 | LGPL-2.1 | LGPL-3 >> dplyr: MIT >> dbplyr: MIT >> digest: GPL-2 | GPL-3 >> forge: Apache >> generics: GPL-2 >> httr: MIT >> jsonlite: MIT >> openssl: MIT >> purrr: GPL-3 >> r2d3: BSD-3 >> rappdirs: MIT >> rlang: GPL-3 >> rprojroot: GPL-3 >> rstudioapi: MIT >> tibble: MIT >> tidyr: MIT >> withr: GPL-2 | GPL-3 >> xml2: GPL-2 | GPL-3 >> ellipsis: GPL-3 >> >> >> On Mon, Oct 21, 2019 at 1:12 AM Justin Mclean >> wrote: >> >> > Hi, >> > >> > I also concerned that the initial committer list only contains 3 >> > committers. Why have you not included others in the community that have >> > made contributions? >> > >> > I don’t know if this is an issue or not but bring it up just in case you >> > not aware. I can see that some of the tidyverse packages are under GPL2, >> > the GPL license is not compatible with the ALv2. I’m not 100% sure what >> > license dplyr is under. I can see that sparkly depends on several (10+) >> GPL >> > licensed pieces of software. Do you see this causing any issue as GPL >> code >> > can’t be included in an Apache source release and can’t be a >> non-optional >> > dependancy of an ASF project. Have you discussed this with your >> champion or >> > proposed mentors and have they flagged this as a possible issue? >> > >> > I can see that one of the proposed mentors is not an IPMC member (which >> is >> > required) and another seems not very active in signing off reports or >> > voting on releases. Did you think the existing mentors will provide your >> > project with enough support? >> > >> > Thanks, >> > Justin >> > >> > 1. https://github.com/tidyverse/dplyr/blob/master/LICENSE >> > - >> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> > For additional commands, e-mail: general-h...@incubator.apache.org >> > >> > >> >
Re: [PROPOSAL] sparklyr
Base on my experience (wearing my Apache Weex's hat), GPL/LGPL dependency is not compatible with ASF's policy, and you may want to fix the License problem at the beginning, even before into Incubator. Otherwise, GPL/LGPL dependency will give you a lot of pain than you'd ever expect. Best Regards, YorkShen 申远 Javier Luraschi 于2019年10月22日周二 上午2:55写道： > Regarding licenses, dplyr is under MIT, see: > https://github.com/tidyverse/dplyr/blob/master/LICENSE.md. However, other > packages are under GPL2. > > Here are all the packages that sparklyr currently depends on and their > associated license (This was retrieved from > https://CRAN.R-project.org/package=, since R package repo > (CRAN) requires their license to be clearly defined). > > assertthat: GPL-3 > base64enc: GPL-2 | GPL-3 > config: GPL-3 > DBI: LGPL-2 | LGPL-2.1 | LGPL-3 > dplyr: MIT > dbplyr: MIT > digest: GPL-2 | GPL-3 > forge: Apache > generics: GPL-2 > httr: MIT > jsonlite: MIT > openssl: MIT > purrr: GPL-3 > r2d3: BSD-3 > rappdirs: MIT > rlang: GPL-3 > rprojroot: GPL-3 > rstudioapi: MIT > tibble: MIT > tidyr: MIT > withr: GPL-2 | GPL-3 > xml2: GPL-2 | GPL-3 > ellipsis: GPL-3 > > > On Mon, Oct 21, 2019 at 1:12 AM Justin Mclean > wrote: > > > Hi, > > > > I also concerned that the initial committer list only contains 3 > > committers. Why have you not included others in the community that have > > made contributions? > > > > I don’t know if this is an issue or not but bring it up just in case you > > not aware. I can see that some of the tidyverse packages are under GPL2, > > the GPL license is not compatible with the ALv2. I’m not 100% sure what > > license dplyr is under. I can see that sparkly depends on several (10+) > GPL > > licensed pieces of software. Do you see this causing any issue as GPL > code > > can’t be included in an Apache source release and can’t be a non-optional > > dependancy of an ASF project. Have you discussed this with your champion > or > > proposed mentors and have they flagged this as a possible issue? > > > > I can see that one of the proposed mentors is not an IPMC member (which > is > > required) and another seems not very active in signing off reports or > > voting on releases. Did you think the existing mentors will provide your > > project with enough support? > > > > Thanks, > > Justin > > > > 1. https://github.com/tidyverse/dplyr/blob/master/LICENSE > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > >
Re: Remove PMC incubator page
+1 Fine by me. Best Regards, YorkShen 申远 Paul King 于2019年10月18日周五 下午6:11写道： > +1 > > On Fri, Oct 18, 2019 at 6:59 PM Justin Mclean > wrote: > > > Hi, > > > > The page here [1] doesn’t really add anything that is not written out > > elsewhere and seems redundant. If no-one objects I’ll remove it. > > > > Thanks, > > Justin > > > > > > 1. https://incubator.apache.org/guides/pmc.html > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > >
[Vote] Release Apache Weex (Incubating) 0.28.0-RC1
Hi, folks The Apache Weex community has voted and approved the proposal to release Apache Weex (Incubating) version 0.28.0-RC1, we now kindly request the Incubator PMC members to review and vote on this incubator release. - Vote thread: https://lists.apache.org/thread.html/3b56f8ceb75981487de107c90995de27ebfa9ff9acfb0e16ca07cc55@%3Cdev.weex.apache.org%3E - Vote result thread: https://lists.apache.org/thread.html/7df08b9020fc11c0cb01b15faea16207cb791314ef993ab73a9b2721@%3Cdev.weex.apache.org%3 <https://lists.apache.org/thread.html/7df08b9020fc11c0cb01b15faea16207cb791314ef993ab73a9b2721@%3Cdev.weex.apache.org%3E> - Git tag for this Release: https://github.com/apache/incubator-weex/releases/tag/0.28.0-RC1 - The source tarball could be found at : https://dist.apache.org/repos/dist/dev/incubator/weex/0.28.0/RC1/apache-weex-incubating-0.28.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.28.0/RC1/apache-weex-incubating-0.28.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.28.0/RC1/apache-weex-incubating-0.28.0-RC1-src.tar.gz.sha512 - The source tarball is signed with Key:D7E6B58FFA293FB1AC9E7B624FD8BC09C7E9DB81, which could be found in the key file: https://dist.apache.org/repos/dist/release/incubator/weex/KEYS - ChangeLog about this version: https://github.com/apache/incubator-weex/blob/release/0.28/CHANGELOG.md One can build the binary from source according to https://github.com/apache/incubator-weex/blob/release/0.28/HOW-TO-BUILD.md with build environment installed. *FYI: I only test the build scripts on Mac environment, it should also work in Linux/Unit platform according to my understanding. But you may get problems if you try to build Weex from source on a windows platform.* This vote will remain open for at least 72 hours, until we get enough votes. Please vote on releasing this RC. - +1 approve - +0 no opinion - -1 disapprove (and reason why) Best Regards, YorkShen 申远
Re: [IP CLEARANCE] Apache NetBeans - dukescript presenters
+ 1 Much better. Take your time and no need to hurry, you have 72 hours after. Eric Barboni 于2019年10月17日 周四00:16写道： > Maybe I should had sentence like that: > > Identify name recorded for software grant: Dukehoff GmbH > And transmitted to the pmc via this link > > https://lists.apache.org/thread.html/5fb0512323d0e12725141d68eb65f6affa8d99d8025c7ea0bd345474@%3Cprivate.netbeans.apache.org%3E > > Best Regards > Eric > PS > No time today to regenerate the form, will append ASAP if that's what is > needed > > -Message d'origine- > De : 申远 > Envoyé : mercredi 16 octobre 2019 14:16 > À : general@incubator.apache.org > Objet : Re: [IP CLEARANCE] Apache NetBeans - dukescript presenters > > > > > Dukehoff GmbH Anton Epple is the inceptor of thoose utilities and > > employee of Dukehoff GmbH > > > Does this mean the company of Dukehoff GmbH hold the IP and do we need SGA > here? > > Best Regards, > YorkShen > > 申远 > > > York Shen 于2019年10月16日周三 下午7:06写道： > > > If my memory was right, you could disclose the link of your reception > > as individuals without the proper right will not be able to open the > link. > > Everything is safe. > > > > Correct me if I am wrong. > > > > Best Regards, > > York Shen > > > > 申远 > > > > 2019年10月16日 18:52，Eric Barboni 写道： > > > > Hi > > Not sure if I have to do something. > > But secretary give us feedback on our private list for reception of > files. > > But should not be disclose I guess. > > I have no access to secretary ml, so cannot help. > > > > Best Regards > > Eric > > -Message d'origine- > > De : Matt Sicker > > Envoyé : mercredi 16 octobre 2019 06:30 À : > > general@incubator.apache.org Objet : Re: [IP CLEARANCE] Apache > > NetBeans - dukescript presenters > > > > There should be an automatic email receipt of the secretary filing the > doc. > > > > On Tue, Oct 15, 2019 at 23:02, 申远 wrote: > > > > Not sure SGA is required in this situation as it seems like there is > > an employment in Dukehoff GmbH. > > > > FYI: Add the link about the communication with secretary would be a > > great, which gives an individual to look into what's happening if > > he/she has the privilege in secretary@asf mailing list. > > > > Best Regards, > > YorkShen > > > > 申远 > > > > > > Eric Barboni 于2019年10月15日周二 下午10:49写道： > > > > Hi community > > > > Apache NetBeans received a donation called dukescript presenters. > > This donation goes in the Apache NetBeans html4j subproject. > > > > Form for ip clearance is here : > > > > > > https://incubator.apache.org/ip-clearance/netbeans-dukescript-presente > > rs.htm > > > > l > > I had issue to regenerate the page please note that PR link is the > > following > > > > https://github.com/apache/netbeans-html4j/pull/23 > > Commit id if needed > > > > > > https://github.com/apache/netbeans-html4j/commit/383122eb00479d12b8df1 > > 810c26 > > > > e7596fa0672d0 > > < > > > > https://github.com/apache/netbeans-html4j/commit/383122eb00479d12b8df1 > > 810c26e7596fa0672d0 > > > > > > > > > > Please vote to approve this contribution. Lazy consensus applies: If > > no > > > > -1, > > > > votes are being cast within the next 72 hours, the vote passes. > > > > Best Regards > > Eric > > > > > > > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > -- > > Matt Sicker > > > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Best Regards York Shen 申远
Re: [IP CLEARANCE] Apache NetBeans - dukescript presenters
> > Dukehoff GmbH Anton Epple is the inceptor of thoose utilities and employee > of Dukehoff GmbH Does this mean the company of Dukehoff GmbH hold the IP and do we need SGA here? Best Regards, YorkShen 申远 York Shen 于2019年10月16日周三 下午7:06写道： > If my memory was right, you could disclose the link of your reception as > individuals without the proper right will not be able to open the link. > Everything is safe. > > Correct me if I am wrong. > > Best Regards, > York Shen > > 申远 > > 2019年10月16日 18:52，Eric Barboni 写道： > > Hi > Not sure if I have to do something. > But secretary give us feedback on our private list for reception of files. > But should not be disclose I guess. > I have no access to secretary ml, so cannot help. > > Best Regards > Eric > -Message d'origine- > De : Matt Sicker > Envoyé : mercredi 16 octobre 2019 06:30 > À : general@incubator.apache.org > Objet : Re: [IP CLEARANCE] Apache NetBeans - dukescript presenters > > There should be an automatic email receipt of the secretary filing the doc. > > On Tue, Oct 15, 2019 at 23:02, 申远 wrote: > > Not sure SGA is required in this situation as it seems like there is > an employment in Dukehoff GmbH. > > FYI: Add the link about the communication with secretary would be a > great, which gives an individual to look into what's happening if > he/she has the privilege in secretary@asf mailing list. > > Best Regards, > YorkShen > > 申远 > > > Eric Barboni 于2019年10月15日周二 下午10:49写道： > > Hi community > > Apache NetBeans received a donation called dukescript presenters. > This donation goes in the Apache NetBeans html4j subproject. > > Form for ip clearance is here : > > > https://incubator.apache.org/ip-clearance/netbeans-dukescript-presente > rs.htm > > l > I had issue to regenerate the page please note that PR link is the > following > > https://github.com/apache/netbeans-html4j/pull/23 > Commit id if needed > > > https://github.com/apache/netbeans-html4j/commit/383122eb00479d12b8df1 > 810c26 > > e7596fa0672d0 > < > > https://github.com/apache/netbeans-html4j/commit/383122eb00479d12b8df1 > 810c26e7596fa0672d0 > > > > > Please vote to approve this contribution. Lazy consensus applies: If > no > > -1, > > votes are being cast within the next 72 hours, the vote passes. > > Best Regards > Eric > > > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > > > -- > Matt Sicker > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > >
Re: [IP CLEARANCE] Apache NetBeans - dukescript presenters
Not sure SGA is required in this situation as it seems like there is an employment in Dukehoff GmbH. FYI: Add the link about the communication with secretary would be a great, which gives an individual to look into what's happening if he/she has the privilege in secretary@asf mailing list. Best Regards, YorkShen 申远 Eric Barboni 于2019年10月15日周二 下午10:49写道： > Hi community > > Apache NetBeans received a donation called dukescript presenters. This > donation goes in the Apache NetBeans html4j subproject. > > Form for ip clearance is here : > > https://incubator.apache.org/ip-clearance/netbeans-dukescript-presenters.htm > l > I had issue to regenerate the page please note that PR link is the > following > > https://github.com/apache/netbeans-html4j/pull/23 > Commit id if needed > > https://github.com/apache/netbeans-html4j/commit/383122eb00479d12b8df1810c26 > e7596fa0672d0 > <https://github.com/apache/netbeans-html4j/commit/383122eb00479d12b8df1810c26e7596fa0672d0> > > > Please vote to approve this contribution. Lazy consensus applies: If no -1, > votes are being cast within the next 72 hours, the vote passes. > > Best Regards > Eric > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [DISCUSS] Maven account for publishing convience binary
Hi, Justin. I just read the link [2] you provided, and I think it is just what I need. Could you please considering add Jcenter/MavenCentral in the list? Or could I adding Jcenter/MavenCentral related page myself if you agree? FYI: Jcenter and MavenCentral are both maven distribution channel, except for JCenter is widely used in Android world, and MavenCentral is for Java world except Android. Best Regards, YorkShen 申远 申远 于2019年9月30日周一 下午9:11写道： > > Thanks, I shall check the link before publishing convenience binary. > > Justin Mclean 于2019年9月30日 周一19:58写道： > >> Hi, >> >> > [1] https://bintray.com/cordova/maven/cordova-android >> > [2] >> https://bintray.com/bintray/jcenter/org.apache.commons:commons-lang3 >> >> There a few branding and trademark issues on those pages, I would suggest >> you read this before copying what those projects are doing. [1] >> >> While we don’t have official guidance on this (yet) I suggest you also >> take a look at [2] and this legal JIRA [3], if it’s not clear ask your >> mentors for help. >> >> Thanks, >> Justin >> >> 1. https://www.apache.org/foundation/marks/resources >> 2. >> https://cwiki.apache.org/confluence/display/INCUBATOR/DistributionGuidelines >> 3. https://issues.apache.org/jira/browse/LEGAL-427 >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> -- > Best Regards, > YorkShen > > 申远 >
Re: Podlings & IP Clearance
Hi As a PPMC member of Weex, I didn’t find any documentation about the IP clearance process for Podlling project, so I just followed what other PPMC did after asking in this mailing list [4]. I am Ok to do it in another way if it’s written in the documentation clearly. IMO, the problem here is that we don’t have an IP clearance process for podllings, so podllings have no other way but follow the standard IP process of TLP project. [4] https://mail-archives.apache.org/mod_mbox/incubator-general/201909.mbox/%3cdaee7cd2-c05a-4a09-867c-37f1c1b19...@classsoftware.com%3e Dave Fisher 于2019年10月4日 周五13:18写道： > Hi - > > > On Oct 3, 2019, at 9:12 PM, Justin Mclean > wrote: > > > > Hi, > > > >> The recent vote from Weex [1] made me think about the IP Clearance > >> process. Per [2], podlings should not follow this process and instead > are > >> directed to look at [3]. > > > > I always assumed that that was advised about the initial codebase and > don’t see an issue with following [2] past that. It certainly could be made > clearer. > > I’ve always considered it to be the mentor’s job to assure IP was > considered for podlings donations. > > A greybeard told me recently that the board added IP clearance to the IPMC > for TLPs > > Regards, > Dave > > > > > Thanks, > > Justin > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Best Regards York Shen 申远
[Result] [IP CLEARANCE] Weex Loader
72 hours passed, and we got no -1 vote. Based on lazy consensus, the vote [1] has passed successfully. [1] https://lists.apache.org/x/thread.html/2e29ee2ead47c9242e0ae8b40b67a254a98cac0e5a9fdfb8ab089e28@%3Cgeneral.incubator.apache.org%3E Best Regards York Shen 申远 -- Best Regards, YorkShen 申远
Re: [IP CLEARANCE] Apache Weex - Weex Loader
After 72 hours, the vote has passed successfully based on lazy consensus York Shen 于2019年9月30日 周一14:58写道： > The hyperlink in the previous mail is somehow wrong, please copy and paste > the URL to your browser mannually if you are interested about the IP > clearance. > > Best Regards, > York Shen > > 申远 > > 在 2019年9月30日，14:55，申远 写道： > > Hi community, > > Apache Weex received an another donation called Weex Loader soon after > Weex CLI[1] donated to ASF. > > Weex Loader is a loader of webpack that can transform *.vue file into a > plain javascript module for Android and iOS platform. In other words, it's > a compiler for compiling .vue file to .js file. > > The IP clearance form can be found at: > https://incubator.apache.org/ip-clearance/weex_loader.html > <https://incubator.apache.org/ip-clearance/weex_cli.html> once the > website updates. > One can view the xml version at: > https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/weex_loader.xml > <https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/weex_cli.xml> > > The git commit containing the donation can be found > https://github.com/weexteam/weex-loader/commit/83d3767d419e8ba0d28f3e16cd22ad8543f2cfac > . The git repo will be transferred to ASF at the end of the process. > > Please vote to approve this contribution. Lazy consensus applies: > If no -1, votes are being cast within the next 72 hours, the vote passes. > > [1] > https://lists.apache.org/thread.html/97e18ae60f7ae10c8c3a6111bbc64ca9bcac34fc98be90ad0ac4aaf2@%3Cgeneral.incubator.apache.org%3E > > Best Regards, > YorkShen > > 申远 > > > -- Best Regards, YorkShen 申远
Re: [DISCUSS] Maven account for publishing convience binary
Thanks, I shall check the link before publishing convenience binary. Justin Mclean 于2019年9月30日 周一19:58写道： > Hi, > > > [1] https://bintray.com/cordova/maven/cordova-android > > [2] https://bintray.com/bintray/jcenter/org.apache.commons:commons-lang3 > > There a few branding and trademark issues on those pages, I would suggest > you read this before copying what those projects are doing. [1] > > While we don’t have official guidance on this (yet) I suggest you also > take a look at [2] and this legal JIRA [3], if it’s not clear ask your > mentors for help. > > Thanks, > Justin > > 1. https://www.apache.org/foundation/marks/resources > 2. > https://cwiki.apache.org/confluence/display/INCUBATOR/DistributionGuidelines > 3. https://issues.apache.org/jira/browse/LEGAL-427 > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Best Regards, YorkShen 申远
[DISCUSS] Maven account for publishing convience binary
Hi, folks Recently, I am trying to publish convenience library of Weex to JCenter, a seperate maven repositories for Android developers. I’d like to know whether there is an Apache-wide JCenter account for publishing connivence binary. It seems like each Apache project is allowed to create their own Jcenter account [1] and publish convenience library as long as the account is shared by PMC/PPMC. Please correct me if I am wrong, otherwise I shall create a jcenter accounts shared by Weex PPMC. [1] https://bintray.com/cordova/maven/cordova-android [2] https://bintray.com/bintray/jcenter/org.apache.commons:commons-lang3 Best Regards, YorkShen 申远
[IP CLEARANCE] Apache Weex - Weex Loader
Hi community, Apache Weex received an another donation called Weex Loader soon after Weex CLI[1] donated to ASF. Weex Loader is a loader of webpack that can transform *.vue file into a plain javascript module for Android and iOS platform. In other words, it's a compiler for compiling .vue file to .js file. The IP clearance form can be found at: https://incubator.apache.org/ip-clearance/weex_loader.html <https://incubator.apache.org/ip-clearance/weex_cli.html> once the website updates. One can view the xml version at: https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/weex_loader.xml <https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/weex_cli.xml> The git commit containing the donation can be found https://github.com/weexteam/weex-loader/commit/83d3767d419e8ba0d28f3e16cd22ad8543f2cfac . The git repo will be transferred to ASF at the end of the process. Please vote to approve this contribution. Lazy consensus applies: If no -1, votes are being cast within the next 72 hours, the vote passes. [1] https://lists.apache.org/thread.html/97e18ae60f7ae10c8c3a6111bbc64ca9bcac34fc98be90ad0ac4aaf2@%3Cgeneral.incubator.apache.org%3E Best Regards, YorkShen 申远
[Result] [IP CLEARANCE] Apache Weex - Weex CLI
72 hours passed, and we got +1 vote in d...@weex.asf Based on lazy consensus, the vote [1] passed successfully. [1] https://lists.apache.org/thread.html/97e18ae60f7ae10c8c3a6111bbc64ca9bcac34fc98be90ad0ac4aaf2@%3Cgeneral.incubator.apache.org%3E Best Regards, YorkShen 申远
Re: [Vote] Release Apache Weex (Incubating) 0.26.0-RC2
> > I’m concerned that I don’t see any indication that release contains a > dependancy on Category X software. This dependancy is going to be included > in the convenance binary right? Is my understanding of this correct? If so > this may come as a surprise to users? How will they be informed of this? Yes. The LGPL runtime will be bundled in the convenience binary of Weex. In our *next release*, the LGPL runtime will be decoupled convenience binary. Users would include both weex_sdk and Webkit(Actually, we only use the JavaScriptCore of Webkit) together like following: weex_sdk webkit I think user would understand that they must include a LGPL runtime(Or any other Javascript interpretator they like) in this way. Best Regards, YorkShen 申远 Justin Mclean 于2019年7月10日周三 上午7:52写道： > Hi, > > +1 (binding) > > I checked: > - incubating in name > - signature and hashes fine > - DISCLAIMER exists > - LICENSE and NOTICE files fine > - No unexpected binary files > - Source file have ASF headers where needed (although rat is a little > noisy so may of missed one) > - Didn’t try to compile > > I’m concerned that I don’t see any indication that release contains a > dependancy on Category X software. This dependancy is going to be included > in the convenance binary right? Is my understanding of this correct? If so > this may come as a surprise to users? How will they be informed of this? > > I would also suggest you use an apache.org email address to sign the > artefact. > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [Vote] Release Apache Weex (Incubating) 0.26.0-RC2
> > * gradle build works (I had trouble with the build script in the scripts > directory) If you build Weex on a Mac, could you please explain your problem here, maybe we shall fix it before next release. We only test build script on Mac platform, if it's on other platforms, there could be problem like Apple only provide iOS toolchain on Mac This throws up 161 files with unknown licenses. Most of them are webkit headers, others are README.md, xx.md, xx.lint or other stuffs like this. As for RAT exception, what' the procedure, is there any document? Best Regards, YorkShen 申远 Myrle Krantz 于2019年7月9日周二 上午2:49写道： > Hey all, > > I vote +1 (binding) > > I checked: > * incubating in name > * gradle build works (I had trouble with the build script in the scripts > directory) > * It contains a correct NOTICE and a LICENSE and DISCLAIMER > * ran ant (version 13) (Got slowed down by accidentally typing rant-ant > multiple times : o) > -> This throws up 161 files with unknown licenses. If I understand > correctly, these are the webkit headers. I understand you are aware of the > problem and are working on it. I will not be able to vote +1 on a second > release with this problem. But you're aware of that already. If you get > legal approval, please consider adjusting the RAT exceptions so that the > RAT report is clean. > * all other source files have ASF headers > > Best Regards, > Myrle > > > On Mon, Jul 8, 2019 at 1:19 PM 王乾元 wrote: > > > Hi, > > > > The Apache Weex community has voted and approved the proposal to release > > Apache Weex (Incubating) version 0.26.0-RC2. > > We now kindly request the Incubator PMC members to review and vote on > this > > incubator release. > > > > > >- Vote thread: > > > > > https://lists.apache.org/x/thread.html/1fe6327f7a2775fad2ca08c6960dac8d389479fce2abbd8c6680a374@%3Cdev.weex.apache.org%3E > >- Vote result thread: > > > > > https://lists.apache.org/x/thread.html/199d2046caece609992271546926378dda4dc2bfd5281caa3ff9c8a6@%3Cdev.weex.apache.org%3E > >- Git tag for this Release: 0.26.0-RC2 > >- The source tarball could be found at : > > > > > https://dist.apache.org/repos/dist/dev/incubator/weex/0.26.0/RC2/apache-weex-incubating-0.26.0-RC2-src.tar.gz > >< > > > https://dist.apache.org/repos/dist/dev/incubator/weex/0.26.0/RC1/apache-weex-incubating-0.26.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.26.0/RC2/apache-weex-incubating-0.26.0-RC2-src.tar.gz.asc > >< > > > https://dist.apache.org/repos/dist/dev/incubator/weex/0.26.0/RC1/apache-weex-incubating-0.26.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.26.0/RC2/apache-weex-incubating-0.26.0-RC2-src.tar.gz.sha512 > >< > > > https://dist.apache.org/repos/dist/dev/incubator/weex/0.26.0/RC1/apache-weex-incubating-0.26.0-RC1-src.tar.gz.sha512 > > > > >- The source tarball is signed with Key: > >CCEFD4B69782450DE173FB5FC7286E03F6E02FBC, which could be found in the > > key > >file: https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS > > > > > > *ChangeLog about this version:* > > *Features* > > > >- Support arm64 & ndk18 on Android platform. > >- Android JSC Runtime refactor. > >- Android & iOS multi-size screen & rotation support. > >- Background JS thread on iOS. > >- Log module on iOS and Android to support redirection. > >- Synchronous call of component methods. > >- Unified C++ log system of WeexCore. > > > > *Main Bugfix* > > > >- Animation module crash on iOS. > >- RTL layout crash on iOS. > >- NSTimer not removed by WXTimerModule on iOS. > >- Occasionally showing placeholder instead of main image on iOS. > >- Animation end progress error on iOS. > >- Some NPE issues on Android. > >- Closing fd multiple times on Android IPC. > >- box-shadow crash protection on Android. > >- GPU texture size overflow protection on Android. > >- Weexcore.so loading failure problem on Android. > > > > > > One can build the binary from source according to > > > > > https://github.com/apache/incubator-weex/blob/0.26.0-RC2/HOW-TO-BUILD.md#build-all-by-script > > < > > > https://github.com/apache/incubator-weex/blob/0.26.0-RC1/HOW-TO-BUILD.md#build-all-by-script > > > > > > > > > This vote will remain open for at least 72 hours, until we get enough > > votes. Please vote on releasing this RC. > > > > [ ] +1 approve > > [ ] +0 no opinion > > [ ] -1 disapprove (and reason why) > > >
Re: LGPL dependency
It looks like we have got result[1] from Legal VP, I will bring it here now 1. It's fine if Weex only could include header files under 2-clause BSD license from Webkit at compiling time and has a dynamic link to Webkit.so at runtime. 2. It's recommended that excluding Webkit.so from Weex convenience library. Users would include the code snippet below to include both weex and webkit. weex_sdk webkit The following is what I need to consult from Incubator: Google will ban all apps without 64 bit published in Google Play from 1st, August, 2019 [1]. Though it's a good idea of excluding Webkit.so from convenience library of Weex, Weex community needs to publish next release with 64-bit support ASAP to give users enough time to upgrade Weex. I'd like to remain webkit.so in convenience library of Weex only for next release. [1] https://issues.apache.org/jira/browse/LEGAL-464 [2] https://developer.android.com/distribute/best-practices/develop/64-bit Best Regards, YorkShen 申远 Roman Shaposhnik 于2019年6月24日周一 上午7:32写道： > Lets continue this discussion on > https://issues.apache.org/jira/browse/LEGAL-464 please > > On Sat, Jun 22, 2019 at 2:18 PM Matt Sicker wrote: > > > > WebKit dates back to KHTML, an LGPL web engine from KDE. It sounds like > > it’s some WebKit specific files that are BSD licensed. I haven’t > inspected > > the individual files, but I suspect that the header files are BSD > licensed > > to make linking less of a legal headache. > > > > On Sat, Jun 22, 2019 at 07:11, Craig Russell > wrote: > > > > > The Webkit license page https://webkit.org/licensing-webkit/ says > > > portions licensed under LGPL and BSD licenses. > > > > > > Usually this means it's the user's choice which license to use. > > > > > > We would choose the BSD License for the components that we use. > > > > > > Can you find anywhere a statement that the Webkit.so is licensed only > > > under LGPL? > > > > > > Craig > > > > > > > On Jun 14, 2019, at 1:40 AM, 申远 wrote: > > > > > > > > As mentioned above, Webkit is under dual License(BSD and LPGL) and > it's > > > > almost impossible for us to figure out which function is a pure BSD > > > > function. I don't know > > > > Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL will happen > or > > > > not. Perhaps pure BSD header file will lead to pure BSD > implementation. > > > > Perhaps? > > > > > > > > As for alternative dependency, it's possible if we make some major > > > changes > > > > to Weex. But convenience binary of each Weex release includes > Webkit.so, > > > > how to solve that problem? Maybe publish two convenience binary, one > > > named > > > > Weex_WebKit.aar and the other named Weex_BSDKit.aar ? Not sounds > like a > > > > good idea to me. > > > > > > > > Best Regards, > > > > YorkShen > > > > > > > > 申远 > > > > > > > > > > > > Sheng Wu 于2019年6月14日周五 下午4:23写道： > > > > > > > >> Hi York > > > >> > > > >> I am not a C/C++ coder, so I could be wrong. > > > >> > > > >> But from I saw, Catalog X dependency required is not right. Like Hen > > > said, > > > >> alternative is an option. > > > >> > > > >> Such as > > > >> Today’s another incubating project, ShardingSphere. > > > >> When user wants to MySQL sharing, then they needs to accept MySQL > Driver > > > >> license first(or already accepted). > > > >> But user could use ShardingSphere with PostgreSQL JDBC Driver. > > > >> > > > >> > > > >> Sheng Wu > > > >> Apache Skywalking, ShardingSphere, Zipkin > > > >> > > > >> > > > >> > > > >>> 在 2019年6月14日，下午4:15，Hen 写道： > > > >>> > > > >>> Assuming Weex requires Webkit and is unable to work with an > > > alternative, > > > >>> the issue here is that users of Weex would seem to have to permit > > > reverse > > > >>> engineering in their legal terms. Our position has been that that > goes > > > >>> beyond the scope of the Apache 2.0 license and would be an > unpleasant > > > >>> surprise for users. > > > >>> > > > >>> (seem to have to => this is how we've discussed
Re: LGPL dependency
Sorry for my late reply, I have open a JIRA issue[1] for this problem. I'm really appreciated your help here, thank you all. [1] https://issues.apache.org/jira/browse/LEGAL-464 Best Regards, YorkShen 申远 申远 于2019年6月18日周二 下午8:08写道： > Thanks for help. > > I will bring this to legal-jira this weeks later. > > Best Regards, > YorkShen > > 申远 > > > Myrle Krantz 于2019年6月17日周一 下午8:07写道： > >> Thank you all, >> >> YorkShen, I think at this point the best thing to do is to open a "legal" >> ticket at this Jira (https://issues.apache.org/jira/browse/LEGAL). I >> suspect that if you're only including the BSD-licensed headers, that Weex >> will only be dependent on BSD-licensed code. It's possible that the >> "runtime" argument will work in this case too. >> >> But this discussion hasn't made me feel confident in either statement, and >> there are other Apache projects for which this question may be relevant. >> I'd like a final answer and the legal committee can provide that. >> >> Let me know if you need help formulating the ticket. >> >> Best Regards, >> Myrle >> >> On Fri, Jun 14, 2019 at 7:13 PM Alex Harui >> wrote: >> >> > Some things I don't think have been mentioned in this thread so far: >> > >> > 1) Even if you make Webkit optional by offering V8, I believe the ASF >> > criteria for "optional" includes "less than half of your users will use >> > that option" and so if Webkit offers better performance and most of the >> > users select Webkit over V8, it won't really qualify Webkit as optional. >> > 2) AIUI, the ASF does not care about the licensing of RUNTIMES (my >> > emphasis) your project's code runs on. Otherwise, no ASF project could >> run >> > on Windows or OSX. Apache Flex runs on Adobe Flash/AIR runtimes. >> > 3) I could not quickly find a direct quote for this, but I believe the >> ASF >> > does not care about the licensing of BUILD TOOLS (emphasis mine) used to >> > manipulate the source in the source release as long as the license of >> those >> > tools does not constrain usage of that code (like some non-commercial >> > restriction, or even a "no evil" restriction. >> > >> > AIUI, the whole purpose of these restrictions is to not place >> restrictions >> > on modifications to source or use of source when that source is >> eventually >> > executed (whether interpreted or compiled or other). >> > >> > So, if I've made that clear so far, the question I have for Weex is: >> How >> > is Webkit used in Weex? Is it just a runtime and libraries for that >> > runtime? If so, then I believe it is ok to have a dependency on LGPL >> > Webkit, but I would recommend that you find a way to not bundle Webkit >> in >> > the release artifacts. Have it downloaded or make it a "prerequisite" >> just >> > like I think every ASF Java-based project says you must install a Java >> JDK >> > and don't bundle Java JDKs. >> > >> > Other questions to ask relative to whether Webkit is a runtime or build >> > tool: >> > >> > A) Will anybody realistically want to modify the Webkit sources in order >> > to use Weex? If no, that's great, and another reason to not bundle >> those >> > header files with your sources. >> > B) Will use of the WebKit header files and other binaries you depend on >> > create a restriction on use? If no, that's great as well, and I think >> if >> > the answer to A and B are both "no", the IPMC should consider Webkit to >> be >> > a runtime/build-tool dependency and let it go. >> > >> > HTH, >> > -Alex >> > >> > >> > On 6/14/19, 5:09 AM, "York Shen" wrote: >> > >> > It depends on the definition of optional dependency. Weex targets >> iOS, >> > Android and Browser environment and Webkit header files and shared >> library >> > are only bundled for Android environment. As for other environments, >> the OS >> > or browser itself has exposed enough API for Weex. >> > >> > PS: I am pretty sure that the iOS system itself uses almost the same >> > code of Webkit as Weex does to build its WKWebView. It’s really strange >> > that’s ok for Weex iOS and not ok for Weex Android. >> > >> > > 在 2019年6月14日，19:17，Justin Mclean 写道： >> > > >> > > Hi,
Re: LGPL dependency
Thanks for help. I will bring this to legal-jira this weeks later. Best Regards, YorkShen 申远 Myrle Krantz 于2019年6月17日周一 下午8:07写道： > Thank you all, > > YorkShen, I think at this point the best thing to do is to open a "legal" > ticket at this Jira (https://issues.apache.org/jira/browse/LEGAL). I > suspect that if you're only including the BSD-licensed headers, that Weex > will only be dependent on BSD-licensed code. It's possible that the > "runtime" argument will work in this case too. > > But this discussion hasn't made me feel confident in either statement, and > there are other Apache projects for which this question may be relevant. > I'd like a final answer and the legal committee can provide that. > > Let me know if you need help formulating the ticket. > > Best Regards, > Myrle > > On Fri, Jun 14, 2019 at 7:13 PM Alex Harui > wrote: > > > Some things I don't think have been mentioned in this thread so far: > > > > 1) Even if you make Webkit optional by offering V8, I believe the ASF > > criteria for "optional" includes "less than half of your users will use > > that option" and so if Webkit offers better performance and most of the > > users select Webkit over V8, it won't really qualify Webkit as optional. > > 2) AIUI, the ASF does not care about the licensing of RUNTIMES (my > > emphasis) your project's code runs on. Otherwise, no ASF project could > run > > on Windows or OSX. Apache Flex runs on Adobe Flash/AIR runtimes. > > 3) I could not quickly find a direct quote for this, but I believe the > ASF > > does not care about the licensing of BUILD TOOLS (emphasis mine) used to > > manipulate the source in the source release as long as the license of > those > > tools does not constrain usage of that code (like some non-commercial > > restriction, or even a "no evil" restriction. > > > > AIUI, the whole purpose of these restrictions is to not place > restrictions > > on modifications to source or use of source when that source is > eventually > > executed (whether interpreted or compiled or other). > > > > So, if I've made that clear so far, the question I have for Weex is: How > > is Webkit used in Weex? Is it just a runtime and libraries for that > > runtime? If so, then I believe it is ok to have a dependency on LGPL > > Webkit, but I would recommend that you find a way to not bundle Webkit in > > the release artifacts. Have it downloaded or make it a "prerequisite" > just > > like I think every ASF Java-based project says you must install a Java > JDK > > and don't bundle Java JDKs. > > > > Other questions to ask relative to whether Webkit is a runtime or build > > tool: > > > > A) Will anybody realistically want to modify the Webkit sources in order > > to use Weex? If no, that's great, and another reason to not bundle those > > header files with your sources. > > B) Will use of the WebKit header files and other binaries you depend on > > create a restriction on use? If no, that's great as well, and I think if > > the answer to A and B are both "no", the IPMC should consider Webkit to > be > > a runtime/build-tool dependency and let it go. > > > > HTH, > > -Alex > > > > > > On 6/14/19, 5:09 AM, "York Shen" wrote: > > > > It depends on the definition of optional dependency. Weex targets > iOS, > > Android and Browser environment and Webkit header files and shared > library > > are only bundled for Android environment. As for other environments, the > OS > > or browser itself has exposed enough API for Weex. > > > > PS: I am pretty sure that the iOS system itself uses almost the same > > code of Webkit as Weex does to build its WKWebView. It’s really strange > > that’s ok for Weex iOS and not ok for Weex Android. > > > > > 在 2019年6月14日，19:17，Justin Mclean 写道： > > > > > > Hi, > > > > > >> Well, what if Weex copies some BSD header files in Webkit then run > > on Webkit? IMHO, the Webkit is also an environment for Weex in this case. > > > > > > You still didi not answer if this is an optional dependancy? But > > again either way I suggest you ask on legal discuss. > > > > > > Thanks, > > > Justin > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > >
Re: LGPL dependency
> > Sorry to say, you have to > 1. Make that clear(I agree it is hard to do, even harder to recheck for > incubator, hope don’t need to do that) > Or > 2. Seek for an alternative. Option 1 is not realistic. However, Weex could switch from Webkit dependency to V8 [1] which is under BSD License. Though this also means a great deal of work. PS: Weex used to have V8 as its dependency until we figured out that JavaScriptCore(a component in Webkit) has better performance. We have to switch back to a poor performance dependency due to LGPL issue. Ironical enough for me. [1] https://github.com/v8/v8/blob/master/LICENSE Best Regards, York Shen 申远 在 2019年6月14日，16:58，Sheng Wu 写道： Inline. Sheng Wu Apache Skywalking, ShardingSphere, Zipkin 在 2019年6月14日，下午4:40，申远 写道： As mentioned above, Webkit is under dual License(BSD and LPGL) and it's almost impossible for us to figure out which function is a pure BSD function. I don't know Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL will happen or not. Perhaps pure BSD header file will lead to pure BSD implementation. Perhaps? Sorry to say, you have to 1. Make that clear(I agree it is hard to do, even harder to recheck for incubator, hope don’t need to do that) Or 2. Seek for an alternative. As for alternative dependency, it's possible if we make some major changes to Weex. But convenience binary of each Weex release includes Webkit.so, how to solve that problem? Maybe publish two convenience binary, one named Weex_WebKit.aar and the other named Weex_BSDKit.aar ? Not sounds like a good idea to me. I doubt we could do `Weex_WebKit.aar` as convenience binary, because of Catalog X license. More important is that LGPL dependency should not in source and binary under ASF. You could do a re-distribution out-of-ASF, by not using weex/Apache weex/etc..(Please correct me if I am wrong) Best Regards, YorkShen 申远 Sheng Wu 于2019年6月14日周五 下午4:23写道： Hi York I am not a C/C++ coder, so I could be wrong. But from I saw, Catalog X dependency required is not right. Like Hen said, alternative is an option. Such as Today’s another incubating project, ShardingSphere. When user wants to MySQL sharing, then they needs to accept MySQL Driver license first(or already accepted). But user could use ShardingSphere with PostgreSQL JDBC Driver. Sheng Wu Apache Skywalking, ShardingSphere, Zipkin 在 2019年6月14日，下午4:15，Hen 写道： Assuming Weex requires Webkit and is unable to work with an alternative, the issue here is that users of Weex would seem to have to permit reverse engineering in their legal terms. Our position has been that that goes beyond the scope of the Apache 2.0 license and would be an unpleasant surprise for users. (seem to have to => this is how we've discussed the license; an actual court may decide something completely different) Looking at Weex's website's description, it does not seem to be that a user of Weex will already have agreed to the terms of Webkit; thus I believe they would be unpleasantly surprised. Hen On Fri, Jun 14, 2019 at 12:49 AM 申远 wrote: Hi, I am a PPMC member of Apache Weex. After serious reviewing of our dependencies, I found there some of the source code we copied from Webkit is actually under LGPL license(Category X) and our license format tools changed the license header of these files to Apache v2 incorrectly. I'd like to hear advice from incubator that whether our actions below would fix the Category X issue. First of all, License for Webkit is complicated, as it's said that "WebKit is open source software with portions licensed under the LGPL and BSD licenses available here." [1]. Now, Weex includes 1500 header files( .h files) from Webkit at compiling stage and around 150 of the are under BSD License. At runtime, Weex will dynamic links to the shared library of Webkit. After some major change, Weex could just include around 50 headers(.h files) at compiling stage and all of them are under BSD license. At runtime, Weex still needs to dynamic links to the shared library of Webkit as before. 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. [1] https://webkit.org/licensing-webkit/ Best Regards, YorkShen 申远 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: LGPL dependency
As mentioned above, Webkit is under dual License(BSD and LPGL) and it's almost impossible for us to figure out which function is a pure BSD function. I don't know Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL will happen or not. Perhaps pure BSD header file will lead to pure BSD implementation. Perhaps? As for alternative dependency, it's possible if we make some major changes to Weex. But convenience binary of each Weex release includes Webkit.so, how to solve that problem? Maybe publish two convenience binary, one named Weex_WebKit.aar and the other named Weex_BSDKit.aar ? Not sounds like a good idea to me. Best Regards, YorkShen 申远 Sheng Wu 于2019年6月14日周五 下午4:23写道： > Hi York > > I am not a C/C++ coder, so I could be wrong. > > But from I saw, Catalog X dependency required is not right. Like Hen said, > alternative is an option. > > Such as > Today’s another incubating project, ShardingSphere. > When user wants to MySQL sharing, then they needs to accept MySQL Driver > license first(or already accepted). > But user could use ShardingSphere with PostgreSQL JDBC Driver. > > > Sheng Wu > Apache Skywalking, ShardingSphere, Zipkin > > > > > 在 2019年6月14日，下午4:15，Hen 写道： > > > > Assuming Weex requires Webkit and is unable to work with an alternative, > > the issue here is that users of Weex would seem to have to permit reverse > > engineering in their legal terms. Our position has been that that goes > > beyond the scope of the Apache 2.0 license and would be an unpleasant > > surprise for users. > > > > (seem to have to => this is how we've discussed the license; an actual > > court may decide something completely different) > > > > Looking at Weex's website's description, it does not seem to be that a > user > > of Weex will already have agreed to the terms of Webkit; thus I believe > > they would be unpleasantly surprised. > > > > Hen > > > > On Fri, Jun 14, 2019 at 12:49 AM 申远 wrote: > > > >> Hi, > >> > >> I am a PPMC member of Apache Weex. After serious reviewing of our > >> dependencies, I found there some of the source code we copied from > Webkit > >> is actually under LGPL license(Category X) and our license format tools > >> changed the license header of these files to Apache v2 incorrectly. I'd > >> like to hear advice from incubator that whether our actions below would > fix > >> the Category X issue. > >> > >> First of all, License for Webkit is complicated, as it's said that > "WebKit > >> is open source software with portions licensed under the LGPL and BSD > >> licenses available here." [1]. > >> > >> Now, Weex includes 1500 header files( .h files) from Webkit at compiling > >> stage and around 150 of the are under BSD License. At runtime, Weex will > >> dynamic links to the shared library of Webkit. > >> > >> After some major change, Weex could just include around 50 headers(.h > >> files) at compiling stage and all of them are under BSD license. At > >> runtime, Weex still needs to dynamic links to the shared library of > Webkit > >> as before. > >> > >> 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. > >> > >> [1] https://webkit.org/licensing-webkit/ > >> > >> Best Regards, > >> YorkShen > >> > >> 申远 > >> > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: LGPL dependency
> > In the link your shared, there is this > > For example, if you distribute copies of the library, whether gratis or > for a fee, you must give the recipients all the rights that we gave you. > You must make sure that they, too, receive or can get the source code. This is just the content of LGPL, so we are still talking about LGPL. I understand the LPGL is under category X and I am not going to change that. If that possible, week don’t depend on this in runtime? Dynamic links are > same as Java dependency, which should not be allowed. IMHO, I think they are actually different. There is a very good chance for any serious C/C++ program dynamically linking to Glibc, which is under LGPL. A simple *malloc *(included in Glibc) in any C/C++ program will cause you have a dynamic link to LGPL library. Best Regards, York Shen 申远 在 2019年6月14日，16:03，Sheng Wu 写道： Hi, In the link your shared, there is this For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. This is not compatible with our Apache 2.0 and Apache public good goal. Apache software should allow all users to use as their wish, even don’t open source again, sell the fork/mutation versions as they will. LGPL has been discussed many times, but that is not the only concern here. If that possible, week don’t depend on this in runtime? Dynamic links are same as Java dependency, which should not be allowed. This is my personal perspective only. Sheng Wu Apache Skywalking, ShardingSphere, Zipkin 在 2019年6月14日，下午3:48，申远 写道： Hi, I am a PPMC member of Apache Weex. After serious reviewing of our dependencies, I found there some of the source code we copied from Webkit is actually under LGPL license(Category X) and our license format tools changed the license header of these files to Apache v2 incorrectly. I'd like to hear advice from incubator that whether our actions below would fix the Category X issue. First of all, License for Webkit is complicated, as it's said that "WebKit is open source software with portions licensed under the LGPL and BSD licenses available here." [1]. Now, Weex includes 1500 header files( .h files) from Webkit at compiling stage and around 150 of the are under BSD License. At runtime, Weex will dynamic links to the shared library of Webkit. After some major change, Weex could just include around 50 headers(.h files) at compiling stage and all of them are under BSD license. At runtime, Weex still needs to dynamic links to the shared library of Webkit as before. 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. [1] https://webkit.org/licensing-webkit/ Best Regards, YorkShen 申远 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
LGPL dependency
Hi, I am a PPMC member of Apache Weex. After serious reviewing of our dependencies, I found there some of the source code we copied from Webkit is actually under LGPL license(Category X) and our license format tools changed the license header of these files to Apache v2 incorrectly. I'd like to hear advice from incubator that whether our actions below would fix the Category X issue. First of all, License for Webkit is complicated, as it's said that "WebKit is open source software with portions licensed under the LGPL and BSD licenses available here." [1]. Now, Weex includes 1500 header files( .h files) from Webkit at compiling stage and around 150 of the are under BSD License. At runtime, Weex will dynamic links to the shared library of Webkit. After some major change, Weex could just include around 50 headers(.h files) at compiling stage and all of them are under BSD license. At runtime, Weex still needs to dynamic links to the shared library of Webkit as before. 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. [1] https://webkit.org/licensing-webkit/ Best Regards, YorkShen 申远
[RESULT][VOTE] Release Apache Weex (Incubating) 0.24.0-RC3
Dear community: The vote for release Apache Weex (Incubating) 0.24.0-RC3 has passed in the IPMC(Incubator PMC) with three +1 binding votes and no -1 vote. +1 vote: - Justin Mclean (binding) - Willem Jiang (binding) - Liang Chen (binding) Vote Thread: https://lists.apache.org/thread.html/76a123c57b1d23f6ce12d3a3e035483fc258df16e347dce52c6b8ba5@%3Cgeneral.incubator.apache.org%3E Thanks to everyone who participated in, we will work to continue the release process including publishing the convenience binary artifacts. Best Regards, YorkShen 申远
Re: [VOTE] Release Apache Weex (Incubating) 0.24.0-RC3
Dear community We have collected enough vote for the release (three +1 binding votes and no -1 vote). I'd like to thank you the guys for the help and I will send another mail to close the vote officially. Best Regards, YorkShen 申远 Liang Chen 于2019年5月20日周一 下午11:19写道： > Hi > > +1 (binding) > > I checked : > - Incubating in name > - DISCLAIMER exists > - LICENSE and NOTICE fine > - all source files have ASF headers > - no unexpected binary files > - can compile from source. > > Regards > Liang > > > > -- > Sent from: http://apache-incubator-general.996316.n3.nabble.com/ > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Release Apache Weex (Incubating) 0.24.0-RC3
Thanks, Justin and Willem. I will fix the issue before next release. BTW: We have two +1 votes for releasing Weex(Incubating) 0.24.0-RC3, and we need at least another one +1 vote to get passed. Best Regards, YorkShen 申远 Willem Jiang 于2019年5月18日周六 下午8:04写道： > +1. (binding) > > Here what I checked: > Signed key and hash code are OK > No binary in the source artifact > Notice and Disclaimer files are OK, > We need to polish the License file as Justin had mentioned in next release. > I also find a minor issue of License file > I cannot find the License information about webkit from here[1], > but I find the license information here[2]. > I think we should update the License file for it. > > > [1] > https://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.17.4/ > [2]https://webkit.org/licensing-webkit/ > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Mon, May 13, 2019 at 11:06 AM 申远 wrote: > > > > Dear community, > > > > This is a call for releasing Apache Weex(Incubating) 0.24.0-RC3. > > > > The Apache Weex community has voted and approved the proposal to release > > Apache Weex (Incubating) version 0.24.0-RC3, we now kindly request the > > Incubator PMC members to review and vote on this incubator release. > > > >- Vote thread: > > > https://lists.apache.org/thread.html/af68fda5a0c5cbceadb6b0a93a1a35d8f9e13e13a3e3f69f7bf37886@%3Cdev.weex.apache.org%3E > >- Vote result thread: > > > https://lists.apache.org/thread.html/dc1499106878f647da051b0e7e1c526f3853214af4f2208323e321da@%3Cdev.weex.apache.org%3E > >- Git tag for this Release: > >https://github.com/apache/incubator-weex/tree/0.24.0-RC3 > >- The source tarball could be found at : > > * > https://dist.apache.org/repos/dist/dev/incubator/weex/0.24.0/RC3/apache-weex-incubating-0.24.0-RC3-src.tar.gz > >< > https://dist.apache.org/repos/dist/dev/incubator/weex/0.24.0/RC3/apache-weex-incubating-0.24.0-RC3-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/RC3/apache-weex-incubating-0.24.0-RC3-src.tar.gz.asc > >< > https://dist.apache.org/repos/dist/dev/incubator/weex/0.24.0/RC3/apache-weex-incubating-0.24.0-RC3-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/RC3/apache-weex-incubating-0.24.0-RC3-src.tar.gz.sha512 > >< > https://dist.apache.org/repos/dist/dev/incubator/weex/0.24.0/RC3/apache-weex-incubating-0.24.0-RC3-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 > >- ChangeLog about this version: > >https://github.com/apache/incubator-weex/blob/0.24.0-RC3/CHANGELOG.md > > > > One can build the binary from source according to > > > https://github.com/apache/incubator-weex/blob/0.24.0-RC3/HOW-TO-BUILD.md#build-all-by-script > > with > > corresponding compiling tools. > > > > Note: > > > >- The building scripts of Weex relies on XCode/NPM/Android SDK/Android > >NDK 13/Android NDK 16, *it would not be a surprise if your build fails > >on non-Mac environment or without corresponding software**.* > >- *Though PPMC members tested the building process in their computers, > >one may still meet compiling problems as the complexity of the > compiling > >procedure (You are going to compile JS/Android/iOS/C++ together in > order to > >build Weex).* > > > > 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 > > > > 申远 > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Release Apache Weex (Incubating) 0.24.0-RC3
Dear community This is a gentle reminder that our vote for releasing Apache Weex (incubating) version 0.24.0-RC3 has been going on for more than 72 hours. For now, we have 0 vote on this list. Please help us out if you are available, thanks. Best Regards, YorkShen 申远 申远 于2019年5月14日周二 下午5:24写道： > Dear community, > > This is a gentle reminder that our vote for releasing Apache Weex > (incubating) version 0.24.0-RC3 has been going on for more than 24 hours. > We need 3 binding +1 votes and more +1 votes than -1 votes for this release. > > I know the compiling procedure is complicated (toolchains > for JavaScript/Android/iOS/C++ on a mac device are needed), but we really > need to publish the release. > > Please help us out if you are available :-) > > Best Regards, > YorkShen > > 申远 > > > 申远 于2019年5月13日周一 上午11:06写道： > >> Dear community, >> >> This is a call for releasing Apache Weex(Incubating) 0.24.0-RC3. >> >> The Apache Weex community has voted and approved the proposal to release >> Apache Weex (Incubating) version 0.24.0-RC3, we now kindly request the >> Incubator PMC members to review and vote on this incubator release. >> >>- Vote thread: >> >> https://lists.apache.org/thread.html/af68fda5a0c5cbceadb6b0a93a1a35d8f9e13e13a3e3f69f7bf37886@%3Cdev.weex.apache.org%3E >>- Vote result thread: >> >> https://lists.apache.org/thread.html/dc1499106878f647da051b0e7e1c526f3853214af4f2208323e321da@%3Cdev.weex.apache.org%3E >>- Git tag for this Release: >>https://github.com/apache/incubator-weex/tree/0.24.0-RC3 >>- The source tarball could be found at : >> *https://dist.apache.org/repos/dist/dev/incubator/weex/0.24.0/RC3/apache-weex-incubating-0.24.0-RC3-src.tar.gz >> >> <https://dist.apache.org/repos/dist/dev/incubator/weex/0.24.0/RC3/apache-weex-incubating-0.24.0-RC3-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/RC3/apache-weex-incubating-0.24.0-RC3-src.tar.gz.asc >> >> <https://dist.apache.org/repos/dist/dev/incubator/weex/0.24.0/RC3/apache-weex-incubating-0.24.0-RC3-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/RC3/apache-weex-incubating-0.24.0-RC3-src.tar.gz.sha512 >> >> <https://dist.apache.org/repos/dist/dev/incubator/weex/0.24.0/RC3/apache-weex-incubating-0.24.0-RC3-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 >><https://dist.apache.org/repos/dist/release/incubator/weex/KEYS> >>- ChangeLog about this version: >>https://github.com/apache/incubator-weex/blob/0.24.0-RC3/CHANGELOG.md >> >> One can build the binary from source according to >> https://github.com/apache/incubator-weex/blob/0.24.0-RC3/HOW-TO-BUILD.md#build-all-by-script >> with >> corresponding compiling tools. >> >> Note: >> >>- The building scripts of Weex relies on XCode/NPM/Android >>SDK/Android NDK 13/Android NDK 16, *it would not be a surprise if >>your build fails on non-Mac environment or without corresponding software* >>*.* >>- *Though PPMC members tested the building process in their >>computers, one may still meet compiling problems as the complexity of the >>compiling procedure (You are going to compile JS/Android/iOS/C++ together >>in order to build Weex).* >> >> 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: [VOTE] Release Apache Weex (Incubating) 0.24.0-RC3
Dear community, This is a gentle reminder that our vote for releasing Apache Weex (incubating) version 0.24.0-RC3 has been going on for more than 24 hours. We need 3 binding +1 votes and more +1 votes than -1 votes for this release. I know the compiling procedure is complicated (toolchains for JavaScript/Android/iOS/C++ on a mac device are needed), but we really need to publish the release. Please help us out if you are available :-) Best Regards, YorkShen 申远 申远 于2019年5月13日周一 上午11:06写道： > Dear community, > > This is a call for releasing Apache Weex(Incubating) 0.24.0-RC3. > > The Apache Weex community has voted and approved the proposal to release > Apache Weex (Incubating) version 0.24.0-RC3, we now kindly request the > Incubator PMC members to review and vote on this incubator release. > >- Vote thread: > > https://lists.apache.org/thread.html/af68fda5a0c5cbceadb6b0a93a1a35d8f9e13e13a3e3f69f7bf37886@%3Cdev.weex.apache.org%3E >- Vote result thread: > > https://lists.apache.org/thread.html/dc1499106878f647da051b0e7e1c526f3853214af4f2208323e321da@%3Cdev.weex.apache.org%3E >- Git tag for this Release: >https://github.com/apache/incubator-weex/tree/0.24.0-RC3 >- The source tarball could be found at : > *https://dist.apache.org/repos/dist/dev/incubator/weex/0.24.0/RC3/apache-weex-incubating-0.24.0-RC3-src.tar.gz > > <https://dist.apache.org/repos/dist/dev/incubator/weex/0.24.0/RC3/apache-weex-incubating-0.24.0-RC3-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/RC3/apache-weex-incubating-0.24.0-RC3-src.tar.gz.asc > > <https://dist.apache.org/repos/dist/dev/incubator/weex/0.24.0/RC3/apache-weex-incubating-0.24.0-RC3-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/RC3/apache-weex-incubating-0.24.0-RC3-src.tar.gz.sha512 > > <https://dist.apache.org/repos/dist/dev/incubator/weex/0.24.0/RC3/apache-weex-incubating-0.24.0-RC3-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 >- ChangeLog about this version: >https://github.com/apache/incubator-weex/blob/0.24.0-RC3/CHANGELOG.md > > One can build the binary from source according to > https://github.com/apache/incubator-weex/blob/0.24.0-RC3/HOW-TO-BUILD.md#build-all-by-script > with > corresponding compiling tools. > > Note: > >- The building scripts of Weex relies on XCode/NPM/Android SDK/Android >NDK 13/Android NDK 16, *it would not be a surprise if your build fails >on non-Mac environment or without corresponding software**.* >- *Though PPMC members tested the building process in their computers, >one may still meet compiling problems as the complexity of the compiling >procedure (You are going to compile JS/Android/iOS/C++ together in order to >build Weex).* > > 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 > > 申远 >
[VOTE] Release Apache Weex (Incubating) 0.24.0-RC3
Dear community, This is a call for releasing Apache Weex(Incubating) 0.24.0-RC3. The Apache Weex community has voted and approved the proposal to release Apache Weex (Incubating) version 0.24.0-RC3, we now kindly request the Incubator PMC members to review and vote on this incubator release. - Vote thread: https://lists.apache.org/thread.html/af68fda5a0c5cbceadb6b0a93a1a35d8f9e13e13a3e3f69f7bf37886@%3Cdev.weex.apache.org%3E - Vote result thread: https://lists.apache.org/thread.html/dc1499106878f647da051b0e7e1c526f3853214af4f2208323e321da@%3Cdev.weex.apache.org%3E - Git tag for this Release: https://github.com/apache/incubator-weex/tree/0.24.0-RC3 - The source tarball could be found at : *https://dist.apache.org/repos/dist/dev/incubator/weex/0.24.0/RC3/apache-weex-incubating-0.24.0-RC3-src.tar.gz <https://dist.apache.org/repos/dist/dev/incubator/weex/0.24.0/RC3/apache-weex-incubating-0.24.0-RC3-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/RC3/apache-weex-incubating-0.24.0-RC3-src.tar.gz.asc <https://dist.apache.org/repos/dist/dev/incubator/weex/0.24.0/RC3/apache-weex-incubating-0.24.0-RC3-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/RC3/apache-weex-incubating-0.24.0-RC3-src.tar.gz.sha512 <https://dist.apache.org/repos/dist/dev/incubator/weex/0.24.0/RC3/apache-weex-incubating-0.24.0-RC3-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 - ChangeLog about this version: https://github.com/apache/incubator-weex/blob/0.24.0-RC3/CHANGELOG.md One can build the binary from source according to https://github.com/apache/incubator-weex/blob/0.24.0-RC3/HOW-TO-BUILD.md#build-all-by-script with corresponding compiling tools. Note: - The building scripts of Weex relies on XCode/NPM/Android SDK/Android NDK 13/Android NDK 16, *it would not be a surprise if your build fails on non-Mac environment or without corresponding software**.* - *Though PPMC members tested the building process in their computers, one may still meet compiling problems as the complexity of the compiling procedure (You are going to compile JS/Android/iOS/C++ together in order to build Weex).* 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: Fwd: [DISCUSS] can we use weex.io as the short domain name fortheapache project
weex.apache.org is fast too from my network environment now. We had received several complaint years ago from Chinese users that weex.apache.org is slow, so we launched weex-project.io with the same content of weex.apache.org. If this is against rules, I think we can make it redirect to weex.apache.org, not sure whether we would receive complaint again. Best Regards, YorkShen 申远 吴晟 Sheng Wu 于2019年2月18日周一 下午4:56写道： > Hi > > > I don't know why it is slow, I just tried, very quickly. > > > > > -- > Sheng Wu > Apache SkyWalking, ShardingSphere, Zipkin > Twitter, wusheng1108 > > > > > > > > -- Original -- > From: "申远"; > Date: Mon, Feb 18, 2019 04:33 PM > To: "general"; > > Subject: Re: Fwd: [DISCUSS] can we use weex.io as the short domain name > fortheapache project > > > > > > > 3. I don't think ASF websites are facing GFW issue. > > ASF website is quite slow when accessing from China, I am not sure whether > this is a GFW issue or simply the server is on another continent without a > CDN. > > We received complains about weex.apache.org from China mainland years ago, > so we deploy website to weex-project.io for fast access in China, as many > of our users are from China and there is CDN for weex-project.io . If > there is a solution for this issue, please let me know. > > Best Regards, > YorkShen > > 申远 > > > 吴晟 Sheng Wu 于2019年2月18日周一 下午3:52写道： > > > Hi YorkShen > > > > > > From my understanding, weex project, including branding and logo, should > > be donated to ASF(at least before Graduation). > > The basic policy is, weex.apache.org should be the only official website > > for the project. > > And project's website should be hosted in Apache Infra. > > > > > > If you have others, let's say weex.io and weex-project.io, and run by > > your committers team, I suggest > > 1. Set redirect for `weex.io` to `weex.apache.org`, for the end user > > convenience. > > 2. For the Chinese documents, if your committers/contributors maintain > > this, put it in `http://weex.apache.org/cn/`makes > <http://weex.apache.org/cn/makes> > > <http://weex.apache.org/cn/makes> sense. > > 3. I don't think ASF websites are facing GFW issue. > > > > > > If you want to publish another domain/website for ecosystem, you should > > avoid using `weex-`, `weex.`, to avoid branding issues. > > And I suggest you don't do that, because the community will be split. > > > > > > The following are just suggestions from my experiences. > > Blog(cn/en) post are popular in many Apache project, which could be > easily > > supported by our CI hook in GitHub, also have post control and review. > > If you want helps from this, ping me or `d...@skywalking.apache.org`, we > > have done something. > > > > > > For Q robots, if you are running that on GitHub issue, a Robot account > > with project subscription should be good enough. > > If you want to do that at Website, I think it will be more complex. > > > > > > -- > > Sheng Wu > > Apache SkyWalking, ShardingSphere, Zipkin > > Twitter, wusheng1108 > > > > > > > > > > > > > > > > -- Original -- > > From: "申远"; > > Date: Mon, Feb 18, 2019 03:07 PM > > To: "general"; > > > > Subject: Fwd: [DISCUSS] can we use weex.io as the short domain name for > > theapache project > > > > > > > > Hi, there > > > > I am a PPMC member of incubator-weex, there is some confusion about > > third-party domain and it seems like difficult to resolve in dev@ > mailing > > list, maybe someone here could give a hand to solve the problem of > domains. > > > > 1.I 'd like to know if there is a formal rule that projects should use > > xxx.apache.org instead of xxx.io, which is shorter and easier to > remember. > > 2. we have another domain weex-project.io for fast access of Çhinese > > Developers as GFW have some confluence on https://weex.apache.org/cn/. > Is > > this against rules for apache project. > > > > Best Regards, > > YorkShen > > > > 申远 > > > > > > -- Forwarded message - > > From: Dan > > Date: 2019年2月15日周五 下午2:39 > > Subject: [DISCUSS] can we use weex.io as the short domain name for the > > apache project > > To: > > > > > > Hi, Myrle/Willem, > > > > Currently, we have a domain name of weex.io and want to use it to > replace > > the previous weex-project.io domain name for the following reasons: > > > > 1. The domain name is shorter and easier to remember. > > 2. Apache's website has slower access to the developer in China, so there > > is a mirror website weex-project.io for Chinese developer. > > 3. We expect to support https on this website and support some of our own > > server functions, such as Q robots, article blog posts, etc. > > > > I would like to ask if apache has any restrictions on this third-party > > domain name, and look forward to hearing from you. > > > > Thanks, > > Dan
Re: Fwd: [DISCUSS] can we use weex.io as the short domain name for theapache project
> > 3. I don't think ASF websites are facing GFW issue. ASF website is quite slow when accessing from China, I am not sure whether this is a GFW issue or simply the server is on another continent without a CDN. We received complains about weex.apache.org from China mainland years ago, so we deploy website to weex-project.io for fast access in China, as many of our users are from China and there is CDN for weex-project.io . If there is a solution for this issue, please let me know. Best Regards, YorkShen 申远 吴晟 Sheng Wu 于2019年2月18日周一 下午3:52写道： > Hi YorkShen > > > From my understanding, weex project, including branding and logo, should > be donated to ASF(at least before Graduation). > The basic policy is, weex.apache.org should be the only official website > for the project. > And project's website should be hosted in Apache Infra. > > > If you have others, let's say weex.io and weex-project.io, and run by > your committers team, I suggest > 1. Set redirect for `weex.io` to `weex.apache.org`, for the end user > convenience. > 2. For the Chinese documents, if your committers/contributors maintain > this, put it in `http://weex.apache.org/cn/`makes > <http://weex.apache.org/cn/makes> sense. > 3. I don't think ASF websites are facing GFW issue. > > > If you want to publish another domain/website for ecosystem, you should > avoid using `weex-`, `weex.`, to avoid branding issues. > And I suggest you don't do that, because the community will be split. > > > The following are just suggestions from my experiences. > Blog(cn/en) post are popular in many Apache project, which could be easily > supported by our CI hook in GitHub, also have post control and review. > If you want helps from this, ping me or `d...@skywalking.apache.org`, we > have done something. > > > For Q robots, if you are running that on GitHub issue, a Robot account > with project subscription should be good enough. > If you want to do that at Website, I think it will be more complex. > > > -- > Sheng Wu > Apache SkyWalking, ShardingSphere, Zipkin > Twitter, wusheng1108 > > > > > > > > -- Original -- > From: "申远"; > Date: Mon, Feb 18, 2019 03:07 PM > To: "general"; > > Subject: Fwd: [DISCUSS] can we use weex.io as the short domain name for > theapache project > > > > Hi, there > > I am a PPMC member of incubator-weex, there is some confusion about > third-party domain and it seems like difficult to resolve in dev@ mailing > list, maybe someone here could give a hand to solve the problem of domains. > > 1.I 'd like to know if there is a formal rule that projects should use > xxx.apache.org instead of xxx.io, which is shorter and easier to remember. > 2. we have another domain weex-project.io for fast access of Çhinese > Developers as GFW have some confluence on https://weex.apache.org/cn/. Is > this against rules for apache project. > > Best Regards, > YorkShen > > 申远 > > > -- Forwarded message - > From: Dan > Date: 2019年2月15日周五 下午2:39 > Subject: [DISCUSS] can we use weex.io as the short domain name for the > apache project > To: > > > Hi, Myrle/Willem, > > Currently, we have a domain name of weex.io and want to use it to replace > the previous weex-project.io domain name for the following reasons: > > 1. The domain name is shorter and easier to remember. > 2. Apache's website has slower access to the developer in China, so there > is a mirror website weex-project.io for Chinese developer. > 3. We expect to support https on this website and support some of our own > server functions, such as Q robots, article blog posts, etc. > > I would like to ask if apache has any restrictions on this third-party > domain name, and look forward to hearing from you. > > Thanks, > Dan
Fwd: [DISCUSS] can we use weex.io as the short domain name for the apache project
Hi, there I am a PPMC member of incubator-weex, there is some confusion about third-party domain and it seems like difficult to resolve in dev@ mailing list, maybe someone here could give a hand to solve the problem of domains. 1.I 'd like to know if there is a formal rule that projects should use xxx.apache.org instead of xxx.io, which is shorter and easier to remember. 2. we have another domain weex-project.io for fast access of Çhinese Developers as GFW have some confluence on https://weex.apache.org/cn/. Is this against rules for apache project. Best Regards, YorkShen 申远 -- Forwarded message - From: Dan Date: 2019年2月15日周五 下午2:39 Subject: [DISCUSS] can we use weex.io as the short domain name for the apache project To: Hi, Myrle/Willem, Currently, we have a domain name of weex.io and want to use it to replace the previous weex-project.io domain name for the following reasons: 1. The domain name is shorter and easier to remember. 2. Apache's website has slower access to the developer in China, so there is a mirror website weex-project.io for Chinese developer. 3. We expect to support https on this website and support some of our own server functions, such as Q robots, article blog posts, etc. I would like to ask if apache has any restrictions on this third-party domain name, and look forward to hearing from you. Thanks, Dan
Re: [DISCUSS] Guidelines for distribution of incubating artefacts on other platforms
> > 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. We distribute artefacts through *CocoaPods* and *Gradle* channel in *incubator-weex* <http://incubator.apache.org/projects/weex.html> project for iOS and Android developers. It would be great if you could add *CocoaPods* and *Gradle *platforms. - Unofficial releases need to be made from approved voted on approved ASF > releases. Does this mean that we need a vote even for distribution of unreleased material <https://www.apache.org/dev/release-distribution#unreleased> ? Incubator-weex had used unofficial release without vote to get quick feedback from users before we knew it could break the rule of Apache release. *According to my understanding, any format of release on any platform needs a vote even if it is unofficial, snapshot, nightly build and etc..* Correct me if I am wrong. Best Regards, YorkShen 申远 Justin Mclean 于2019年2月8日周五 下午3:08写道： > 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
Request incubator wiki write access
Hi, there I am a committer of Incubator-Weex project and need write access to the incubator wiki to update podling report. My user name on Incubator wiki site is YorkShen Best Regards, YorkShen
Re: [VOTE]- Release Apache Weex (Incubating) 0.19.0 [RC3]
I have fixed the issue by removing ./apache-weex-incubating-0.19.0-RC3-src/android_sdk/gradle/wrapper/gradle-wrapper.jar, it seems like to me everything is good now. > 在 2018年8月14日，16:40，Justin Mclean 写道： > > Hi, > > Sorry but it’s -1 (binding) form me as there is compiled code in the source > release. [1] > > I checked: > - incubating in name > - signature and hashes good > - DISCLAIMER exists > - LICENCE and NOTICE ok but there is a licensing issue (see below) > - Unexpected binary in source release > - All source files have ASF header > - Can compile from source > > You are not abiding by the terms of the MIT license as a copy of the license > text isn’t being included in the release, please fix this for the next > release. This is why the short form of providing a link to the text of the > license is recommended in LICENSE. Linking via a URL (as you done for other > licenses) is also not recommended as the content at that URL could change. > > The file POSSIBLE-NOTICES-FOR-BIN-DIST probably doesn’t have correct content > as MIT and BSD licenses usually doesn’t need to be mentioned in NOTICE. [2] > > Thanks, > Justin > > > 1. > ./apache-weex-incubating-0.19.0-RC3-src/android_sdk/gradle/wrapper/gradle-wrapper.jar > 2. http://www.apache.org/dev/licensing-howto.html#mod-notice > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
