Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after
Jari Häkkinen wrote: I support the split if only for the reason that aircraft maintainers will get commit rights to their private spheres in fg-land (if I understand things properly). With the previous monolithic fgdata only a selected group of people had commit privileges. Maybe now, that 'fgdata' is open again, one of the admins should simply add Jari to the list of data maintainers ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after
On Thu, 20 Oct 2011, Martin Spott wrote: Jari Häkkinen wrote: I support the split if only for the reason that aircraft maintainers will get commit rights to their private spheres in fg-land (if I understand things properly). With the previous monolithic fgdata only a selected group of people had commit privileges. Maybe now, that 'fgdata' is open again, one of the admins should simply add Jari to the list of data maintainers ;-) Still, that is a point in favour of having aircraft in separate repositories. Already with our selected group there as been some scary git moments, e.g. at one point a commit adding a new aircraft was undone in a tangled mess of merges and remerges by other committers - but I do sincerely hope that was only possible due to Tim having forgot to forbid non-fastforward updates on fgdata at that point (which was the case IIRC). An other thing: we know a 4GB repository works well on at least some platforms (e.g. I have had no problems) but what size is too large? 8GB? 16GB? Nevermind, keeping everything in one repository we are likely to hit that size sooner than if we scale in the number of repositories instead. The latter carries its own problems as has been mentioned, however. Amazingly, having both the new (experimental) and old fgdata master branches in my git repository the size has not increased much: anders@sleipner:~/FlightGear/fgdata$ du -sk .git 4022072 .git The level of compression achieved by git is impressive, but no doubt helped by the identical deltas on the respective branches. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ http://gitorious.org/anders-hangar-- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after
I am happy to accept the privileges when/if I begin an aircraft project. I even have plans for that but then again those plans are already 2 years old with no progress :) No, currently I am happy with trying to convince the dev team to accept my small and sporadic contributions. And with git, I keep the changes that didn't make it into the official repository in my local repo. Cheers, Jari On 2011-10-20 10.07, Martin Spott wrote: Jari Häkkinen wrote: I support the split if only for the reason that aircraft maintainers will get commit rights to their private spheres in fg-land (if I understand things properly). With the previous monolithic fgdata only a selected group of people had commit privileges. Maybe now, that 'fgdata' is open again, one of the admins should simply add Jari to the list of data maintainers ;-) Cheers, Martin. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On Tue, Oct 18, 2011 at 04:21:47PM -0600, dave perry wrote: On 10/18/2011 10:24 AM, Cedric Sodhi wrote: - Development - All aircraft related development shall henceforth be performed on repositories which are maintained by the respective authors. It is planned that most of the repositories on https://gitorious.org/flightgear-aircraft will be dissolved over time and be taken over by the respective authors. I don't understand the above (up to - Development -). Questions: 1. Are you saying that aircraft developers cannot leave their aircraft in https://gitorious.org/flightgear-aircraft indefinitely? So do we need to set up our own git repository for each ac we maintain? This raises the knowledge/experience bar required for aircraft developers/maintainers. As it turns out, the majority of those currently involved in the discussion on this mailing list (see the thread which Thorsten started on AC repositories) seem not to agree with that, although it is indeed the suggestion which I made. Instead, Thorsten et al welcome you to use the infrastructure of the official aircraft repository https://gitorious.org/flightgear-aircraft to officially publish your planes as part of the Flightgear project. 2. Assuming the answers are no, yes, to #1, will all these repositories be centrally located so one can track new or modified ac of interest? If you do not wish to publish your planes under the conditions outlined above, for instance because you don't want to use Gitorious or because your plane is not GPL, then, so Thorsten, you will not be entitled to be listed and tracked centrally (I personally don't agree with that). -- regards, ManDay -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On 18 Oct 2011, at 23:21, dave perry wrote: 2. Assuming the answers are no, yes, to #1, will all these repositories be centrally located so one can track new or modified ac of interest? 3. Is there any interest in creating repositories by ac class/type? e.g. historical, military-fighter, military-transport, civilian-light-ac, airliners, etc. Jus tot keep repeating (forever, until I have time to write the code) - don't confuse development and deployment here. The package system I'm working on includes the notion of aircraft catalogs (each an XML feed), listing aircraft. It's up to the catalog maintainer which aircraft he adds to it (or authors he allows to add to the catalog), and it's up to the end-users which catalog(s) they subscribe too. I'm also trying to force some metadata as part of this, about era / type / usage, so someone could create a '1950s Military' catalog, or alternatively use a 'all-aircraft' catalog, and then do a filter by era / class / license / rating / something else. James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On 10/19/2011 10:36 AM, James Turner wrote: On 18 Oct 2011, at 23:21, dave perry wrote: 2. Assuming the answers are no, yes, to #1, will all these repositories be centrally located so one can track new or modified ac of interest? 3. Is there any interest in creating repositories by ac class/type? e.g. historical, military-fighter, military-transport, civilian-light-ac, airliners, etc. Jus tot keep repeating (forever, until I have time to write the code) - don't confuse development and deployment here. The package system I'm working on includes the notion of aircraft catalogs (each an XML feed), listing aircraft. It's up to the catalog maintainer which aircraft he adds to it (or authors he allows to add to the catalog), and it's up to the end-users which catalog(s) they subscribe too. I'm also trying to force some metadata as part of this, about era / type / usage, so someone could create a '1950s Military' catalog, or alternatively use a 'all-aircraft' catalog, and then do a filter by era / class / license / rating / something else. Hi, Is there any written spec on this system? I got frustrated when looking for a specific aircraft in fgrun :) and so I suggested something similar several days ago on IRC, but it got confused with a/c rating. If I understand you correctly, submit a/c to a catalogue would mean that the information would not be kept in the a/c data - which has its pros and cons. I rather think that the metadata should be in the a/c itself. Maybe some combination would be the best of all worlds? I think that each a/c should define: - type (SR-71B, MiG-15bis) - manufacturer / constructor (e.g. for Soviet planes) - (Grumman, Mikoyan) - nicknames and codenames (Delfin / Maya, Avenger) - year of first flight or production or some such - country of origin - role (fighter, airliner) - tags (jet, blimp, ..., movable wings, ..., WW2, ) - a bit fuzzy Also the liveries/camouflages themselves could/should define - country - civil or military - force / company - years from-to The advantage of user supplied info is that it's independent of a/c author and can be possibly more up to date, or specify categories not considered by the author - like a List of aircraft flying in the Redflag exercise. Otoh metadata specified directly by author within a/c data will be probably more accurate and authoritative, usable by offline tools like fgrun and less prone to a sudden disappearance. Any thoughts? Edheldil -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On 19 Oct 2011, at 10:15, Edheldil wrote: Is there any written spec on this system? I got frustrated when looking for a specific aircraft in fgrun :) and so I suggested something similar several days ago on IRC, but it got confused with a/c rating. If I understand you correctly, submit a/c to a catalogue would mean that the information would not be kept in the a/c data - which has its pros and cons. I rather think that the metadata should be in the a/c itself. Maybe some combination would be the best of all worlds? http://wiki.flightgear.org/Aircraft_deployment One thing has changed since I wrote that - I'm probably going to put the metadata in a *separate* file from the -set.xml (but still part of the aircraft zip / distribution) because it means the system can handle 'non-aircraft' packages (eg, shared Instruments) that lack a set file, and it also simplifies handling multiple aircraft variants (set files) in one package. For encoding the metadata, I'm assuming an open-ended scheme, using properties, but with a standard ontology defined on the Wiki. I don't really what the ontology is, but obviously it will include era (1930s, 1950s), type (fixed-wing, glider, heavy), role (general aviation, commercial, bomber, fighter, etc), and so on. It could an arbitrary number of rating systems too, eg: metadata era1950/era typefixed-wing-jet/type rolecommerical/role statusbeta/alpha/production/status licenseGPL/freeware/CC-SA-nonsense/license ratings johns-points-system5/johns-points-system bobs-points-system56/bobs-points-system ... and so on /ratings /metadata Again, I'm not worry about the onotology until I have enough code written that it matters, which will be a few months time, probably. James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On 19 October 2011 19:29, Cedric Sodhi man...@gmx.net wrote: https://gitorious.org/flightgear-aircraft Last night, the discussion came up where the above page is slow to load, in part it's due to 1.2MB of HTML code, plus the CSS, plus the any images in use. Not very browser friendly. I hacked together a php script that will parse a locally stored version of the above page and display urls to the individual aircaft projects. On irc, Zorg, Gijs and perhaps a few others in the #flightgear channel had a poke it and gave it a nod. Tonight I have improved it, and it now validates as XHTML 1.0 Strict. I guess, what essential information do we require from the above Gitorious resource page. I can add parsing of the each aircraft's RSS/atom feed, but will need to work on caching first. Currently I have been periodically fetching the above page and saving it as a static resource that is then referred to as requested. It should help those that are on slower connection or pay a high data rate for traffic. (Or those who are pressed for time. :-) ) The url is http://fgfs.dyndns.info/aircraft.php I haven't linked it from the front page ofhttp://fgfs.dyndns.info as yet. Regards George to officially publish your planes as part of the Flightgear project. 2. Assuming the answers are no, yes, to #1, will all these repositories be centrally located so one can track new or modified ac of interest? If you do not wish to publish your planes under the conditions outlined above, for instance because you don't want to use Gitorious or because your plane is not GPL, then, so Thorsten, you will not be entitled to be listed and tracked centrally (I personally don't agree with that). -- regards, ManDay -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
Question on the new repository layout: I would like to pull every aircraft from https://gitorious.org/flightgear-aircraft/ Is there a way to do this in a single command or do I have to manually identify each aircraft in the repository and manually clone it here? If someone adds a new aircraft to this repository, will it get automatically fetched on my next git pull or do I have to manually check for new aircraft and manually pull them each individually? Thanks, Curt. On Wed, Oct 19, 2011 at 8:59 AM, George Patterson wrote: On 19 October 2011 19:29, Cedric Sodhi man...@gmx.net wrote: https://gitorious.org/flightgear-aircraft Last night, the discussion came up where the above page is slow to load, in part it's due to 1.2MB of HTML code, plus the CSS, plus the any images in use. Not very browser friendly. I hacked together a php script that will parse a locally stored version of the above page and display urls to the individual aircaft projects. On irc, Zorg, Gijs and perhaps a few others in the #flightgear channel had a poke it and gave it a nod. Tonight I have improved it, and it now validates as XHTML 1.0 Strict. I guess, what essential information do we require from the above Gitorious resource page. I can add parsing of the each aircraft's RSS/atom feed, but will need to work on caching first. Currently I have been periodically fetching the above page and saving it as a static resource that is then referred to as requested. It should help those that are on slower connection or pay a high data rate for traffic. (Or those who are pressed for time. :-) ) The url is http://fgfs.dyndns.info/aircraft.php I haven't linked it from the front page ofhttp://fgfs.dyndns.info as yet. Regards George to officially publish your planes as part of the Flightgear project. 2. Assuming the answers are no, yes, to #1, will all these repositories be centrally located so one can track new or modified ac of interest? If you do not wish to publish your planes under the conditions outlined above, for instance because you don't want to use Gitorious or because your plane is not GPL, then, so Thorsten, you will not be entitled to be listed and tracked centrally (I personally don't agree with that). -- regards, ManDay -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
Not automatically, as far as I know, but it should be relatively simple to script this. the main issue is how to script something that will work across platforms. I can do this in less than 20 lines of python, but of course not everyone has python installed on his windows machine Ciao, Alessandro From: curtol...@gmail.com Date: Wed, 19 Oct 2011 10:03:25 -0500 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split Question on the new repository layout: I would like to pull every aircraft from https://gitorious.org/flightgear-aircraft/ Is there a way to do this in a single command or do I have to manually identify each aircraft in the repository and manually clone it here? If someone adds a new aircraft to this repository, will it get automatically fetched on my next git pull or do I have to manually check for new aircraft and manually pull them each individually? Thanks, Curt. On Wed, Oct 19, 2011 at 8:59 AM, George Patterson wrote: On 19 October 2011 19:29, Cedric Sodhi man...@gmx.net wrote: https://gitorious.org/flightgear-aircraft Last night, the discussion came up where the above page is slow to load, in part it's due to 1.2MB of HTML code, plus the CSS, plus the any images in use. Not very browser friendly. I hacked together a php script that will parse a locally stored version of the above page and display urls to the individual aircaft projects. On irc, Zorg, Gijs and perhaps a few others in the #flightgear channel had a poke it and gave it a nod. Tonight I have improved it, and it now validates as XHTML 1.0 Strict. I guess, what essential information do we require from the above Gitorious resource page. I can add parsing of the each aircraft's RSS/atom feed, but will need to work on caching first. Currently I have been periodically fetching the above page and saving it as a static resource that is then referred to as requested. It should help those that are on slower connection or pay a high data rate for traffic. (Or those who are pressed for time. :-) ) The url is http://fgfs.dyndns.info/aircraft.php I haven't linked it from the front page ofhttp://fgfs.dyndns.info as yet. Regards George to officially publish your planes as part of the Flightgear project. 2. Assuming the answers are no, yes, to #1, will all these repositories be centrally located so one can track new or modified ac of interest? If you do not wish to publish your planes under the conditions outlined above, for instance because you don't want to use Gitorious or because your plane is not GPL, then, so Thorsten, you will not be entitled to be listed and tracked centrally (I personally don't agree with that). -- regards, ManDay -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson:http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On Wed, Oct 19, 2011 at 10:14 AM, TDO_Brandano - tdo_brand...@hotmail.comwrote: Not automatically, as far as I know, but it should be relatively simple to script this. the main issue is how to script something that will work across platforms. I can do this in less than 20 lines of python, but of course not everyone has python installed on his windows machine We (someone?) definitely needs to do something here. I'm sitting here now having cloned the fgdata-new repository with zero aircraft and zero instructions for fetching them. I know enough git and I know the root path, so I could go do this -- but for 350 aircraft, this would be weeks of manual work interleaved with lots of waiting to get all of them and then a major pain to update them all in the future or notice and fetch new aircraft. Sure we can script it out, but do I have 2-3 days right now to fiddle with a script? Not this week myself. What about new users coming to the project? We need to have some instructions and a reasonable mechanism that works for everyone. Right now we've replaced a one-line command with several weeks of manual work. (Or so it appears.) I understand the reasons, and we need to move forward, but I think this is a logic gap here -- an unforeseen side effect, and a problem we (someone) needs to scramble on to address. Anyone have any good ideas? Can anyone knock something out quickly? With svn you can just checkout the top level, or checkout any subtree underneath that individually. Is there any similar concept with git? Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On Wed, 19 Oct 2011, Curtis Olson wrote: Sure we can script it out, but do I have 2-3 days right now to fiddle with a script? Not this week myself. Updating aircraft repositories you have cloned should be easy enough, a quick and dirty bash hack: for d in my-aircraft-dir/*; do (cd $d; git pull --rebase); done (Testing that $d is indeed a directory might be good, though.) Initial cloning is slightly worse since you'd need to get the URLs (or the changing part of it) from somewhere (like the php script mentioned above?). Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On 19 Oct 2011, at 16:27, Curtis Olson wrote: Right now we've replaced a one-line command with several weeks of manual work. (Or so it appears.) I understand the reasons, and we need to move forward, but I think this is a logic gap here -- an unforeseen side effect, and a problem we (someone) needs to scramble on to address. The intention is create a super-module which has each aircraft as a submodule. Eg an 'all-aircraft' repository, for people who want this. Ideally someone with some scripting skills would automate creating that repository, and then we're back to a few steps: clone init submodules pull (which will recursively pull, and take ... some time) James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
The greatest problem i can see is that there's no wget equivalent for Windows, or tools to parse strings from a file, inbuilt in the shell. That's why I was mentioning python: it's easier to get working on Windows and these tools are part of the standard library. On linux, of course, you can get all the data with a savvy combination of wget, grep and sed. Ciao, Alessandro Date: Wed, 19 Oct 2011 17:42:49 +0200 From: anders-...@gidenstam.org To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split On Wed, 19 Oct 2011, Curtis Olson wrote: Sure we can script it out, but do I have 2-3 days right now to fiddle with a script? Not this week myself. Updating aircraft repositories you have cloned should be easy enough, a quick and dirty bash hack: for d in my-aircraft-dir/*; do (cd $d; git pull --rebase); done (Testing that $d is indeed a directory might be good, though.) Initial cloning is slightly worse since you'd need to get the URLs (or the changing part of it) from somewhere (like the php script mentioned above?). Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after
Curtis Olson wrote: Anyone have any good ideas? Yes, revert the dissection of 'fgdata' until a practical solution is in place which doesn't require lots of people to waste extra time just to achieve the previous state which simply works for them. Spending some thoughts on how to compensate the drawbacks of a split repository wouldn't be bad either. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On Wed, Oct 19, 2011 at 10:48 AM, James Turner wrote: The intention is create a super-module which has each aircraft as a submodule. Eg an 'all-aircraft' repository, for people who want this. Ideally someone with some scripting skills would automate creating that repository, and then we're back to a few steps: clone init submodules pull (which will recursively pull, and take ... some time) Hi James, A super module sounds ideal if that's doable in git. Looking forward to it! For now, maybe I have to sluff along with the aircraft from the old fgdata repository. Thanks! Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On Wed, Oct 19, 2011 at 11:03 AM, Curtis Olson wrote: Hi James, A super module sounds ideal if that's doable in git. Looking forward to it! For now, maybe I have to sluff along with the aircraft from the old fgdata repository. Replying to myself: Once we have a super-module for all the GPL aircraft in our central repository, it would be interetesting to begin work on a 2nd super-module for all the available externally maintained aircraft repositories we can find. Thanks once again, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
Normally windows users want everything in a 1 click download like precompiled packages. Maybe we can do this serverside, let them check a box for each aircraft or select all and simply give them a link? Jorg 2011/10/19 TDO_Brandano - tdo_brand...@hotmail.com The greatest problem i can see is that there's no wget equivalent for Windows, or tools to parse strings from a file, inbuilt in the shell. That's why I was mentioning python: it's easier to get working on Windows and these tools are part of the standard library. On linux, of course, you can get all the data with a savvy combination of wget, grep and sed. Ciao, Alessandro Date: Wed, 19 Oct 2011 17:42:49 +0200 From: anders-...@gidenstam.org To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split On Wed, 19 Oct 2011, Curtis Olson wrote: Sure we can script it out, but do I have 2-3 days right now to fiddle with a script? Not this week myself. Updating aircraft repositories you have cloned should be easy enough, a quick and dirty bash hack: for d in my-aircraft-dir/*; do (cd $d; git pull --rebase); done (Testing that $d is indeed a directory might be good, though.) Initial cloning is slightly worse since you'd need to get the URLs (or the changing part of it) from somewhere (like the php script mentioned above?). Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after
On Wed, Oct 19, 2011 at 11:03 AM, Martin Spott wrote: Curtis Olson wrote: Anyone have any good ideas? Yes, revert the dissection of 'fgdata' until a practical solution is in place which doesn't require lots of people to waste extra time just to achieve the previous state which simply works for them. Spending some thoughts on how to compensate the drawbacks of a split repository wouldn't be bad either. We certainly are discovering that git is not the perfectly elegant solution for every situation. Splitting the repository certainly has it's own set of issues and challenges and in the end do we still end up with the exact same challenges as when we started along with some new ones we add? I'm willing to be frustrated in the short term and run with the decisions of some of our trusted developers, but I sure hope we have at least a few people who are willing to scramble here right now and help us work through these issues and also help document the new process for new people just arriving. We can't depend on (or force) everyone to get a phd in git to participate in the project and forcing people to run scripts or install a scripting language is also a huge addition of complexity to our once relatively simple system. I'm not looking forward to downloading another 8Gb of aircraft repositories spread across 350 clones, but I'll do it since that's the direction we are going, but will a super module buy us much over the situation we just came from? Will we still have one huge download? Now we have an 8Gb download instead of a 9Gb download? Or we have to manually do all the individual aircraft, or we require everyone install python and learn how to launch scripts (and edit paths, etc.) Are we advancing the ball here? And if we are, let's make sure we don't drop the ball or cough it up with a bad pass (depending on what sports analogy you prefer.) Trying to be patient!!! I know this stuff takes time. It helps to be patient if I know someone is addressing these concerns and we'll have a reasonable solution in a timely manner. It just stresses me out to get caught in limbo. I am not a git-guru, and I can script, but I don't have time right now to spend 3 days on what used to be a single command I could copy/paste into my terminal. Thanks! Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
We have to make a small distinction here. Are we talking about users or developers? As it was pointed out earlier, GIT should not be seen as a distribution mechanism, this is a task best left elsewhere, and possibly managed by the frontend. It should not be difficult to just archive all the planes for download in a single install package. If you want to use the unstable, unreliable planes from git, then you should put up with the idea that it might require a little more than a single click for you. That said, it is perfectly possible to make a tool that will do this for you automatically. Ciao, Alessandro Date: Wed, 19 Oct 2011 18:06:24 +0200 From: jorgvanderve...@googlemail.com To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split Normally windows users want everything in a 1 click download like precompiled packages. Maybe we can do this serverside, let them check a box for each aircraft or select all and simply give them a link? Jorg 2011/10/19 TDO_Brandano - tdo_brand...@hotmail.com The greatest problem i can see is that there's no wget equivalent for Windows, or tools to parse strings from a file, inbuilt in the shell. That's why I was mentioning python: it's easier to get working on Windows and these tools are part of the standard library. On linux, of course, you can get all the data with a savvy combination of wget, grep and sed. Ciao, Alessandro Date: Wed, 19 Oct 2011 17:42:49 +0200 From: anders-...@gidenstam.org To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split On Wed, 19 Oct 2011, Curtis Olson wrote: Sure we can script it out, but do I have 2-3 days right now to fiddle with a script? Not this week myself. Updating aircraft repositories you have cloned should be easy enough, a quick and dirty bash hack: for d in my-aircraft-dir/*; do (cd $d; git pull --rebase); done (Testing that $d is indeed a directory might be good, though.) Initial cloning is slightly worse since you'd need to get the URLs (or the changing part of it) from somewhere (like the php script mentioned above?). Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On Wed, Oct 19, 2011 at 11:03 AM, Curtis Olson wrote: A super module sounds ideal if that's doable in git. Looking forward to it! For now, maybe I have to sluff along with the aircraft from the old fgdata repository. Hi James, One more super module question: if I start plowing through 350 aircraft by hand, and then next week you come out with a super module, will that require me to redownload everything, or can that be retrofitted on top of the modules I've already fetched? Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On 19 Oct 2011, at 17:47, Curtis Olson wrote: One more super module question: if I start plowing through 350 aircraft by hand, and then next week you come out with a super module, will that require me to redownload everything, or can that be retrofitted on top of the modules I've already fetched? I think you need to re-download everything, I'm afraid. But maybe a Git expert can correct me. James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after
Curtis Olson wrote: A super module sounds ideal if that's doable in git. Looking forward to it! Gitorious will be pleased if everybody starts pulling everything from scratch - and developers will be pleased by Gitorious' performance when everybody starts pulling everything from scratch. Previously there was a packaged bare repository for download via HTTP to start from in order to save Gitorious from the load and to save the developer from waiting hours until the fetch was complete Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after
On Wed, Oct 19, 2011 at 11:55 AM, Martin Spott wrote: A super module sounds ideal if that's doable in git. Looking forward to it! Gitorious will be pleased if everybody starts pulling everything from scratch - and developers will be pleased by Gitorious' performance when everybody starts pulling everything from scratch. Previously there was a packaged bare repository for download via HTTP to start from in order to save Gitorious from the load and to save the developer from waiting hours until the fetch was complete And I presume that this package has been made invalid since it points to the old fgdata repository, and it will be substantial work to bring it up to match the new fgdata + all the aircraft? So I'm still sitting here with zero aircraft, and not being sure I want to start down the path of a lengthy manual process that will need to be redone anyway, or a lengthy scripting session (that might have to be run many times before it's completely debugged.) Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after
I actually lost track of who is doing what in the splitting of fgdata but there is a tremendous response pointing out issues related to the split. I want to express support for the splitting team. I support the split if only for the reason that aircraft maintainers will get commit rights to their private spheres in fg-land (if I understand things properly). With the previous monolithic fgdata only a selected group of people had commit privileges. Once the dust settles I think we will see the benefits of giving aircraft developers direct access to their repos. At least the need for setting up other repos will decrease (assuming that not all aircraft developers are anti-GPL) because I think one major reason for setting up external repos are (lack of) commit privileges in fgdata. For those of you who are impatient with the progress, is the now frozen fgdata unusable? Why not stay with it until the new fgdata is to your liking? I haven't pulled the latest fg-state lately so I don't know if this is possible to stay old-school? Cheers, Jari -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
Seems like most people are just banging their heads against the wall trying to make a new system the same as the old, which is counter productive and unfortunate. It is highly unlikely ANYONE needs every single aircraft from git that they were previously forced to take, which is the whole point of the change. If people are honest with themselves I think they would realize they only need such aircraft that they plan to use or do development on. Personally I am extremely happy that I will no longer need to pull down hundreds of aircraft I have no intention of ever touching just so I can work on and test development new development in flightgear. In the end this will make it much, much easier for new developers and testers to get up and running and get to work. cheers --Jacob -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after
My main point (or thought) is just that if we are going to push forward with this split, then we need to go the whole way and make it work reasonably for everyone. The people pushing this and doing the initial work, can't just take it half way and then leave it because their personal concerns are dealt with. They need to consider the broader user and developer base and make sure our new approach and structure isn't a significant regression or inconvenience for people. It's one thing when you are in your own sand box, but this is the whole playground we are redoing, so their is a much more significant responsibility for making this work really well for everyone. I was reacting to the series of emails that indicated the split was done, everything is finished, nothing more to see here, every one move along -- but I'm sitting here with zero aircraft and a major hassle to get them all back and keep them updated. Gijs has indicated that we are going to have a do-over which is fine -- I've done enough sys admin stuff to know that it usually takes a couple tries to catch all the lose ends. When I install a new OS on a PC, I'm usually in it for 6-12 attempts before I get all the partitioning and configuration options just the way I want without messing something up critically in the process. ;-) I just want to make sure that we are considering the different issues and concerns; that the process and end results are being thought through carefully; and that those doing the leg work on this (and pushing the change strongly) don't leave it half baked because we ran into a problem that no one considered and no one knows what to do about it, and the original people are happy enough with only a 1/2 dozen aircraft to play with. Thanks! Curt. On Wed, Oct 19, 2011 at 12:41 PM, Jari Häkkinen wrote: I actually lost track of who is doing what in the splitting of fgdata but there is a tremendous response pointing out issues related to the split. I want to express support for the splitting team. I support the split if only for the reason that aircraft maintainers will get commit rights to their private spheres in fg-land (if I understand things properly). With the previous monolithic fgdata only a selected group of people had commit privileges. Once the dust settles I think we will see the benefits of giving aircraft developers direct access to their repos. At least the need for setting up other repos will decrease (assuming that not all aircraft developers are anti-GPL) because I think one major reason for setting up external repos are (lack of) commit privileges in fgdata. For those of you who are impatient with the progress, is the now frozen fgdata unusable? Why not stay with it until the new fgdata is to your liking? I haven't pulled the latest fg-state lately so I don't know if this is possible to stay old-school? Cheers, Jari -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On Wed, Oct 19, 2011 at 1:45 PM, Jacob Burbach jmburb...@gmail.com wrote: Seems like most people are just banging their heads against the wall trying to make a new system the same as the old, which is counter productive and unfortunate. It is highly unlikely ANYONE needs every single aircraft from git that they were previously forced to take, which is the whole point of the change. If people are honest with themselves I think they would realize they only need such aircraft that they plan to use or do development on. Personally I am extremely happy that I will no longer need to pull down hundreds of aircraft I have no intention of ever touching just so I can work on and test development new development in flightgear. In the end this will make it much, much easier for new developers and testers to get up and running and get to work. A developer that needs to make download packages for every available aircraft? A developer that wants to check if a source code change will impact the available aircraft (or gauge what the level of impact would be if they made a particular change.) A developer that needs to update code, and also fix all the associated aircraft to track a code change. A user who likes to be a collector and have everything available to browse through whether they plan to use a particular aircraft today or not. I could probably think of many more if I thought for a while longer. We can't be short sighted here and do a major regression that causes problems for a lot of people, just because there are some vocal people who don't have a personal need for every usage case. I know we all worship at the alter of git, but isn't the main problem here is that we are forcing everyone to download the complete binary history of everything in the data package, and this is not scaling well for us? If we put it to a vote, I wonder how our general user population would respond to: Do you want (a) the entire binary history of everything (b) the entire set of aircraft. We are committed to git, I'm not suggesting otherwise, but the entire binary history of the data tree is pushing 10Gb. My understanding is that splitting off the aircraft wouldn't reduce the total size, but would allow us to deal with smaller chunks and optionally cherry pick just the parts we want. But if the result is that it is an immense effort or very difficult to get all the data and all the aircraft for people that want it (for any reason) then we have a problem. Telling them they don't need it and shouldn't download it is not really a good answer. Here's another way to look at it. We need to keep policy and capability as separate as possible. If we end up with significantly reduced capability, just redefining our policy is going to make a lot of people unhappy. Ideally we should find a solution that offers the required capabilities to support different policies. People that just want a few aircraft can establish that policy for themselves, people that want all the aircraft can establish that policy for themselves. We can't go around telling people what they should want or what they should do in response to taking something away from them and implying there's something wrong with them if they think otherwise. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
Am 19.10.2011 20:45, schrieb Jacob Burbach: Seems like most people are just banging their heads against the wall trying to make a new system the same as the old, which is counter productive and unfortunate. It is highly unlikely ANYONE needs every single aircraft from git that they were previously forced to take, which is the whole point of the change. If people are honest with themselves I think they would realize they only need such aircraft that they plan to use or do development on. Personally I am extremely happy that I will no longer need to pull down hundreds of aircraft I have no intention of ever touching just so I can work on and test development new development in flightgear. Fair point. But some of use might need to walk through all aircraft from time to time. One example: I'm working on a new implementation of the navradio code (the code that does the VOR/LOC/GS computation). I'd prefer to guarantee some degree of backward compatibility with existing aircraft. Which ones should I choose? Another example: For the last release, we branched and tagged the repositories and well defined states. This was OK for three repositories (fg+sg+fgdata). Doing this manually for 300+ repos is a no and doing this scripted calls for trouble. I'm not saying that the old situation (one single repo) is heaven on earth. But for me as a developer, it has more advantages than disadvantages. I have no issues with the size, I branch, merge, pull and push in seconds. Only, git gc --aggressive takes some time. In the end this will make it much, much easier for new developers and testers to get up and running and get to work. I'm not convinced that this is true. Torsten -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after
Jacob Burbach wrote: Seems like most people are just banging their heads against the wall trying to make a new system the same as the old, which is counter productive and unfortunate. I wonder by which justification you pretend to speak for a group whose common understanding you never bothered to share !? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On 2011-10-19 21.12, Torsten Dreyer wrote: Another example: For the last release, we branched and tagged the repositories and well defined states. This was OK for three repositories (fg+sg+fgdata). Doing this manually for 300+ repos is a no and doing this scripted calls for trouble. But is there a need to tag all 300+? Only a handful aircraft are part of fg releases. I do understand that some/many have the need to download all aircraft, I will for sure do that. For me the download size is not the issue. I genuinely think that the split will benefit the project. Of course, if it alienates developers then the change may turn out to be a bad move. Why not wait and see how the new repository structure plays out? It is easy to revert if needed. What is the cost? A short delay in committed fgdata changes. Development doesn't have to stop since all of us have a clone of the old fgdata that can be used to keep track of our changes. Jari -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after
Curtis Olson wrote: We are committed to git, I'm not suggesting otherwise, but the entire binary history of the data tree is pushing 10Gb. I'm not sure if we're talking about the same item, but the bare repository of the entire 'fgdata' in its current state should be at approx. 4 GByte or even slightly less. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
I understand there are a some cases where one might need all aircraft to perform some specific task, and when I said unlikely ANYONE would I could have spoken better. However for the vast majority of developers, contributors, and testers, I have to believe it is completely unnecessary or desired to get everything. For those power developers that DO actually need everything, I also have to believe they are more than capable of figuring out how to import some repos, run a script, etc. It is not wise to continue to let fgdata repository just grow and grow without end, it cannot be sustained in that manner indefinitely. More aircraft are created all the time, it is not going to get smaller or easier for people to work with. How many people have we already alienated, who may have otherwise been able to contribute, simply because they do not have access to the bandwidth necessary to deal with fgdata at no fault of their own? cheers -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after
On Wed, Oct 19, 2011 at 3:49 PM, Martin Spott martin.sp...@mgras.net wrote: Jacob Burbach wrote: Seems like most people are just banging their heads against the wall trying to make a new system the same as the old, which is counter productive and unfortunate. I wonder by which justification you pretend to speak for a group whose common understanding you never bothered to share !? Martin. I speak for no person and no group, nor do I pretend to do so. I speak only about a general recurring theme in this discussion in which many seem to be struggling to find a simple, hands free way to get a monolithic fgdata back. Sure, some may have some use or actual need for it, but it really seems many are searching for a problem that doesn't really exist as such. cheers --Jacob -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after
On Wed, Oct 19, 2011 at 04:55:28PM -0400, Jacob Burbach wrote: On Wed, Oct 19, 2011 at 3:49 PM, Martin Spott martin.sp...@mgras.net wrote: Jacob Burbach wrote: Seems like most people are just banging their heads against the wall trying to make a new system the same as the old, which is counter productive and unfortunate. I wonder by which justification you pretend to speak for a group whose common understanding you never bothered to share !? Martin. I speak for no person and no group, nor do I pretend to do so. I speak only about a general recurring theme in this discussion in which many seem to be struggling to find a simple, hands free way to get a monolithic fgdata back. Sure, some may have some use or actual need for it, but it really seems many are searching for a problem that doesn't really exist as such. cheers --Jacob Dear Jacob, if you had followed the discussion a bit more attentively and in particular read my two emails, you would know that everything, apart from the tiny issue with the fgdata-core repository, which by now has been rectified, everything goes flawlessly (and according to the plan which has been made in advance, which you don't know about). I don't think anyone is really looking for a a way back, by now practically everyone has realized that the split was necessary. Yes, this was a change. And perhaps an at first confusing change for those not well aquainted with Git and the structure of fgdata, but even they will get used to it. If there are currently still problems with the change, they either result from the unknowingness of the respective people, which can easily be remedied, or bugs which has been revealed through the split (such as the use of wrong file-paths in some of the airplanes). regards, ManDay -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
= IMPORTANT NOTICE TO EVERYONE INVOLVED WITH THE DEVELOPMENT OF FGDATA OR AIRPLANES THEREIN = Thanks to the concentrated effort of all people involved, most notably Jorg - who I'd hereby like to thank on behalf of all of us, for spending three successive days and nights branching, cloning, filtering, splitting and verifying data - FGDATA has, by today, successfully been split into individual repositories, comprising the respective planes and FGDATA core data. Again: === !!! === From the present day on, the development version of FGDATA NO LONGER CONTAINS ANY AIRPLANES - You will have to clone a new FGDATA! === - Airplanes migrated - All airplanes, hitherto found in $FGDATA/Aircraft/, have been removed from that place in the development version of FGDATA and can presently be found in their individual repositories at the following URL https://gitorious.org/flightgear-aircraft (Disclaimer: HTML page is rather huge) Please contact either of the following administrators to be given priviledges on one of those repositories: https://gitorious.org/+flightgear-aircraft/memberships - New FGDATA Core - FGDATA is now without any aircraft. The only things which remain in FGDATA's Aircraft directory are general purpose data which are used by a bulk of different airplanes. The respective directories of these data are Generic Instruments Instruments-3d Despite its name, now a historical relict, NO AIRCRAFT SHALL EVER BE PUSHED TO $FGDATA/Aircraft. The new FGDATA can be found in the official repository at the following URL https://gitorious.org/fg/fgdata-new The repository is named fgdata-new for the time being and the old fgdata is kept arround, frozen, to have a fallback if anything should happen. Please contact either of the following administrators to be given priviledges on the new fgdata repository: https://gitorious.org/+flightgear-developers/memberships - Development - All aircraft related development shall henceforth be performed on repositories which are maintained by the respective authors. It is planned that most of the repositories on https://gitorious.org/flightgear-aircraft will be dissolved over time and be taken over by the respective authors. On a sidenote, some of those repositories are already superflous because development has long been moved somewhere else. These are the first repositories which will be decomissioned. Only repositories for which no author is found will remain stored centrally. Development on the rest of FGDATA will continue in the new FGDATA repository until further notice, possibly until more components are migrated, as it has been brought forward. https://gitorious.org/fg/fgdata-new - Usage - To keep up with the new structure, commit all your local changes on your old FGDATA and move its directory out of the way (for example by renaming it). $ cd fgdata $ git commit -a $ cd .. $ mv fgdata fgdata-OLD Next, clone the new repository of FGDATA $ git clone git://gitorious.org/fg/fgdata-new.git fgdata IF YOU HAD LOCAL CHANGES, you will need to reapply these changes. This could be a little adventurous, because these are actually two separate repositories and you can't just rebase. You'll have to prepare the patches and apply them over. If you need help with this, check on the official IRC channel at irc://irc.flightgear.org/flightgear for help. Now you have the new core FGDATA (possibly with your own changes, if you followed the hint above). In the coming days, we will provide you with scripts which conveniently fetch your personal selection of aircrafts; until then you will have to manually obtain them from the repositories. Here is how: DO NOT PUT THE AIRCRAFTS INTO THE NEW FGDATA! Instead, create a new directory somewhere completely different, say, /usr/local/flightgear/aircrafts and store the aircrafts in there (for example clone them from their repositories). If you specify that directory on the command line to Flightgear, it will find them, altough they are not in the FGDATA directory. E.g.: $ ./fgfs --fg-aircraft=/usr/local/flightgear/aircrafts NOTE: Some aircrafts explicitly require to be inside of FGDATA, because they are programmed to expect their own data files to be found in FGDATA. These airplanes will give you an error if you put them outside of FGDATA (as you must). In order to solve this, you can symbolically link them individually into FGDATA (Git is already told to ignore those links). $ ln -s /usr/local/flightgear/aircrafts/c172p /path/to/fgdata/Aircraft/ === If you are experiencing problems you can find people who can help you on IRC. regards, ManDay, on behalf of the Split-Team ^^ -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
Good work guys. Thanks. On Tue, Oct 18, 2011 at 5:24 PM, Cedric Sodhi wrote: NOTE: Some aircrafts explicitly require to be inside of FGDATA, because they are programmed to expect their own data files to be found in FGDATA. These airplanes will give you an error if you put them outside of FGDATA (as you must). In order to solve this, you can symbolically link them individually into FGDATA (Git is already told to ignore those links). $ ln -s /usr/local/flightgear/aircrafts/c172p /path/to/fgdata/Aircraft/ === Surely that would be a bug in the aircraft that should be fixed? Also, IIRC there are a number of aircraft that have dependencies on other aircraft. Presumably this would be a good opportunity to fix those as well? -Stuart -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On Tue, Oct 18, 2011 at 05:33:23PM +0100, Stuart Buchanan wrote: On Tue, Oct 18, 2011 at 5:24 PM, Cedric Sodhi wrote: NOTE: Some aircrafts explicitly require to be inside of FGDATA, because they are programmed to expect their own data files to be found in FGDATA. These airplanes will give you an error if you put them outside of FGDATA (as you must). In order to solve this, you can symbolically link them individually into FGDATA (Git is already told to ignore those links). $ ln -s /usr/local/flightgear/aircrafts/c172p /path/to/fgdata/Aircraft/ === Surely that would be a bug in the aircraft that should be fixed? Indeed. Also, IIRC there are a number of aircraft that have dependencies on other aircraft. Presumably this would be a good opportunity to fix those as well? Agreed. ManDay -Stuart -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the
The 'fgdata'-mirror at: http://mapserver.flightgear.org/git/gitweb.pl?p=fgdata which previously had been maintained for it's advantageous download performance is now frozen, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
Am 18.10.2011 18:24, schrieb Cedric Sodhi: Next, clone the new repository of FGDATA $ git clone git://gitorious.org/fg/fgdata-new.git fgdata For some reason, there seems to be no ssh url available for fgdata-new and the aircraft projects? Torsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
Torsten wrote: For some reason, there seems to be no ssh url available for fgdata-new and the aircraft projects? There is. g...@gitorious.org:fg/fgdata-new.git and for the aircraft it's like g...@gitorious.org:flightgear-aircraft/c172p.git (all aircraft repos simply match the respective aircraft's directory name). You mean you don't see it at Gitorious? Works fine here on IE9 and FF7... Cheers, Gijs -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
Am 18.10.2011 19:30, schrieb Gijs de Rooy: Torsten wrote: For some reason, there seems to be no ssh url available for fgdata-new and the aircraft projects? There is. g...@gitorious.org:fg/fgdata-new.git mailto:g...@gitorious.org:fg/fgdata-new.git and for the aircraft it's like g...@gitorious.org:flightgear-aircraft/c172p.git mailto:g...@gitorious.org:flightgear-aircraft/c172p.git (all aircraft repos simply match the respective aircraft's directory name). You mean you don't see it at Gitorious? Works fine here on IE9 and FF7... Sorry, I was referring to the clone/push url. Surely the gitorious web site works as expected. The ssh url is required (iirc) to access gitorious with the public key as a commiter. git clone g...@gitorious.org:fg/fgdata-new data fails with Cloning into data... == Gitorious: == Access denied or bad command fatal: The remote end hung up unexpectedly before I can enter my private key. Torsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
Torsten wrote: git clone g...@gitorious.org:fg/fgdata-new data Make sure you don't forget .git. Use this: git clone g...@gitorious.org:fg/fgdata-new.git data -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
Am 18.10.2011 19:45, schrieb Gijs de Rooy: Torsten wrote: git clone g...@gitorious.org:fg/fgdata-new data Make sure you don't forget .git. Use this: git clone g...@gitorious.org:fg/fgdata-new.git touche - I'm getting too old for this ;-) It works now, thanks! Torsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On Tue, Oct 18, 2011 at 5:33 PM, Stuart Buchanan wrote: On Tue, Oct 18, 2011 at 5:24 PM, Cedric Sodhi wrote: NOTE: Some aircrafts explicitly require to be inside of FGDATA, because they are programmed to expect their own data files to be found in FGDATA. These airplanes will give you an error if you put them outside of FGDATA (as you must). In order to solve this, you can symbolically link them individually into FGDATA (Git is already told to ignore those links). $ ln -s /usr/local/flightgear/aircrafts/c172p /path/to/fgdata/Aircraft/ === Surely that would be a bug in the aircraft that should be fixed? ... and it has now been. You should now be able to use the c172p outside of the fgdata/ directory. -Stuart -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On 10/18/2011 10:24 AM, Cedric Sodhi wrote: = IMPORTANT NOTICE TO EVERYONE INVOLVED WITH THE DEVELOPMENT OF FGDATA OR AIRPLANES THEREIN = Thanks to the concentrated effort of all people involved, most notably Jorg - who I'd hereby like to thank on behalf of all of us, for spending three successive days and nights branching, cloning, filtering, splitting and verifying data - FGDATA has, by today, successfully been split into individual repositories, comprising the respective planes and FGDATA core data. Again: === !!! === From the present day on, the development version of FGDATA NO LONGER CONTAINS ANY AIRPLANES - You will have to clone a new FGDATA! === - Airplanes migrated - All airplanes, hitherto found in $FGDATA/Aircraft/, have been removed from that place in the development version of FGDATA and can presently be found in their individual repositories at the following URL https://gitorious.org/flightgear-aircraft (Disclaimer: HTML page is rather huge) Please contact either of the following administrators to be given priviledges on one of those repositories: https://gitorious.org/+flightgear-aircraft/memberships - New FGDATA Core - FGDATA is now without any aircraft. The only things which remain in FGDATA's Aircraft directory are general purpose data which are used by a bulk of different airplanes. The respective directories of these data are Generic Instruments Instruments-3d Despite its name, now a historical relict, NO AIRCRAFT SHALL EVER BE PUSHED TO $FGDATA/Aircraft. The new FGDATA can be found in the official repository at the following URL https://gitorious.org/fg/fgdata-new The repository is named fgdata-new for the time being and the old fgdata is kept arround, frozen, to have a fallback if anything should happen. Please contact either of the following administrators to be given priviledges on the new fgdata repository: https://gitorious.org/+flightgear-developers/memberships - Development - All aircraft related development shall henceforth be performed on repositories which are maintained by the respective authors. It is planned that most of the repositories on https://gitorious.org/flightgear-aircraft will be dissolved over time and be taken over by the respective authors. I don't understand the above (up to - Development -). Questions: 1. Are you saying that aircraft developers cannot leave their aircraft in https://gitorious.org/flightgear-aircraft indefinitely? So do we need to set up our own git repository for each ac we maintain? This raises the knowledge/experience bar required for aircraft developers/maintainers. 2. Assuming the answers are no, yes, to #1, will all these repositories be centrally located so one can track new or modified ac of interest? 3. Is there any interest in creating repositories by ac class/type? e.g. historical, military-fighter, military-transport, civilian-light-ac, airliners, etc. By the way, thanks for all the work on this and also for this helpful note of documentation! On a sidenote, some of those repositories are already superflous because development has long been moved somewhere else. These are the first repositories which will be decomissioned. Only repositories for which no author is found will remain stored centrally. Development on the rest of FGDATA will continue in the new FGDATA repository until further notice, possibly until more components are migrated, as it has been brought forward. https://gitorious.org/fg/fgdata-new - Usage - To keep up with the new structure, commit all your local changes on your old FGDATA and move its directory out of the way (for example by renaming it). $ cd fgdata $ git commit -a $ cd .. $ mv fgdata fgdata-OLD Next, clone the new repository of FGDATA $ git clone git://gitorious.org/fg/fgdata-new.git fgdata IF YOU HAD LOCAL CHANGES, you will need to reapply these changes. This could be a little adventurous, because these are actually two separate repositories and you can't just rebase. You'll have to prepare the patches and apply them over. If you need help with this, check on the official IRC channel at irc://irc.flightgear.org/flightgear for help. Now you have the new core FGDATA (possibly with your own changes, if you followed the hint above). In the coming days, we will provide you with scripts which conveniently fetch your personal selection of aircrafts; until then you will have to manually obtain them from the repositories. Here is how: DO NOT PUT THE AIRCRAFTS INTO THE NEW FGDATA! Instead, create a new directory somewhere completely different, say, /usr/local/flightgear/aircrafts and store the aircrafts in there (for example clone them from their repositories). If you specify that directory on the command line to Flightgear, it will find them, altough they are not in the FGDATA directory. E.g.: $ ./fgfs
