Re: mod_pagespeed incubation page still blank

[Rich Bowen]

Thank you. This is indeed a huge improvement.

On Thu, May 16, 2019, 15:56 Otto van der Schaaf  wrote:

> http://pagespeed.incubator.apache.org/ now ought to look much better!
>
> Otto
>
>
> Op ma 13 mei 2019 om 20:47 schreef Otto van der Schaaf  >:
>
> > I think that we should see a major improvement if we can put the contents
> > of https://github.com/apache/incubator-pagespeed-mod/tree/master/html
> over
> > at http://pagespeed.incubator.apache.org/.
> > Can somebody please  help me by pointing out how to accomplish that?
> > Reading http://www.staging.apache.org/dev/project-site, it looks like
> > gitpubsub would be what we need, is setting that up
> > a matter of requesting help via filing an infra jira issue?
> > - I worked on a RC; it's currently staged over at
> > http://people.apache.org/~oschaaf/mod_pagespeed/1.14.36.1-rc2/
> > This unfortunately needs another round of correction, but I have
> addressed
> > everything else I could catch, (except that the archive contents starts
> in
> > a subdirectory).
> > After I've done that I will raise a thread on this list to discuss.
> >
> > Otto
> >
> >
> > Op ma 13 mei 2019 om 19:54 schreef Dave Fisher :
> >
> >> Hi Rich,
> >>
> >> It has been disappointing that no progress has been made for so long.
> >>
> >> Do we need one more shot at mentoring or is it time to retire?
> >>
> >> Regards,
> >> Dave
> >>
> >> Sent from my iPhone
> >>
> >> > On May 13, 2019, at 10:33 AM, Rich Bowen  wrote:
> >> >
> >> > Hi, folks.
> >> >
> >> > I'm not sure who to direct this to.
> >> >
> >> > The mod_pagespeed incubation page -
> >> http://pagespeed.incubator.apache.org/ - which is linked from the
> >> incubator site - http://incubator.apache.org/projects/pagespeed.html -
> >> remains blank after mentioning it a couple of times both here, and on
> their
> >> project mailing list, as well as a couple of times in board report
> comments.
> >> >
> >> > Is that something we can strive to get corrected in the coming month
> or
> >> so?
> >> >
> >> > --Rich
> >> >
> >> >
> >> > --
> >> > Rich Bowen - rbo...@rcbowen.com
> >> > http://rcbowen.com/
> >> > @rbowen
> >> >
> >> > -
> >> > 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: mod_pagespeed incubation page still blank

[Otto van der Schaaf]

http://pagespeed.incubator.apache.org/ now ought to look much better!

Otto


Op ma 13 mei 2019 om 20:47 schreef Otto van der Schaaf :

> I think that we should see a major improvement if we can put the contents
> of https://github.com/apache/incubator-pagespeed-mod/tree/master/html over
> at http://pagespeed.incubator.apache.org/.
> Can somebody please  help me by pointing out how to accomplish that?
> Reading http://www.staging.apache.org/dev/project-site, it looks like
> gitpubsub would be what we need, is setting that up
> a matter of requesting help via filing an infra jira issue?
> - I worked on a RC; it's currently staged over at
> http://people.apache.org/~oschaaf/mod_pagespeed/1.14.36.1-rc2/
> This unfortunately needs another round of correction, but I have addressed
> everything else I could catch, (except that the archive contents starts in
> a subdirectory).
> After I've done that I will raise a thread on this list to discuss.
>
> Otto
>
>
> Op ma 13 mei 2019 om 19:54 schreef Dave Fisher :
>
>> Hi Rich,
>>
>> It has been disappointing that no progress has been made for so long.
>>
>> Do we need one more shot at mentoring or is it time to retire?
>>
>> Regards,
>> Dave
>>
>> Sent from my iPhone
>>
>> > On May 13, 2019, at 10:33 AM, Rich Bowen  wrote:
>> >
>> > Hi, folks.
>> >
>> > I'm not sure who to direct this to.
>> >
>> > The mod_pagespeed incubation page -
>> http://pagespeed.incubator.apache.org/ - which is linked from the
>> incubator site - http://incubator.apache.org/projects/pagespeed.html -
>> remains blank after mentioning it a couple of times both here, and on their
>> project mailing list, as well as a couple of times in board report comments.
>> >
>> > Is that something we can strive to get corrected in the coming month or
>> so?
>> >
>> > --Rich
>> >
>> >
>> > --
>> > Rich Bowen - rbo...@rcbowen.com
>> > http://rcbowen.com/
>> > @rbowen
>> >
>> > -
>> > 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: Podling Status Event Dates - Re: Podling status Copyright section

[Kenneth Knowles]

Thanks for this. The steps are very clear and I like the addition of
repository clearance.

Kenn

On Wed, May 15, 2019 at 12:52 PM Chris Lambertus  wrote:

>
>
> > On May 15, 2019, at 12:10 PM, Dave Fisher  wrote:
> >
> > Hi -
> >
> > I think that we are mixing together a few events in a podling's
> lifecycle. Since I published a plan to update the status process and am
> just about to implement I think we should discuss events in a modern way
> since much of the language is a decade or more old and we are each trying
> to find the best language for modern times which includes our collective
> thoughts and understanding.
> >
> > (1) Start Date - Podling Proposal is Accepted.
> > (2) Podlings.xml file updated.
> > (3) Status page created.
> > (Not needed in improvement plan where the correct dates and events will
> be maintained through Whimsy Roster/Status pages)
> > (4) LDAP and Mailing lists created by Infra.
>
>
> DNS is a required Infra step. the LDAP creation is via Whimsy, and anyone
> with appropriate karma can click the button, although I do not currently
> know who has the karma. It is nominally apldap (Infra) but I think
> Secretary may also be able to take this step? This can be changed to suit,
> and could easily happen as part of the onboarding process (maybe by
> Secretary, maybe by some other designee) after podlings.xml has been
> updated. For now, it's easy enough to include it as an Infra step.
>
> Mailing lists are self-serve once the LDAP and DNS exists via
> https://selfserve.apache.org/ 
>
>
>
> > (5) PPMC Member onboarding - ICLA, Apache accounts, ML signup.
> > (6) Codebase onboarding - assuming that all podling’s continue to fit
> the GitHub development model.
> > - SGA (or proof that CCLA/ICLA in some combination are appropriate.)
> > - List of Repositories Cleared - This is NEW and providing this will be
> very helpful to both the podling and INFRA.
> > - Different repositories may come under different SGAs (or ICLA/CCLA)
> > - Date the repository is moved (or copied) and accepted by the PPMC.
>
> Specifically for Infra onboarding, we really just need to know that "the
> Foundation" has accepted the code and the donation has been reviewed by
> someone in-the-know about these things. Historically, this has been
> Secretary. The most critical thing for infra is that the repositories
> requested to be moved to the ASF are the ones which Secretary has received
> the SGA for, and the person requesting the import include a mailing list
> link to the Secretary's acceptance of the SGA.
>
> Thanks for putting this together.
>
> -Chris
>
>
>
>
>
> > (7) Date that the donated code has been changed.
> > - AL2 headers
> > - Copyrights removed.
> > (8) First fully compliant release
> > - Date when the IPMC agrees that podling is making compliant releases.
> > (9) News - releases, added committers, added PPMC members, (added
> repositories?)
> >
> > Notes on (6):
> > (a) Providing clearance for each repository will provide INFRA with a
> clear place to confirm that GitHub JIRA requests are valid.
> > (b) Provide a clear view to the status of repositories.
> >
> > Does this breakdown help us focus on the code versus committer
> requirements?
> >
> >> On May 15, 2019, at 1:28 AM, sebb  wrote:
> >>
> >> On Wed, 15 May 2019 at 06:55, Alex Harui 
> wrote:
> >>>
> >>> I do not like the words "transfer rights".  It could be interpreted as
> transfer of copyright.  Copyright of existing code is not transferred to
> the ASF, AIUI.  How about "Check to make sure that an SGA or CCLA has been
> received.”
> >
> > At the point the SGA is granted and the code repository moved over one
> of the first actions to add the AL2 headers where appropriate. The donation
> may be relicensed from proprietary to AL2. At this time the copyright line
> is typically removed.
> >
> > It is up to the donating companies what they do with their copyright to
> their copy.
> >
> >>>
> >>> I don't like hypotheticals, but I can imagine some individual starting
> a project on GitHub, has only a few files already under ALv2, and gets a
> project going at the ASF?  Wouldn't we accept those few files under his
> ICLA and not require an SGA or CCLA?
> >
> > Yes. See 6 above.
> >
> >>>
> >>> I'd suggest dropping the second sentence ("it is necessary to transfer
> rights...").  AIUI, it is only necessary to grant a perpetual license to
> the ASF.
> >>
> >> Also, the CCLA is not required, and is not an alternative to the SGA
> >> -- as may perhaps be inferred by some from the phrase "(SGA or CCLA)"
> >>
> >> https://www.apache.org/licenses/cla-faq.html#cclas-not-required <
> https://www.apache.org/licenses/cla-faq.html#cclas-not-required>
> >
> > It is between the individuals and their employers if they can
> contribute. In the rare case where a company might not grant the donation
> via our SGA, but would with an CCLA, then we should be flexible. The
> question is where that decision should be made and how 

Re: Podling status Copyright section

[Matt Sicker]

A CCLA has two schedules (exhibits? sections?): one for employees, and one
for software grants. The grants section is typically left empty.

On Thu, May 16, 2019 at 11:15, Alex Harui  wrote:

> Hi Matt,
>
> I'm not sure what "add" means, but there have been several past
> discussions where it appears that new code was brought in under a CCLA
> without an SGA.
>
>
> https://lists.apache.org/thread.html/d77183d7efd5faf331534edf7ee2de993e908cffa4feb7454f9a6ab1@%3Cgeneral.incubator.apache.org%3E
> https://issues.apache.org/jira/browse/LEGAL-236
>
> https://lists.apache.org/thread.html/2814bd99f77325f80c6bfbf1156debd22bf556bfd4b9786996c9217c@1423476452@%3Cgeneral.incubator.apache.org%3E
> http://s.apache.org/YPe
>
> It is also my understanding (from Roy) that in some cases existing code
> can come in under an ICLA.
>
> HTH,
> -Alex
>
> On 5/15/19, 4:27 PM, "Matt Sicker"  wrote:
>
> You can add a software grant to a CCLA concurrently, but not vice
> versa.
>
> On Wed, May 15, 2019 at 03:28, sebb  wrote:
>
> > On Wed, 15 May 2019 at 06:55, Alex Harui 
> wrote:
> > >
> > > I do not like the words "transfer rights".  It could be
> interpreted as
> > transfer of copyright.  Copyright of existing code is not
> transferred to
> > the ASF, AIUI.  How about "Check to make sure that an SGA or CCLA
> has been
> > received."
> > >
> > > I don't like hypotheticals, but I can imagine some individual
> starting a
> > project on GitHub, has only a few files already under ALv2, and gets
> a
> > project going at the ASF?  Wouldn't we accept those few files under
> his
> > ICLA and not require an SGA or CCLA?
> > >
> > > I'd suggest dropping the second sentence ("it is necessary to
> transfer
> > rights...").  AIUI, it is only necessary to grant a perpetual
> license to
> > the ASF.
> >
> > Also, the CCLA is not required, and is not an alternative to the SGA
> > -- as may perhaps be inferred by some from the phrase "(SGA or CCLA)"
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Flicenses%2Fcla-faq.html%23cclas-not-requireddata=02%7C01%7Caharui%40adobe.com%7C7b354edcc5b244d70e7c08d6d98ced18%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636935596691256488sdata=xS2K8uFmOV367uU65bfbmB6XR5IGsdY8OirvNAiyNO4%3Dreserved=0
> >
> > > I like your third sentence.
> > >
> > > HTH,
> > > -Alex
> > >
> > > On 5/13/19, 5:28 PM, "Craig Russell"  wrote:
> > >
> > > The Copyright section of the podling status page says "Check
> and
> > make sure that the papers that transfer rights to the ASF been
> received. It
> > is only necessary to transfer rights for the package, the core code,
> and
> > any new code produced by the project.".
> > >
> > > I'd propose a change:
> > >
> > > "Check to make sure that the papers that transfer rights to
> the ASF
> > been received (SGA or CCLA). It is necessary to transfer rights for
> any
> > existing package and core code. Any new code produced by the project
> must
> > be covered by ICLA."
> > >
> > > This change is proposed because it might not be obvious to
> everyone
> > what "the papers that transfer rights" are. And new code produced
> must be
> > committed by a person who has filed an ICLA.
> > >
> > > Patches welcome.
> > >
> > > Craig L Russell
> > > c...@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
> >
> > -
> > 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
>
-- 
Matt Sicker 

Re: Podling status Copyright section

[Alex Harui]

Hi Matt,

I'm not sure what "add" means, but there have been several past discussions 
where it appears that new code was brought in under a CCLA without an SGA.

https://lists.apache.org/thread.html/d77183d7efd5faf331534edf7ee2de993e908cffa4feb7454f9a6ab1@%3Cgeneral.incubator.apache.org%3E
https://issues.apache.org/jira/browse/LEGAL-236
https://lists.apache.org/thread.html/2814bd99f77325f80c6bfbf1156debd22bf556bfd4b9786996c9217c@1423476452@%3Cgeneral.incubator.apache.org%3E
http://s.apache.org/YPe

It is also my understanding (from Roy) that in some cases existing code can 
come in under an ICLA.

HTH,
-Alex

On 5/15/19, 4:27 PM, "Matt Sicker"  wrote:

You can add a software grant to a CCLA concurrently, but not vice versa.

On Wed, May 15, 2019 at 03:28, sebb  wrote:

> On Wed, 15 May 2019 at 06:55, Alex Harui  wrote:
> >
> > I do not like the words "transfer rights".  It could be interpreted as
> transfer of copyright.  Copyright of existing code is not transferred to
> the ASF, AIUI.  How about "Check to make sure that an SGA or CCLA has been
> received."
> >
> > I don't like hypotheticals, but I can imagine some individual starting a
> project on GitHub, has only a few files already under ALv2, and gets a
> project going at the ASF?  Wouldn't we accept those few files under his
> ICLA and not require an SGA or CCLA?
> >
> > I'd suggest dropping the second sentence ("it is necessary to transfer
> rights...").  AIUI, it is only necessary to grant a perpetual license to
> the ASF.
>
> Also, the CCLA is not required, and is not an alternative to the SGA
> -- as may perhaps be inferred by some from the phrase "(SGA or CCLA)"
>
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Flicenses%2Fcla-faq.html%23cclas-not-requireddata=02%7C01%7Caharui%40adobe.com%7C7b354edcc5b244d70e7c08d6d98ced18%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636935596691256488sdata=xS2K8uFmOV367uU65bfbmB6XR5IGsdY8OirvNAiyNO4%3Dreserved=0
>
> > I like your third sentence.
> >
> > HTH,
> > -Alex
> >
> > On 5/13/19, 5:28 PM, "Craig Russell"  wrote:
> >
> > The Copyright section of the podling status page says "Check and
> make sure that the papers that transfer rights to the ASF been received. 
It
> is only necessary to transfer rights for the package, the core code, and
> any new code produced by the project.".
> >
> > I'd propose a change:
> >
> > "Check to make sure that the papers that transfer rights to the ASF
> been received (SGA or CCLA). It is necessary to transfer rights for any
> existing package and core code. Any new code produced by the project must
> be covered by ICLA."
> >
> > This change is proposed because it might not be obvious to everyone
> what "the papers that transfer rights" are. And new code produced must be
> committed by a person who has filed an ICLA.
> >
> > Patches welcome.
> >
> > Craig L Russell
> > c...@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
>
> -
> 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

[VOTE] Release Apache Zipkin (incubating) version 2.14.0

[Adrian Cole]

Hello IPMC

The Apache Zipkin community has voted on and approved a proposal to release
Apache Zipkin (incubating) version 2.14.0. The voting thread can be found here:

https://lists.apache.org/thread.html/03b215cc4a6e10a7092fe39b6ce87d3a964f35b6e181e12da4d45432@%3Cdev.zipkin.apache.org%3E

This vote is running concurrent with the above, carrying over 3
binding +1 votes from mentors Willem Ning Jiang, Sheng Wu and Andriy
Redko.

We now kindly request the Incubator PMC members review and vote on this
incubator release.

Apache Zipkin (incubating) is a distributed tracing system. It helps
gather timing data needed to troubleshoot latency problems in
microservice architectures. It manages both the collection and lookup
of this data. Zipkin’s design is based on the Google Dapper paper.

This source includes a dependency-free library and a spring-boot
server. Storage options include in-memory, JDBC (mysql), Cassandra,
and Elasticsearch.

The release candidates:
https://dist.apache.org/repos/dist/dev/incubator/zipkin/zipkin/2.14.0/

Git tag for the release:
https://github.com/apache/incubator-zipkin/tree/v2.14.0

Hash for the release tag: 9c2fa2697cdbbd6a3eeb9f87ae6a6ccba2f3c881

Release Notes:
https://github.com/apache/incubator-zipkin/releases/tag/v2.14.0

The artifacts have been signed with Key: BB67A050, which can be found in
the keys file:
https://www.apache.org/dist/incubator/zipkin/KEYS

Verification Hints:
For your convenience, the below includes a detailed how-to on verifying
a source release. Please note that this document is a work-in-progress

https://cwiki.apache.org/confluence/display/ZIPKIN/Verifying+a+Source+
Release

The vote will be open for at least 72 hours or until the necessary number
of votes are reached.

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

Note:

   1. Zipkin-UI contains vendored libraries which will be removed during the
   incubation
   2. A more complete list of issues requiring attention before
graduation is here
https://github.com/apache/incubator-zipkin/issues/2544

Thanks,
The Apache Zipkin (Incubating) Team

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

request: please keep feedback categorized to what's being voted on

[Adrian Cole]

Hi, all.

During a release vote, it can be tempting to tack on feedback about
things not being voted on, but pertain to the eventual graduation of a
project. For example, some glitch about content on a website. In
projects with only one or few codebases, it can maybe make sense to
conflate things related to a vote of one thing with anything about the
project. However, I would expect that projects with a dozen
repositories, that it would be easier to respond in votes only about
things that pertain to what is being voted on.

If there are other things to mention, for example, rosters, web sites
etc, or any other random feedback, please give that. However, I would
ask to please start a new thread sent to the dev@ list if the change
request would not affect the source being voted on.

I would go so far as saying this is just how issues typically work.
For example, ideally an issue is created on the project it relates to,
and comments on an issue should relate to the issue under discussion.
If you think of a release vote as an issue to close, it is possibly
easier to grok why it can make sense and be easier to classify content
like this.

 Yes, it is inconvenient for the IPMC member to start a new email
thread vs tack onto the vote response, but I don't think that is much
to ask. The result is less stress for the project team. In a project
like Zipkin, we have a huge amount of things to do as we have like ten
repos to work on. This leads to a higher level of load and stress,
something we desperately desire.

My 2p.
-A

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