While I have no problem naming the directory flex/falcon I do understand Om's concern that it is a code name that people may not know. flex/newcompiler isn't very pretty.
Carol On 8/15/12 2 :18PM, "Alex Harui" <aha...@adobe.com> wrote: > > > >On 8/15/12 10:43 AM, "Om" <bigosma...@gmail.com> wrote: > >> On Aug 15, 2012 9:07 AM, "Alex Harui" <aha...@adobe.com> wrote: >>> >>> > >>> >> I agree that it is the way to go in the long run. But, from Gordon's >> description, it does not sound like Falcon its anywhere close to >>achieving >> this. In the short term, making it a top level project creates a >>barrier >> that would prevent people contributing to it. Which in turn would >>delay >> the eventual goal of making a separate release of Falcon. >For me (and I think for everyone else reading this thread so far) >separation >now seems better as it makes it clear you should not add more SDK >dependencies to the compiler. > >>> Features of a single deliverable like the SDK. But I think Falcon >>>should >> be >>> thought of as a separate sub-project. TLF as well. Both Falcon and >>>TLF >> can >>> be involved in SWFs without any other SDK code in it. >> >> Is there any reason why we can't do the same while having Falcon inside >>the >> modules directory? Once we achieve this goal, we can move it out to a >> separate project. >See above. >> >> >> In the end, here is what I am proposing: >> >> Lets keep Falcon inside /flex/trunk/modules/falcon. It would make >>working >> with it much easier. Work on making Falcon sdk-independent can also >> happen here. Once that goal is achieved, we can move it to a too level >> project-by which time it should just be a directory copy. >Well, it is only Wednesday, and so far, nobody has joined your side so on >Thursday, I think we're going to make the tree as Carol most recently >proposed it. >> >> If we still want to make Falcon a top level project, I would like to see >> how the the the typical developer set up would look like. Just saying >> consider it a top level project without figuring out the dev setup is >>not >> very helpful in making such a decision. >> >> Gordon asked the same question and has not been discussed in this >>thread. >> >I'm sure we can figure it out. Flex is already comprised of several other >Apache TLPs like Batik and Velocity. It should be even easier to handle >one >that is actually somewhere else in our own repo. > >IMO, you are arguing against the principle of modularity and/or separation >of concerns. Yes, there is a bit more overhead, but is should be worth >it. >You voted for a much more complex branching strategy supposedly in favor >of >modularity. I'm surprised you are pushing back on it here. > >-- >Alex Harui >Flex SDK Team >Adobe Systems, Inc. >http://blogs.adobe.com/aharui >
