Re: Update weex descriptions on Apache site

[Willem Jiang]

Yes, the website is generated from the XML file. Can you try to update
the file yourself?
The Apache Member has the right to change it but I'm such if the PPMC
has the same right to updated the file.


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Thu, Jan 31, 2019 at 11:10 AM York Shen  wrote:
>
> I found the content of the weex website 
> (http://incubator.apache.org/projects/weex.html 
> ) is written by XML 
> https://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/weex.xml
>  
> 
>  .
>
> Do I need to change the XML file directly or is the XML file generated by 
> another file like xxx.html and I should change xxx.html?
>
> Best Regards,
> York Shen
>
> 申远
>
> > 在 2019年1月29日，09:00，Willem Jiang  写道：
> >
> > The website is generated from the here[1]. You may need to Apache
> > member right to edit it.
> > If you cannot change it, please let me know the change, I'd happy to
> > update it for you.
> >
> > [1]https://svn.apache.org/repos/asf/incubator/public/trunk
> > [2]https://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/weex.xml
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Wed, Jan 16, 2019 at 8:49 PM 申远  wrote:
> >>
> >> Hi, there
> >>
> >> I’d like to update the page of weex 
> >> http://incubator.apache.org/projects/weex.html 
> >>  , it seems like outdated. 
> >> I didn’t find any editing button on the page, it would be great if some 
> >> could tell me how to edit that page.
> >>
> >> Thanks
>

Re: Weex, Apache and outside code

[Jan Piotrowski]

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

Have a nice holiday you all!

-J

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

Re: Weex, Apache and outside code

[York Shen]

> Who goes ahead and does the first version as a PR?
May be Dan could the job?

BTW, as Chinese lunar year is coming, some of weex’s committers & contributor 
(include Dan and me) may take a vacation for one or two weeks. We may finish 
the document work when vacation is over.

> Thanks for the explanation of the domain. Confusing.
> draft.weex.apache.org  would work and 
> communicate much better.
Actually, I couldn’t find a way to deploy to draft.weex.apache.org 
. It seems like Gitpubsub will deploy the 
asf-site branch of incubator-weex-site 
 to weex.apache.org 
 automatically. In order to have more fine control 
when deploying, we use another domain called https://weex.io  
.

If there is a way to deploy website to draft.weex.apache.org 
 , I’d really like to learn. Any help or advise 
on the domain issue?


> 在 2019年2月1日，19:55，Jan Piotrowski  写道：
> 
>> I totally agree with you. I think the first step is listing all the 
>> corresponding toolchain and their relationship between weex in the document 
>> clearly(e.g. xxx is official, and  is third party plugin). Moving 
>> weex-toolkit to Apache repos will be a huge according to my understanding, 
>> maybe we should talk this later in another thread after we finished the 
>> document work first.
> 
> Awesome. Who goes ahead and does the first version as a PR? I am happy
> to jump in when something is up and give feedback on how to improve
> the list - but you are probably _much_ faster in collecting the
> relevant repos and giving them a bit of context.
> 
>> weex.io is based on ...
> 
> Thanks for the explanation of the domain. Confusing.
> draft.weex.apache.org would work and communicate much better.
> 
> You should check with Apache Incubator first if weex.io as a domain
> will work. Cordova is officially cordova.apache.org although we have
> cordova.io as a short domain. This might be required for Apache
> projects - and actually makes sense from a branding perspective!
> 
> -J
> 
> 
> Am Fr., 1. Feb. 2019 um 12:19 Uhr schrieb York Shen :
>> 
>> Hi, Jan.
>> 
>>> that are _currently_ connected to Weex and list them on a page on the
>>> documentation. Just a link to the repo and a short description what it
>>> does ("weex-toolkit - A CLI for creating and managing Weex based
>>> applications", "weex-pack - Scripts to run and build Weex apps for
>>> different platforms (used by weex-toolkit)" etc). That would give a
>>> first overview and help to decide which should be migrated when.
>> 
>> I totally agree with you. I think the first step is listing all the 
>> corresponding toolchain and their relationship between weex in the document 
>> clearly(e.g. xxx is official, and  is third party plugin). Moving 
>> weex-toolkit to Apache repos will be a huge according to my understanding, 
>> maybe we should talk this later in another thread after we finished the 
>> document work first.
>> 
>> 
>>> PS: What is https://weex.io/  based on?
>> https://weex.io  is based on the draft branch of 
>> https://github.com/apache/incubator-weex-site 
>>  , other website like 
>> http://weex.incubator.apache.org  and 
>> https://weex-project.io  are based on the master 
>> branch. We are trying to rewrite weex's website and host it on 
>> https://weex.io  . Other URL will be redirect to 
>> https://weex.io  when all the job are done. You may think 
>> https://weex.io  is in beta stage and will be the weex’s 
>> website. We would like to publish https://weex.io  on Weex 
>> conf 2019. Ref this  to 
>> have a deeper view of weex conf 2018.
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远
>> 
>>> 在 2019年2月1日，18:30，Jan Piotrowski  写道：
>>> 
>>> Hi,
>>> 
>>> awesome discussion I started here. Really like your responses.
>>> 
>>> To add some context on the "unreleased code" discussion: For Apache
>>> Cordova we have official, voted releases, but all tooling can also be
>>> installed from git directly (`npm install -g cordova` vs. `npm install
>>> -g https://github.com/apache/cordova-cli` or even `git clone
>>> https://github.com/apache/cordova-cli` with `npm link`). We also have
>>> a cronjob that creates nightly builds and pushes them to npm, so those
>>> can be tested. That way normal users do use the normal, stable, voted
>>> Apache releases - and maintainers and more active users can still use
>>> the newest stuff. For Apache it is only important that only the
>>> official releases are marketed to users, because only those have the
>>> "seal of approval" from the PMC by voting.
>>> 
>>> Maybe a freat first step would be to ident

Re: Weex, Apache and outside code

[Jan Piotrowski]

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

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

> weex.io is based on ...

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

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

-J


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

Re: Weex, Apache and outside code

[York Shen]

Hi, Jan.

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

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


> PS: What is https://weex.io/  based on?
https://weex.io  is based on the draft branch of 
https://github.com/apache/incubator-weex-site 
 , other website like 
http://weex.incubator.apache.org  and 
https://weex-project.io  are based on the master 
branch. We are trying to rewrite weex's website and host it on https://weex.io 
 . Other URL will be redirect to https://weex.io 
 when all the job are done. You may think https://weex.io 
 is in beta stage and will be the weex’s website. We would 
like to publish https://weex.io  on Weex conf 2019. Ref this 
 to have a deeper view of 
weex conf 2018.

Best Regards,
York Shen

申远

> 在 2019年2月1日，18:30，Jan Piotrowski  写道：
> 
> Hi,
> 
> awesome discussion I started here. Really like your responses.
> 
> To add some context on the "unreleased code" discussion: For Apache
> Cordova we have official, voted releases, but all tooling can also be
> installed from git directly (`npm install -g cordova` vs. `npm install
> -g https://github.com/apache/cordova-cli` or even `git clone
> https://github.com/apache/cordova-cli` with `npm link`). We also have
> a cronjob that creates nightly builds and pushes them to npm, so those
> can be tested. That way normal users do use the normal, stable, voted
> Apache releases - and maintainers and more active users can still use
> the newest stuff. For Apache it is only important that only the
> official releases are marketed to users, because only those have the
> "seal of approval" from the PMC by voting.
> 
> Maybe a freat first step would be to identify all the repositories
> that are _currently_ connected to Weex and list them on a page on the
> documentation. Just a link to the repo and a short description what it
> does ("weex-toolkit - A CLI for creating and managing Weex based
> applications", "weex-pack - Scripts to run and build Weex apps for
> different platforms (used by weex-toolkit)" etc). That would give a
> first overview and help to decide which should be migrated when.
> 
> Thanks to Dan for explaining a bit about _why_ stuff is how it is. As
> usual, it can be summarized as "it just grew that way" and that is
> perfectly fine. One of the benefits of being an Apache project is that
> the rules force a bit of clarity here and make you clean up, so users
> don't send emails like the one I did. I am happy you are all moving
> forward here instead of just blocking. I think this could be really
> great for the Weex project.
> 
> Best,
> Jan
> 
> PS: What is https://weex.io/ based on?
> 
> 
> Am Fr., 1. Feb. 2019 um 11:13 Uhr schrieb Adam Feng :
>> 
>> Hi, all
>> 
>> I suppose it's not just about the workload for Dan， it’s what do we think of 
>> the project.
>> 
>> At first, Weex has no toolkits,  and thanks for Dan and other maintainer’s 
>> work, Weex has a good tool for starting guide,  and we link to it in our 
>> official site .
>> 
>> Maybe there should be a more in-depth discussion about whether toolkit 
>> should be a part of Apache Weex， in my opinion,  it should be but is not 
>> yet,  at present Weex focus on “framework” and focus on how to be integrated 
>> into mobile environment ,  which is used without toolkit,  toolkit is a 
>> pluses but not a requirement.
>> 
>> Dan is a strong developer and develop toolkit almost by himself,  but we 
>> need more discussions and interactions between Weex repo and toolkit repo,  
>> not only just a link and a part of document. I’m looking forward to the 
>> “official” toolkit.
>> 
>> Other opinions are really important,  maybe I’m too “cleanliness”.
>> 
>> 
>> 
>> Thanks.
>> Adam Feng
>> 在 2019年2月1日 +0800 PM5:29，Dan ，写道：
>>> Hi Myrle,
>>> 
>>> At present, I can think of the difficulties mainly in the following aspects:
>>> 
>>> 1. I'm not very understanding of apache's workflow at present, and also I'm
>>> not a committer for Apache weex now, I should be voted to be a committer
>>> firstly.
>>> 2. The migr

Re: Weex, Apache and outside code

[Jan Piotrowski]

Hi,

awesome discussion I started here. Really like your responses.

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

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

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

Best,
Jan

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


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

Re: Weex, Apache and outside code

[Adam Feng]

Hi, all

I suppose it's not just about the workload for Dan， it’s what do we think of 
the project.

At first, Weex has no toolkits,  and thanks for Dan and other maintainer’s 
work, Weex has a good tool for starting guide,  and we link to it in our 
official site .

Maybe there should be a more in-depth discussion about whether toolkit should 
be a part of Apache Weex， in my opinion,  it should be but is not yet,  at 
present Weex focus on “framework” and focus on how to be integrated into mobile 
environment ,  which is used without toolkit,  toolkit is a pluses but not a 
requirement.

Dan is a strong developer and develop toolkit almost by himself,  but we need 
more discussions and interactions between Weex repo and toolkit repo,  not only 
just a link and a part of document. I’m looking forward to the “official” 
toolkit.

 Other opinions are really important,  maybe I’m too “cleanliness”.



Thanks.
Adam Feng
在 2019年2月1日 +0800 PM5:29，Dan ，写道：
> Hi Myrle,
>
> At present, I can think of the difficulties mainly in the following aspects:
>
> 1. I'm not very understanding of apache's workflow at present, and also I'm
> not a committer for Apache weex now, I should be voted to be a committer
> firstly.
> 2. The migration of the warehouse may cause some historical issues to
> continue to track, the new repo will start from 0 (that's no bad, but a big
> change).
> 3. I need to re-adjust my code and follow the apache approach, which also
> has a certain cost for me, and now I was the only one who works on the
> weex toolchain.
>
> Maybe this issue can be resolved, but I'm not sure how much time I need to
> complete this thing.
>
> I look forward to more comments and discussions to get this matter going.
>
> Thanks.
> Dan
>
> Myrle Krantz  于2019年2月1日周五 下午4:32写道：
>
> > Hello Dan,
> >
> > One answer inline below.
> >
> > On Fri, Feb 1, 2019 at 8:07 AM Dan  wrote:
> >
> > > > About move weex-toolkit project into the Apache repo.
> > >
> > > For now, this is a little difficult and also inconvenient thing cause the
> > > current 2.0 tools are in a state of rapid iteration, and I also hope to
> > > get
> > > the user's usage from the tool, this may not be allowed by apache, I
> > > prefer
> > > to develop these tools as a third-party developer, it should be ok to
> > > remind users in the documentation that it's not part of Apache
> >
> >
> > This is a common misconception. Code does not have to be complete to be
> > developed at Apache. Rapid prototyping and user feedback are important
> > parts of all software development whether at Apache or elsewhere. For an
> > example of a project currently doing this in incubation see PLC4X.
> >
> > Can you explain in more detail what makes development within an Apache
> > GitHub repository difficult for you? Perhaps it’s an issue that can be
> > resolved?
> >
> > It’s important that the Weex PPMC resolves this. A project which is split
> > in this way cannot be effectively governed by the Weex PMC. The governance
> > imbalance can cause distortions in the code architecture. More important:
> > it can damage the community.
> >
> > Best Regards,
> > Myrle
> >
> > (I speak from experience: I made exactly this mistake when I first became
> > involved with Apache.)
> >

Re: Weex, Apache and outside code

[Dan]

Hi, Willem

As the toolchain is not a necessary part of Weex framework and will not be
published follow the Weex SDK, I thought the SNAPSHOT tag release cannot be
worked on that issue.

Thanks.
Dan




Willem Jiang  于2019年2月1日周五 下午5:34写道：

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

Re: Weex, Apache and outside code

[Willem Jiang]

Here is instruction of distribution unrelease materials[1],  as the
SNAPSHOT means it's not official release, we just use it for the
feedback the development.

[1]https://www.apache.org/dev/release-distribution#unreleased

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Feb 1, 2019 at 4:44 PM York Shen  wrote:
>
> According to my understanding and what Justin Mclean wrote 
> https://lists.apache.org/thread.html/5c5a75f00d78211f75e10d17bfeb05bc7b0b4f9e8416fa602b0ebb54@%3Cgeneral.incubator.apache.org%3E
>  
> 
>  , any format of unofficial release is forbidden, all release must be voted 
> before we publish it.
>
> Correct me if I am wrong.
>
>
> Best Regards,
> York Shen
>
> 申远
>
> > 在 2019年2月1日，16:27，Willem Jiang  写道：
> >
> > A lot of Apache project has the SNAPSHOT release to get quick feedback
> > from the community.
> > It's OK if we don't announce the  SNAPSHOT release as an office Apache 
> > release.
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Fri, Feb 1, 2019 at 3:07 PM Dan  wrote:
> >>
> >> Hey
> >>
> >> I'm the author of the weex-toolkit, also the main developer of the tools
> >> around weex, I need to explain the questions you mentioned above.
> >>
> >>> Is this redirection and inclusion of outside code intentional? Is this
> >> temporary or meant to be permanent?
> >> Early in the development and maintenance of this project, the project was
> >> designed to support package integration of multiple command line tools, and
> >> to manage mappings between them through xtoolkit module, the idea is good,
> >> but too many projects are scattered into the various git repo, such as
> >> weex-debugger, weex-pack and so on.
> >>
> >> On the weex-toolkit@2.0,  I'm split each function module into separate
> >> parts, and manage multiple separate releases in the repository via Lerna,
> >> after that you can find all the module you want in the weex-toolkit repo
> >> (currently in the alpha process), you can enjoy it follow the document
> >> here: https://weex.io/tools/toolkit.html, it also supports the thrid-part
> >> extensions, the document will be further supplemented
> >>
> >>> About move weex-toolkit project into the Apache repo.
> >>
> >> For now, this is a little difficult and also inconvenient thing cause the
> >> current 2.0 tools are in a state of rapid iteration, and I also hope to get
> >> the user's usage from the tool, this may not be allowed by apache, I prefer
> >> to develop these tools as a third-party developer, it should be ok to
> >> remind users in the documentation that it's not part of Apache Weex.
> >>
> >>> why the module called toolkit but not cli?
> >>
> >> This is the name defined by the previous module creator. I personally think
> >> it might be better to call it weex-cli. Maybe I will consider renaming the
> >> module soon.
> >>
> >> Thanks
> >> Dan
> >>
> >> Jan Piotrowski  于2019年2月1日周五 上午3:13写道：
> >>
> >>> (Answering from my Apache address as my Gmail didn't receive your
> >>> responses - I can only see them in the list archive. Strange.)
> >>>
> >>> Thanks York Shen and Willem Jiang for your answers.
> >>>
>  As there are many Weex users coming from China and the GFW is a huge
> >>> problem for them, so we create several website for users from China to 
> >>> have
> >>> the right access. You can choose whatever you want, as the three websites
> >>> are all the same.
> >>>
> >>> Thanks for that explanation.
> >>>
> >>> In my opinion (and maybe Apache guidelines?) there should only be _one_
> >>> domain per Apache project, so you know you can trust the content of that
> >>> domain. You (the team) should probably decide which one of the two
> >>> apache.org domains you should use (and can use per incubation rules!),
> >>> and redirect the other one. Otherwise both Google and users can be
> >>> confused.
> >>> For the non-Apache mirrors for Chinese users you could maybe add a banner
> >>> that this is a mirror of *.apache.org for Chinese users and link to it
> >>> from somewhere _on_ the site so it is discoverable? Additionally maybe
> >>> no-index the domain, so Google doesn't list them? Then it is all
> >>> transparent and there is no confusion.
> >>>
>  The repo for weex is https://github.com/apache/incubator-weex, from
> >>> where weex community generates apache release.
>  All the other repos is not officially belong to weex, though some of are
> >>> useful tools for debug, development purpose. They are just useful tools,
> >>> one can using weex framework without these tools with no problem. I will
> >>> consider these tools as useful plugins, and there are perhaps tens of such
> >>> plugins, so they are not under Apache repositories.
>  I will ask the authors of  https://github.com/weexteam/xtoolkit and
> >>> https://github.com/weexteam/weex-pack, not sure whether there is a
> 

Re: Weex, Apache and outside code

[Dan]

Hi Myrle,

At present, I can think of the difficulties mainly in the following aspects:

1. I'm not very understanding of apache's workflow at present, and also I'm
not a committer for Apache weex now, I should be voted to be a committer
firstly.
2. The migration of the warehouse may cause some historical issues to
continue to track, the new repo will start from 0 (that's no bad, but a big
change).
3. I need to re-adjust my code and follow the apache approach, which also
has a certain cost for me, and now I was the only one who works on the
weex toolchain.

Maybe this issue can be resolved, but I'm not sure how much time I need to
complete this thing.

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

Thanks.
Dan

Myrle Krantz  于2019年2月1日周五 下午4:32写道：

> Hello Dan,
>
> One answer inline below.
>
> On Fri, Feb 1, 2019 at 8:07 AM Dan  wrote:
>
>> > About move weex-toolkit project into the Apache repo.
>>
>> For now, this is a little difficult and also inconvenient thing cause the
>> current 2.0 tools are in a state of rapid iteration, and I also hope to
>> get
>> the user's usage from the tool, this may not be allowed by apache, I
>> prefer
>> to develop these tools as a third-party developer, it should be ok to
>> remind users in the documentation that it's not part of Apache
>
>
> This is a common misconception. Code does not have to be complete to be
> developed at Apache.  Rapid prototyping and user feedback are important
> parts of all software development whether at Apache or elsewhere. For an
> example of a project currently doing this in incubation see PLC4X.
>
> Can you explain in more detail what makes development within an Apache
> GitHub repository difficult for you? Perhaps it’s an issue that can be
> resolved?
>
> It’s important that the Weex PPMC resolves this. A project which is split
> in this way cannot be effectively governed by the Weex PMC.  The governance
> imbalance can cause distortions in the code architecture. More important:
> it can damage the community.
>
> Best Regards,
> Myrle
>
> (I speak from experience: I made exactly this mistake when I first became
> involved with Apache.)
>

Re: Weex, Apache and outside code

[York Shen]

According to my understanding and what Justin Mclean wrote 
https://lists.apache.org/thread.html/5c5a75f00d78211f75e10d17bfeb05bc7b0b4f9e8416fa602b0ebb54@%3Cgeneral.incubator.apache.org%3E
 

 , any format of unofficial release is forbidden, all release must be voted 
before we publish it.

Correct me if I am wrong.


Best Regards,
York Shen

申远

> 在 2019年2月1日，16:27，Willem Jiang  写道：
> 
> A lot of Apache project has the SNAPSHOT release to get quick feedback
> from the community.
> It's OK if we don't announce the  SNAPSHOT release as an office Apache 
> release.
> 
> 
> Willem Jiang
> 
> Twitter: willemjiang
> Weibo: 姜宁willem
> 
> On Fri, Feb 1, 2019 at 3:07 PM Dan  wrote:
>> 
>> Hey
>> 
>> I'm the author of the weex-toolkit, also the main developer of the tools
>> around weex, I need to explain the questions you mentioned above.
>> 
>>> Is this redirection and inclusion of outside code intentional? Is this
>> temporary or meant to be permanent?
>> Early in the development and maintenance of this project, the project was
>> designed to support package integration of multiple command line tools, and
>> to manage mappings between them through xtoolkit module, the idea is good,
>> but too many projects are scattered into the various git repo, such as
>> weex-debugger, weex-pack and so on.
>> 
>> On the weex-toolkit@2.0,  I'm split each function module into separate
>> parts, and manage multiple separate releases in the repository via Lerna,
>> after that you can find all the module you want in the weex-toolkit repo
>> (currently in the alpha process), you can enjoy it follow the document
>> here: https://weex.io/tools/toolkit.html, it also supports the thrid-part
>> extensions, the document will be further supplemented
>> 
>>> About move weex-toolkit project into the Apache repo.
>> 
>> For now, this is a little difficult and also inconvenient thing cause the
>> current 2.0 tools are in a state of rapid iteration, and I also hope to get
>> the user's usage from the tool, this may not be allowed by apache, I prefer
>> to develop these tools as a third-party developer, it should be ok to
>> remind users in the documentation that it's not part of Apache Weex.
>> 
>>> why the module called toolkit but not cli?
>> 
>> This is the name defined by the previous module creator. I personally think
>> it might be better to call it weex-cli. Maybe I will consider renaming the
>> module soon.
>> 
>> Thanks
>> Dan
>> 
>> Jan Piotrowski  于2019年2月1日周五 上午3:13写道：
>> 
>>> (Answering from my Apache address as my Gmail didn't receive your
>>> responses - I can only see them in the list archive. Strange.)
>>> 
>>> Thanks York Shen and Willem Jiang for your answers.
>>> 
 As there are many Weex users coming from China and the GFW is a huge
>>> problem for them, so we create several website for users from China to have
>>> the right access. You can choose whatever you want, as the three websites
>>> are all the same.
>>> 
>>> Thanks for that explanation.
>>> 
>>> In my opinion (and maybe Apache guidelines?) there should only be _one_
>>> domain per Apache project, so you know you can trust the content of that
>>> domain. You (the team) should probably decide which one of the two
>>> apache.org domains you should use (and can use per incubation rules!),
>>> and redirect the other one. Otherwise both Google and users can be
>>> confused.
>>> For the non-Apache mirrors for Chinese users you could maybe add a banner
>>> that this is a mirror of *.apache.org for Chinese users and link to it
>>> from somewhere _on_ the site so it is discoverable? Additionally maybe
>>> no-index the domain, so Google doesn't list them? Then it is all
>>> transparent and there is no confusion.
>>> 
 The repo for weex is https://github.com/apache/incubator-weex, from
>>> where weex community generates apache release.
 All the other repos is not officially belong to weex, though some of are
>>> useful tools for debug, development purpose. They are just useful tools,
>>> one can using weex framework without these tools with no problem. I will
>>> consider these tools as useful plugins, and there are perhaps tens of such
>>> plugins, so they are not under Apache repositories.
 I will ask the authors of  https://github.com/weexteam/xtoolkit and
>>> https://github.com/weexteam/weex-pack, not sure whether there is a
>>> license issue or they are happy to move into Apache Weex  umbrella
>>> officially.
>>> 
>>> The documentation and guides made them sound very much a part of Weex - so
>>> if in any way possible you should move _all_ the tools, plugins,
>>> playground, and other pieces that are used in the documentation and
>>> examples to Apache repositories (PMC members and committers can create
>>> additional repositories at https://gitbox.apache.org/setup/newrepo.html).
>>> 
>>> If you can't transfer any of the code f

Re: Weex, Apache and outside code

[Myrle Krantz]

Hello Dan,

One answer inline below.

On Fri, Feb 1, 2019 at 8:07 AM Dan  wrote:

> > About move weex-toolkit project into the Apache repo.
>
> For now, this is a little difficult and also inconvenient thing cause the
> current 2.0 tools are in a state of rapid iteration, and I also hope to get
> the user's usage from the tool, this may not be allowed by apache, I prefer
> to develop these tools as a third-party developer, it should be ok to
> remind users in the documentation that it's not part of Apache


This is a common misconception. Code does not have to be complete to be
developed at Apache.  Rapid prototyping and user feedback are important
parts of all software development whether at Apache or elsewhere. For an
example of a project currently doing this in incubation see PLC4X.

Can you explain in more detail what makes development within an Apache
GitHub repository difficult for you? Perhaps it’s an issue that can be
resolved?

It’s important that the Weex PPMC resolves this. A project which is split
in this way cannot be effectively governed by the Weex PMC.  The governance
imbalance can cause distortions in the code architecture. More important:
it can damage the community.

Best Regards,
Myrle

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

Re: Weex, Apache and outside code

[Willem Jiang]

A lot of Apache project has the SNAPSHOT release to get quick feedback
from the community.
It's OK if we don't announce the  SNAPSHOT release as an office Apache release.


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Feb 1, 2019 at 3:07 PM Dan  wrote:
>
> Hey
>
> I'm the author of the weex-toolkit, also the main developer of the tools
> around weex, I need to explain the questions you mentioned above.
>
> > Is this redirection and inclusion of outside code intentional? Is this
> temporary or meant to be permanent?
> Early in the development and maintenance of this project, the project was
> designed to support package integration of multiple command line tools, and
> to manage mappings between them through xtoolkit module, the idea is good,
> but too many projects are scattered into the various git repo, such as
> weex-debugger, weex-pack and so on.
>
> On the weex-toolkit@2.0,  I'm split each function module into separate
> parts, and manage multiple separate releases in the repository via Lerna,
> after that you can find all the module you want in the weex-toolkit repo
> (currently in the alpha process), you can enjoy it follow the document
> here: https://weex.io/tools/toolkit.html, it also supports the thrid-part
> extensions, the document will be further supplemented
>
> > About move weex-toolkit project into the Apache repo.
>
> For now, this is a little difficult and also inconvenient thing cause the
> current 2.0 tools are in a state of rapid iteration, and I also hope to get
> the user's usage from the tool, this may not be allowed by apache, I prefer
> to develop these tools as a third-party developer, it should be ok to
> remind users in the documentation that it's not part of Apache Weex.
>
> > why the module called toolkit but not cli?
>
> This is the name defined by the previous module creator. I personally think
> it might be better to call it weex-cli. Maybe I will consider renaming the
> module soon.
>
> Thanks
> Dan
>
> Jan Piotrowski  于2019年2月1日周五 上午3:13写道：
>
> > (Answering from my Apache address as my Gmail didn't receive your
> > responses - I can only see them in the list archive. Strange.)
> >
> > Thanks York Shen and Willem Jiang for your answers.
> >
> > > As there are many Weex users coming from China and the GFW is a huge
> > problem for them, so we create several website for users from China to have
> > the right access. You can choose whatever you want, as the three websites
> > are all the same.
> >
> > Thanks for that explanation.
> >
> > In my opinion (and maybe Apache guidelines?) there should only be _one_
> > domain per Apache project, so you know you can trust the content of that
> > domain. You (the team) should probably decide which one of the two
> > apache.org domains you should use (and can use per incubation rules!),
> > and redirect the other one. Otherwise both Google and users can be
> > confused.
> > For the non-Apache mirrors for Chinese users you could maybe add a banner
> > that this is a mirror of *.apache.org for Chinese users and link to it
> > from somewhere _on_ the site so it is discoverable? Additionally maybe
> > no-index the domain, so Google doesn't list them? Then it is all
> > transparent and there is no confusion.
> >
> > > The repo for weex is https://github.com/apache/incubator-weex, from
> > where weex community generates apache release.
> > > All the other repos is not officially belong to weex, though some of are
> > useful tools for debug, development purpose. They are just useful tools,
> > one can using weex framework without these tools with no problem. I will
> > consider these tools as useful plugins, and there are perhaps tens of such
> > plugins, so they are not under Apache repositories.
> > > I will ask the authors of  https://github.com/weexteam/xtoolkit and
> > https://github.com/weexteam/weex-pack, not sure whether there is a
> > license issue or they are happy to move into Apache Weex  umbrella
> > officially.
> >
> > The documentation and guides made them sound very much a part of Weex - so
> > if in any way possible you should move _all_ the tools, plugins,
> > playground, and other pieces that are used in the documentation and
> > examples to Apache repositories (PMC members and committers can create
> > additional repositories at https://gitbox.apache.org/setup/newrepo.html).
> >
> > If you can't transfer any of the code for licence reasons, it should be
> > clearly documented in the documentation when you advise users to use it
> > that this is not part of Apache Weex, but a user space plugin or project.
> >
> > From a user standpoint, if I use an Apache project I want to know that I
> > can trust all the project code. With parts of the source code being
> > downloaded (especially if not via npm!) from some other repository,
> > installed and executed, I can't do that. (Additionally there have to be
> > release processes with votes etc. that make sure that what gets published
> > on npm actually matches wh