In the other thread you suggested that TDF and TDF Mobile go into the same repo. I can add that to the Infra request, but a) I don’t know if it complicates the task (merging folders from two repos into a single repo) but also b) I thought a major motivation behind the split was so that when we merge from a develop branch to master, we don’t merge too much stuff that wasn’t released into master. If TDF and TDF mobile have different release schedules, they should probably have their own repos. Do they share a lot of code?
-Alex On 4/24/15, 1:38 PM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote: >I don't think losing history is a major concern. The history would be >there even if you delete the files. I believe the concern is transferring >history to the new repo. I believe it is possible as well. > >I like your list and have no objections. > >(Replied in that other thread as well) > >Thanks, >Om > >On Fri, Apr 24, 2015 at 1:25 PM, Alex Harui <aha...@adobe.com> wrote: > >> >> >> On 4/24/15, 1:12 PM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote: >> >> >No objections. I see flex-utilities as a incubator repo where we put >> >things initially. When projects are ready to be released, ideally they >> >should be moved over to their own repos before the first release. >> >> I’m not a git expert so I don’t know how easy it is to move a subset of >>a >> repo to another repo and not lose history. IMO, if Infra has to do it, >>it >> is best for new code donations to land in a new repo of their own. >> >> Anyway, the link to the old thread is [1]. My proposal is copied below: >> >> At the top-level is: >> >> ApacheFXG >> FlexPMD >> Squiggly >> Common >> installerLocaleEditor >> CodeCoverage >> MD5Checker >> TourDeFlex >> Installer >> maven-flex-plugin >> FXGTools >> MobileTrader >> ant_on_air >> installerBadge >> Mavenizer >> >> >> I would argue that we should leave the following in flex-utilities. I >> guess it sort of means that flex-utilities is for code that we don't >>have >> release plans for, but help us do other things like modify FXG files, or >> check MD5s. If we end up wanting to release something in >>flex-utilities, >> hopefully we can later move it to its own repo without losing history. >> >> >> ApacheFXG >> FXGTools >> MD5Checker >> MobileTrader >> CodeCoverage >> >> >> Then we should create more repos as follows: >> flex-installer.git: >> ant_on_air >> Common >> Installer >> installerBadge >> installerLocaleEditor >> >> >> flex-maven.git: >> >> >> Maven-flex-plugin >> Mavenizer >> >> >> flex-squiggly.git >> Squiggly >> >> >> flex-pmd.git >> FlexPMD >> >> >> flex-tdf.git >> TourDeFlex >> >> The thread died when Om wanted to move TDF into flex-examples and I >>asked >> him a question that never got answered. Maybe we can pick up from >>there. >> >> -Alex >> >> [1] http://markmail.org/message/edii4ycwrj3pmor6 >> >> >> > >> >Thanks, >> >Om >> > >> >On Fri, Apr 24, 2015 at 1:08 PM, Alex Harui <aha...@adobe.com> wrote: >> > >> >> I’d prefer #2 because some day we will agree on the plan for >>splitting >> >>up >> >> flex-utilities into separate repos and it will be easier to move and >> >> probably easier to package if if the examples are under >> >>maven-flex-plugin. >> >> Right now, with flex-utilities being shared between releasable >> >>products, >> >> I think it would get messy if I put examples from some other thing >>like >> >> AntOnAir in the same folder. >> >> >> >> Anybody object to re-starting this discussion about splitting up >> >> flex-utilities? >> >> >> >> -Alex >> >> >> >> On 4/24/15, 12:35 PM, "Christofer Dutz" <christofer.d...@c-ware.de> >> >>wrote: >> >> >> >> >Hi, >> >> > >> >> > >> >> >as I am currently writing the Flex Maven tutorials, I would also >>like >> >>to >> >> >prepare some sample projects that demonstrate what I'm writing >>about. >> >> > >> >> > >> >> >What do you thing where I should put these sample projects? >> >> > >> >> >- flex-utilities/examples >> >> > >> >> >- flex-utilities/maven-flex-plugin/examples (should rename this >>to >> >> >flex-maven-plugin anyway) >> >> > >> >> >- a third option >> >> > >> >> > >> >> >I would prefer no 1 >> >> > >> >> > >> >> >Chris >> >> >> >> >> >>
