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 ------------------------------------------------------------------------------ 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
