This seems like a great way to manage changes to Flex while giving people complete freedom to fiddle with it. The danger can come, at some point in the future, from git repositories that contain features not compatible with Apache Flex. I would think this could be handled by making sure Apache Flex is known to be the true version and if you are not a developer, just be aware that if you are taking Flex from some other git repository you do so at your own risk.
In other words, if there come to be a bunch of 3rd party IDEs that use Apache Flex and you go and snag a copy of Flex from someone's personal git repository, you run the risk of that Flex SDK not working with your IDE. But I think those things just work themselves out; a vibrant developer community will probably keep such a thing in check. >From what I've been reading about git, this fits perfectly well with how git works and should make everyone's life easier once it gets underway, plus it lets Apache Flex work the "Apache Way". --peter On 8/20/12 3:27 PM, "Carlos Rovira" <carlos.rov...@codeoscopic.com> wrote: >You understand perfectly Peter :) > >2012/8/20 Peter Ent <p...@adobe.com> > >> If I mayŠ >> >> 1. Have Apache Git be the origin for Apache Flex (including branches >>that >> are official). >> 2. Use GitHub to mirror and for additional work and features. This lets >> the community do as the please to explore and modify, test, enhance, >>etc. >> 3. Committers perform the integration from GitHub to the develop and >> release branches on Apache Git once the changes have been validated >>and/or >> voted on. >> >> I'm just reading about Git and trying to digest all of the emails around >> this and this is my current >> take on it all, so forgive any misunderstandings and terminology >>misuses. >> >> --peter >> >> On 8/20/12 2:43 PM, "Alex Harui" <aha...@adobe.com> wrote: >> >> > >> > >> > >> >On 8/20/12 11:34 AM, "Om" <bigosma...@gmail.com> wrote: >> > >> >>> >> >>> What would be the steps to integrate a proposed change if we didn't >>use >> >>> GitHub and we retired the GitHub mirror? >> >>> >> >> >> >> I am sorry, but why would we want to retire the GitHub mirror? Right >> >>now, >> >> it is read-only. If we leave it like that, the community can at >>least >> >>fork >> >> the projects and work on it. >> >> >> >Why couldn't the community make forks/branches from the official Apache >> >Flex >> >Git repo? It would save a step, prevent issues from mirror delays, >>reduce >> >bandwidth on Apache infra. Would we have to make mirror requests of >>Infra >> >for every branch in GBM? That would also be painful. >> >> >> >>> >> >>> GitHub might be great for sharing, if the committers have lots of >>extra >> >>> steps to deal that will be a dis-incentive for reviewing patches. >> >>> >> >> >> >> Agreed. We will have to come up with a way and put pressure on infra >> >>(ha!) >> >> to use such a workflow. >> >> >> >> From my side, I am HIGHLY interested in removing the barriers for >> >>community >> >> participation. Getting an acceptable GitHub workflow is something I >> >>will >> >> be working on soon (after I wrap up what I am doing right now) >> >> >> >I am also interested in getting the community involved, but not at the >> >sacrifice of the Apache Way. As the mentors have warned, we need to >>make >> >sure folks have legally and willingly contributed changes and that only >> >the >> >committers can make those changes. We have to make the workflow safe >>and >> >efficient for the committers as well. It will likely require some >> >balancing. >> > >> >-- >> >Alex Harui >> >Flex SDK Team >> >Adobe Systems, Inc. >> >http://blogs.adobe.com/aharui >> > >> >> > > >-- >Carlos Rovira >Director de Tecnología >M: +34 607 22 60 05 >F: +34 912 35 57 77 ><http://www.codeoscopic.com> >CODEOSCOPIC S.A. <http://www.codeoscopic.com> >Avd. del General Perón, 32 >Planta 10, Puertas P-Q >28020 Madrid
