> 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.)
> >>>>
>
