weex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Piotrowski <piotrow...@gmail.com>
Subject Re: Weex, Apache and outside code
Date Fri, 01 Feb 2019 10:30:07 GMT

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.


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

Am Fr., 1. Feb. 2019 um 11:13 Uhr schrieb Adam Feng <cxfeng1@gmail.com>:
> Hi, all
> I suppose it's not just about the workload for Dan, it’s what do we think of the
> 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 <faterrole@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 <myrle@apache.org> 于2019年2月1日周五 下午4:32写道:
> >
> > > Hello Dan,
> > >
> > > One answer inline below.
> > >
> > > On Fri, Feb 1, 2019 at 8:07 AM Dan <faterrole@gmail.com> wrote:
> > >
> > > > > About move weex-toolkit project into the Apache repo.
> > > >
> > > > For now, this is a little difficult and also inconvenient thing cause
> > > > 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.)
> > >

View raw message