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