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 <shenyua...@gmail.com>: > > > Who goes ahead and does the first version as a PR? > May be Dan could the job? > > BTW, as Chinese lunar year is coming, some of weex’s committers & contributor > (include Dan and me) may take a vacation for one or two weeks. We may finish > the document work when vacation is over. > > > Thanks for the explanation of the domain. Confusing. > > draft.weex.apache.org <http://draft.weex.apache.org/> would work and > > communicate much better. > Actually, I couldn’t find a way to deploy to draft.weex.apache.org > <http://draft.weex.apache.org/>. It seems like Gitpubsub will deploy the > asf-site branch of incubator-weex-site > <https://github.com/apache/incubator-weex-site/> to weex.apache.org > <http://weex.apache.org/> automatically. In order to have more fine control > when deploying, we use another domain called https://weex.io > <https://weex.io/> . > > If there is a way to deploy website to draft.weex.apache.org > <http://draft.weex.apache.org/> , I’d really like to learn. Any help or > advise on the domain issue? > > > > 在 2019年2月1日，19:55，Jan Piotrowski <piotrow...@gmail.com> 写道： > > > >> 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 xxxx 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 <shenyua...@gmail.com>: > >> > >> 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 xxxx is third party plugin). > >> Moving weex-toolkit to Apache repos will be a huge according to my > >> understanding, maybe we should talk this later in another thread after we > >> finished the document work first. > >> > >> > >>> PS: What is https://weex.io/ <https://weex.io/> based on? > >> https://weex.io <https://weex.io/> is based on the draft branch of > >> https://github.com/apache/incubator-weex-site > >> <https://github.com/apache/incubator-weex-site> , other website like > >> http://weex.incubator.apache.org <http://weex.incubator.apache.org/> and > >> https://weex-project.io <https://weex-project.io/> are based on the master > >> branch. We are trying to rewrite weex's website and host it on > >> https://weex.io <https://weex.io/> . Other URL will be redirect to > >> https://weex.io <https://weex.io/> when all the job are done. You may > >> think https://weex.io <https://weex.io/> is in beta stage and will be the > >> weex’s website. We would like to publish https://weex.io > >> <https://weex.io/> on Weex conf 2019. Ref this > >> <http://weex-project.io/weexConf2018/index-en.html> to have a deeper view > >> of weex conf 2018. > >> > >> Best Regards, > >> York Shen > >> > >> 申远 > >> > >>> 在 2019年2月1日，18:30，Jan Piotrowski <piotrow...@gmail.com> 写道： > >>> > >>> 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 <cxfe...@gmail.com>: > >>>> > >>>> 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 <faterr...@gmail.com>，写道： > >>>>> 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 <my...@apache.org> 于2019年2月1日周五 下午4:32写道： > >>>>> > >>>>>> Hello Dan, > >>>>>> > >>>>>> One answer inline below. > >>>>>> > >>>>>> On Fri, Feb 1, 2019 at 8:07 AM Dan <faterr...@gmail.com> 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.) > >>>>>> > >> >
