Le 17/09/2011 20:26, Vivian Meazza a écrit : > Cedric wrote > >> I hope this is the last time we will have to discuss this topic, since >> over the last months it seemed that everyone agreed with that FGDATA >> >> - has to be split sometime >> - should be split a.s.a.p. >> >> We agreed that after the current release of 2.4 would be a good point to >> get the project on the way. As I offered and it still stands, I will >> take care of writing the bash script which "splits" the current FGDATA >> repository into multiple repositories and leaves an FGDATA repository >> which holds merely the bare essentials which supplement the core binary >> of fgfs. One could classify the contents of the new FGDATA by saying >> that it's data which provides the technical backbone - the common >> denominator everything is based upon. >> >> I'd like to cease this opportunity to give everyone the chance to utter >> their possible disagreement with the project or their respective >> opinions and discuss the very details of the split, which have not yet >> been determined. >> >> The general boundary conditions of the splitting process are the >> following: >> >> - FGDATA shall consist of everything which is essential for the binary >> to run and shall not hold any data which is specific to certain >> airports or airplanes. Those should be provided in separate >> repositories the structure of which is not of current interest and >> might possibly be chosen by the respective authors. >> >> - The change shall not require restructuring of the architecture, >> including the directory structure. Solely the repositories in which >> the data is contained shall change. >> >> Informatively, I'd like to supply a sensible suggestion for how a final >> structure might look and how, either as a developer or user might use >> it. Particularily, because some of you might wonder how we can strip >> FGDATA of KSFO and the 172p, leaving nothing to fly with - isn't that a >> bad decision? >> >> Definitly not. One has to distinguish between a proper, dedicated >> development structure which is aligned to and substructred into >> independent development units and a way of deployment. >> >> As a developer, you will clone the base fgfs SC repository and you will >> clone the FGDATA repository. Then, depending on your field of interest >> you will clone the aircrafts, airports etc. you are planning to work on. >> >> You can do so with the git submodule, which will integrate the specific >> aircraft/airport/etc repository into the existing FGDATA repository, >> while keeping the commits separate. >> >> For deployment, you either manually or programatically git-submodule all >> data required for shipping into a branch for deployment. This includes, >> for instance, the KSFO tile and the c172p. It's apparent that one, among >> many advantages of that approach is, that the confusing redundancy >> between the "default KSFO" and the "scenery KSFO", as it currently >> exists, will go. >> >> While the planes are the primary concern of the splitting and will bring >> a relief of a tremendous 4.5 Gigabytes to every user of FGDATA and >> rectify a lot of redundancies and confusion, other things might also be >> considered, say, ./Traffic (just a lucky guess). >> >> Practically everything which is orthogonal to the core and without which >> FG (assuming a plane and a tile) can properly run, should migrate. >> > I think this is an offer we can't refuse. I think these proposals are as > good as any, and are in line with what Tim Moore was doing. Perhaps we > should go for a phased approach. In the fist phase, we could split out the > aircraft, then further restructuring could form subsequent phases. > > Cedric might like to start work on his script as soon as possible. > > Vivian
Yup ! > > ------------------------------------------------------------------------------ > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > http://p.sf.net/sfu/rim-devcon-copy2 > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
