> 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 <[email protected]>: > > 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 <[email protected]> 写道： > > > > 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 <[email protected]>: > >> > >> 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 <[email protected]>，写道： > >>> 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 <[email protected]> 于2019年2月1日周五 下午4:32写道： > >>> > >>>> Hello Dan, > >>>> > >>>> One answer inline below. > >>>> > >>>> On Fri, Feb 1, 2019 at 8:07 AM Dan <[email protected]> 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.) > >>>> >
