flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlos.rov...@codeoscopic.com>
Subject Re: [FlexJS] - Is FlexJS ready for production?
Date Thu, 09 Feb 2017 21:59:28 GMT
And what about start a project in Github for a port of Lizhis code?
That would keep it separate, and we could make it compatible with our code.
I think Lizhi is not very close to this project and maybe he could continue
his work
in his own code, maybe not... In a perfect world he could lead the effort
and
maintain and evolution his own code base to work close to Apache FlexJS
but at least for now, that seem's not the case...


2017-02-09 18:38 GMT+01:00 OmPrakash Muppirala <bigosmallm@gmail.com>:

> On Feb 9, 2017 8:15 AM, "Alex Harui" <aharui@adobe.com> wrote:
>
>
>
> On 2/9/17, 12:58 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
> wrote:
>
> >Hi Alex,
> >
> >I think it would be great to refactor ir and bring it here. Although, I
> >have some things on my plate already, so maybe more later.
>
> If folks help Lizhi clean it up and we get enough votes to bring it here,
> then I won't stand in the way.  Let me point out some reasons not to bring
> it here for folks to think about:
>
> 1) Apache doesn't like "umbrella projects".  I don't exactly know why and
> haven't dug into it, but apparently there were some umbrella projects in
> the past that ran into trouble and the solution was to split the big
> project into several projects.  Starting up a project is definitely harder
> than bringing in code to an existing project, so I understand the
> temptation to keep bringing more things under Apache Flex.
>
> 2) Scalability:  In one vision of a wildly successful future for FlexJS,
> we'd ship even fewer SWCs than we do now.  The Jquery folks would take
> over the Jquery SWCs.   They'd export the code from our repos to their
> repos and release them on their own schedule.  We would remove the code
> from our repos.  Same for CreateJS, GoogleMaps, etc.  IMO, we are only
> providing these SWCs for now as a proof of concept.  I can't imagine the
> amount of list traffic involved if we had one huge monolithic release of
> every AS library in the world.
>
>
> I get what you are saying,  but this does not usually happen.   Angular,
> Typescript etc shims for popular libraries like Highcharts, D3 etc. are
> maintained by volunteers who are not affiliated to either the framework or
> the library.  I believe that is healthy situation.
>
> That said,  I think if the version of Starling that Lizhi is developing is
> a separate apache project,  it would attract the right kind of community.
>
> Just my 2 cents.
>
> Thanks,
> Om
>
>
>
> And I can't imagine the amount of list
> traffic if we had 200 third-party libraries all on their own release
> schedule.  In short, I would prefer that we build an ecosystem of
> third-parties rather than have everyone have to go through our community
> in order to release.  Even JIRA doesn't really handle categorization of
> bugs in a hierarchical fashion.
>
> So, I'm not sure what the right answer is, but we'll discuss it more when
> Lizhi's code becomes more ready.
>
> -Alex
>



-- 

Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es

Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message