Re: [Flightgear-devel] Cmake (soon)
There is a fault somewhere in Flightgear/Simgear cmake which makes this happen from time to time. Here is a quick fix. Step 12a If you get the error Could NOT find SimGear (missing: SIMGEAR_VERSION_OK) (Required is at least version 2.5.0) Press Add Entry In the window that comes up set Name to SIMGEAR_VERSION_OK, Type to BOOL and tick the Value box. Press OK and continue. This bypasses the broken Simgear version check. Alan -Original Message- From: Rob Dosogne Sent: Tuesday, October 18, 2011 10:06 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Cmake (soon) Thanks for the instructions, Alan. I tried this twice from scratch—SimGear configures builds just fine, but CMake gets stuck trying to configure FlightGear. I set CMAKE_INSTALL_PREFIX as you said, and building INSTALL seems to have copied SimGear into that directory, but CMake can't find it; any ideas? Git revision is 3rdparty files located in C:/FlightGear apr-1-config not found, implement manual search for APR Could NOT find LIBSVN (missing: LIBSVN_LIBRARIES LIBSVN_INCLUDE_DIR) C:/FlightGear/3rdParty.x64/include adding runtime JS dependencies C:/FlightGear/install/include looking for version: 2.5.0 CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:91 (MESSAGE): Could NOT find SimGear (missing: SIMGEAR_VERSION_OK) (Required is at least version 2.5.0) Call Stack (most recent call first): C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:252 (_FPHSA_FAILURE_MESSAGE) CMakeModules/FindSimGear.cmake:217 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:179 (find_package) Configuring incomplete, errors occurred! cheers, Rob On Tue, Oct 18, 2011 at 09:41, Alan Teeder ajtee...@v-twin.org.uk wrote: It is about time that such a document was started, many thanks. However windows users will most likely use the CMake gui, which hides all that geeky command line stuff. For Cmake gui the following seems to work. 1. Set up a work directory as described in http://wiki.flightgear.org/index.php/Building_Flightgear_-_Windows. (NOTE: this is now out of date as the 3rdparty , zlib and OSG are all ready to use at ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/ ) 2. Open the Cmake gui 3. Set “Where is the source code” and “Where to build the binaries” to C:/Flightgear/simgear” (or wherever you have put simgear) 4. Press the “Configure” button. The first time that the project is generated, Cmake will bring up a window asking which compiler you wish to use. Normally just accept Cmakes suggestion, and press Finish. Cmake will now do a check on your system and will produce a preliminary build configuration.´ 5. Check for errors in the red window. Cmake should have found OSG, zlib and your 3rdparty directories. 6. Set CMAKE_INSTALL_PREFIX to C:/Flightgear/install. This is probably not necessary for Windows XP, but is required for Windows 7 as the default (C:\Program Files) is protected. 7. Press “Configure” once more. Errors should all have gone. 8. Press “Generate”. Cmake will now write a windows sln and project files in the simgear directory. 9. Open C:\Flightgear\simgear\simgear.sln. MSVC should come up. Select Release (or debug if you need it) build and then build-all. 10. Once simgear has built successfully (there will be some warnings), build the INSTALL project. This will copy the simgear libraries and include files to C:flightgear\install. 11. Now repeat the Cmake process for flightgear. The directories to choose are C:/Flightgear/flightgear. 12. It is important to chose the same CMAKE_INSTALL_PREFIX, otherwise the simgear libraries will not be found. 13. Open C:\Flightgear\flightgear\flightgear.sln. As with simgear, build all, and then build INSTALL. 14. Flightgear and other executables should be in C:\Flightgear\install\bin. No doubt I have left something out, but this does describe the basic process. Alan From: James Turner Sent: Tuesday, October 18, 2011 9:40 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Cmake (soon) _ On 17 Oct 2011, at 18:38, Curtis Olson wrote: Would it be possible to write a quick howto for doing some basic coding/developer things in cmake. Like: how to add a new source file to the project. Or how to add a new module/library to the project. Maybe a few quick summeries of how to install in a custom directory, how to build with custom compiler options, how to configure for debug vs. release build, or some the more subtle build options that invoke different levels of optimizations or warnings. I've written this up, at least a first attempt, will commit it later today, and people can review it for sanity / correctness / omissions :) Either that, or our cmake experts need to be willing and ready to respond to frustrated dumb questions in a
Re: [Flightgear-devel] FlightGear aircraft repository
As for the topic brought up here, I sense a bit of sentimentalism clouding the technical judgment of some. (...) In a positive creative development structure you leave the contributors their freedom. Contribute your planes! rather than Come to Gitorious, ask for our permission to get your repository, work under our supervision! Work, work, my busy bees, and make us planes for our big master-repository! Freedom naturally finds its limits where it impacts on the freedom of others - you seem to miss this point. You always have the choice to make your development available in whatever form and license you like. You can create your own hangar, present your work there, are free to use whatever license you like, are free to offer whatever level of user support you like, you can even sell your addons ... You can also offer your work as part of 'The Flightgear Project'. Once you decide to do so, it is no longer your freedom to do what you want with your work - it is under the control of 'The Flightgear Project', you may have to compromise, you can't choose your license, But you get something in return for giving up that freedom - you get to use the official Flightgear infrastructure (you aircraft will be for download on the official page, others test compatibility, other developers may take care of your work when you're not around, others will feel responsible to provide support if they can,...). You seem to entertain the idea of a free lunch - get the goodies which being part of the Flightgear project has to offer, but keeping the freedom to do what you want. That may be a positive creative development structure from your personal point of view, but certainly not for everyone else who is then supposed to provide infrastructure for you. This has nothing to do with what technical possibilities GIT offers, or what GIT is about - it's just common sense that there has to be a balance between give and take whenever people interact and work together. So, if you like your complete freedom, you can't be part of a collaborative project. It's as simple as that, being part of a bigger project always implies giving up that complete freedom. Cheers, * Thorsten (R) -- 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 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] FlightGear aircraft repository
On Wed, Oct 19, 2011 at 10:28:33AM +0300, thorsten.i.r...@jyu.fi wrote: As for the topic brought up here, I sense a bit of sentimentalism clouding the technical judgment of some. (...) In a positive creative development structure you leave the contributors their freedom. Contribute your planes! rather than Come to Gitorious, ask for our permission to get your repository, work under our supervision! Work, work, my busy bees, and make us planes for our big master-repository! You can also offer your work as part of 'The Flightgear Project'. Once you decide to do so, it is no longer your freedom to do what you want with your work - it is under the control of 'The Flightgear Project', you may have to compromise, you can't choose your license, But you get something in return for giving up that freedom - you get to use the official Flightgear infrastructure (you aircraft will be for download on the official page, others test compatibility, other developers may take care of your work when you're not around, others will feel responsible to provide support if they can,...). This is exactly the deal which I think you are rather hurting yourself with. I allege, that contributers of planes are not looking to make a deal with you, at least I would not. What you are offering them, is what *every* contributor should be entitled to in the first place. You only get to be on our download page if you surrender your autonomy to us? What are you trying to achieve? Do you really think anyone would readily change their mind to rather publish their plane as GPL, although they'd prefer not to, and give up their autonomy, although they'd prefer not to, to get a goodie from you? Again: What are you trying to achieve? Are you trying to promote GPL by sanctioning people for not using it? Or is it only about some personal pride thing, and you don't want to feel exploited by those, who contribute (that sounds ridicolous enough as it stands)? You seem to entertain the idea of a free lunch - get the goodies which being part of the Flightgear project has to offer, but keeping the freedom to do what you want. That may be a positive creative development structure from your personal point of view, but certainly not for everyone else who is then supposed to provide infrastructure for you. If you consider those, who contribute planes, looking for a free lunch, I seriously must wonder what kind of attitude you presume in an open source project. What is that lunch exactly? The fame, perhaps? And instead of considering listing even non-GPL planes on the main-page a good thing for Flightgear, you rather wish to deprive those who contributed them of their fame? it's just common sense that there has to be a balance between give and take whenever people interact and work together. Again, I can't help it but wonder what image you have in mind when you accuse those, who voluntarily make planes for Flightgear, of taking from you but not giving back. I can't even imagine what your opinion of people who only use Flightgear, and develop neither code nor planes for it, must be... And as for other developers may take care of your work when you're not around, others will feel responsible to provide support if they can,...). I think we have sufficiently seen how other people's work is taken care of after they leave. And how much it helps in this regard, that the planes are forced under the hood of GPL and subjected to your authority, your restrictions. I think old, abandoned planes will equally, if not more likely be willingly taken over by others, if they are not forced into a master-repo. This has nothing to do with what technical possibilities GIT offers, or what GIT is about Yes, it has everything to do with what Git(orious) is about. Because Gitorious demonstrates what a sustainable, distributed development structure works like, and your suggestion is nothing like that. You completely misregard fundamental properties of distributed development, such as cloning and branching. Your desire to patronize the other developers may be more fit for core and code development, but the development of planes differs substantially from that of the core: Planes are contributed modularily, have no strong interaction amonst eachother and can thus be contributed freely, as in the freedom to contribute or not. If you like to obtain authority over a plane, cloning it into your own repository will allow you to call it your own, while you can still savour the development the author makes. And if the author seems to abandon the plane or changes things of which you disapprove, branching will allow you to continue development as if it had always been your own. So, if you like your complete freedom, you can't be part of a collaborative project. It's as simple as that, being part of a bigger project always implies giving up that complete freedom. No one gives up any freedom here, since it's their free and voluntary
Re: [Flightgear-devel] FlightGear aircraft repository
Hello again, I would like to add that I agree, that making any implication about whether authors *should* migrate their planes to their own repos, was wrong. There is of course no reason to turn them away, if only, there is a reason to request them to be part of the central Gitorious-Account (as it is the subject of this thread). regards, ManDay On Wed, Oct 19, 2011 at 10:28:33AM +0300, thorsten.i.r...@jyu.fi wrote: -- 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] FlightGear aircraft repository
I'd loke to note that I listed pros and cons at the wiki. Some people contributed, some didn't. Rather than turning this into a me/we-vs-you/they fight I'd like to see that people sit down and add their thoughts (and facts) to the wiki. Makes it easier/healthier for all of us ;) http://wiki.flightgear.org/FlightGear_Git:_splitting_fgdata#Reasons_to_put_aircraft_under_a_single_project -- 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] FlightGear aircraft repository
This is exactly the deal which I think you are rather hurting yourself with. I allege, that contributers of planes are not looking to make a deal with you, at least I would not. First, you're talking to the wrong person. I'm not Thorsten B, I am Thorsten R, and I do not represent the core developers, nor do I have any sorts of commit rights, I just take some time to explain something to you which seems pretty obvious to me. Second, if you do not wish to make the deal, then don't. End of story. No need for your rants. There are excellent planes without GPL license around (the Tu-154b comes to mind), the development is well respected, I don't see the problem. Obviously people can and do contribute that way. What you are offering them, is what *every* contributor should be entitled to in the first place. *shrugs* I'm a contributor, I just contribute a different thing (weather) which isn't so easily separable from the core. So - I need to talk to people, work together with others, accomodate structure constraints all the time. I can't usually decide to structure things in a certain way - I propose changes, they get discussed, sometimes implemented, sometimes not. You feel you are entitled to more because you do other development? Apparently yes... You only get to be on our download page if you surrender your autonomy to us? Yes. Seems pretty obvious to me. I work at a university, so I get access to the university webpages. Someone else doesn't, so he doesn't get to be on the university page. If I misuse my access to university webpages, I see it revoked. Me being able to send emails from a university address gives me mroe credibility than a yahoo address - that's some bonus. Where precisely is the problem? You work for the Flightgear project, your work gets promoted by the Flightgear webpage. You work for Cedric Sodhi, your work gets promoted by Cedric Sodhi. What are you trying to achieve? Do you really think anyone would readily change their mind to rather publish their plane as GPL, although they'd prefer not to, and give up their autonomy, although they'd prefer not to, to get a goodie from you? Frankly, I don't particularly care about that aspect. People who want to publish with a different license can do so, see above, end of story. For me, fairness is an issue. If one single person on the official project page doesn't get to keep control of his work, then no one should. It's a decision the project has made a long time ago, I entered it knowing that this is how it works, it has worked well. Again, I can't help it but wonder what image you have in mind when you accuse those, who voluntarily make planes for Flightgear, of taking from you but not giving back. Oh, but you're not talking here about people who make planes 'for Flightgear'. For people who make planes 'for Flightgear' the implication is that the planes will be given out of their hands because Flightgear is GPL. You're talking here about people who make planes as addons which rely on Flightgear - a rather different beast. Please, let's be very clear about this. We may speculate why people choose not to publish under GPL. One reason might be that they can't because they have used material that isn't GPL compatible. Another may simply be ego, or fame as you put it. Either is fine with me, people can do that, but it's not 'part of Flightgear' or 'for Flightgear', because Flightgear is GPL. Taking your argument a bit further, you'd also include FlightProSim into the group working 'for Flightgear' because they do something relying on the Flightgear code? Or if not, just when is it 'for Flightgear' in your book? Your desire to patronize the other developers may be more fit for core and code development, but the development of planes differs substantially from that of the core: Planes are contributed modularily, have no strong interaction amonst eachother and can thus be contributed freely, as in the freedom to contribute or not. It's a bit tiresome to point out again that you have the complete freedom to do whatever you like with your plane, but that you don't have the freedom to use the Flightgear page for it. Basically, the reason an idea called 'equality'. It's been around since the French Revolution. Just because there's a technical infrastructure which would allow us to be unequal we don't have to be - it still remains ethically wrong. It'd be easy to ask people to pay 1000 $ before they can cast a vote. Election results would be very different then - but does that mean we should we do so? In essence you're saying that because it is technically possible for you to exercise more freedom rights than for me, you should have more rights. I think that's not a particularly ethically well-founded position. Or, to say it bluntly, it wouldn't appear fair. A collaborative, open and free project means, at the very least, conforming to the project's requirements, technically and possibly socially. And that means
Re: [Flightgear-devel] FlightGear aircraft repository
On Wed, Oct 19, 2011 at 10:19 AM, Cedric Sodhi wrote: other developers may take care of your work when you're not around, others will feel responsible to provide support if they can,...). I think we have sufficiently seen how other people's work is taken care of after they leave. And how much it helps in this regard, that the planes are forced under the hood of GPL and subjected to your authority, your restrictions. I think old, abandoned planes will equally, if not more likely be willingly taken over by others, if they are not forced into a master-repo. Why? To my mind the practicality of being able to maintain and improve aircraft after the original author has left the project is one of the best reasons for having a shared repository. I have been involved in maintaining a number of aircraft after their original author's have moved on, so have quite a lot of experience in this area. I have found that having a shared aircraft repository has made it straightforward to make the (often quite minor) changes required to ensure that the aircraft continue to fly, and made it straightforward for new people to contribute, often years after the original author has left the project. A prime example of this is the Piper Cub. The following is from memory, so apologies if I get the names wrong: The original model was by David M. He moved on, and after a period of a number of years with only minimal maintenance (to ensure it continued to fly), another user (Karla IIRC) made significant improvements to the model. He himself moved on to other things, and more recently I myself took over and made some minor changes to the model and improved the FDM. If the aircraft had been held in a separate repository, the minimal maintenance would not have occurred, and the aircraft would have bit-rotted, and become unflyable. There's not much incentive to improve an aircraft that doesn't fly. It's unlike that Karla or myself would have put the effort into maintaining and improving the aircraft. Additionally, having a shared repository made the practicalities of maintenance straightforward. Karla didn't have commit rights, but was able to submit patches that were applied on his behalf by a team of committers. If there had been a separate private repository run by (say) Dave M, Dave would have had to commit the patches or give Karla commit rights. Dave's a nice bloke and I'm sure would have done so, but it's possible that contributors pass away, lose their passwords etc. The alternative is that Karla would have had to create his own repository, and fork the aircraft. All of this is more of a hassle. (I myself have commit rights, which makes life a lot easier) -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 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] FlightGear aircraft repository
Just to add my own 2 cents while the central repository is a fine idea , after the move to git , I lost any commit rights to my own work, so after a time i gave up on the idea of maintaining them and started my own repositories . I would have happily continued to maintain/upgrade them , and I,m hoping this change might make things easier ... but if Im now being told that my work can be changed without any notice to me , that i have no say over my own contributions, then I wont waste any more time here. I do appreciate addons to my work , particularly stuff I dont/cant do but saying it's in the central repo so i can change it whether you like or not does dampen the spirit of contribution . Kind of reminds me of a contract or two Ive signed in the past , and I really hope FG isn't coming to that. Remember when we had common courtesy here ? And we all discussed changes openly ? P.S. After proofreading this have decided i need sleep :) Cheers -- 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] FlightGear aircraft repository
On 19 Oct 2011, at 11:53, syd adams wrote: while the central repository is a fine idea , after the move to git , I lost any commit rights to my own work, so after a time i gave up on the idea of maintaining them and started my own repositories . I would have happily continued to maintain/upgrade them , and I,m hoping this change might make things easier Hmm, that's a straight technical oversight - myself or any other the admins would have added you in 10 seconds, if we'd know there was an issue. My understanding was that all people with CVS access were granted commit access after the move to Git - that was certainly the intention! This is orthogonal to your points about courtesy to authors when making changes to their aircraft, which I also agree with - I just wanted to be clear we don't confuse an administrative screw-up with a 'policy change' that never in fact happened. 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] FlightGear aircraft repository
I would have happily continued to maintain/upgrade them , and I,m hoping this change might make things easier ... but if Im now being told that my work can be changed without any notice to me , that i have no say over my own contributions, then I wont waste any more time here. I think that needs a distinction between what's true in principle and in practice. In principle it's true that you signed over your work, so anyone can change it without notice. The rational is that if anyone gets angry, he can't leave and take his work with him and stall the whole project in the course. So in the case that you would decide to leave Flightgear in anger, it would probably occur that your work would be modified over your objection if that's needed to keep it running. In practice, there is common courtesy to authors. I haven't witnessed many situations in which an aircraft was modified without consulting the author, when this happened it turned out to be an accident rather than intention. I have witnessed the opposite, i.e. that a change to an aircraft made by someone else was not committed because the original author objected. Most of us are adult people, and most of the time we are able to act like civilized people, i.e. we can work out things in a reasonable way without invoking the law and waving license around. There are some rules for emergency cases necessary though. So, I'm pretty sure no one will go ahead and modify your stuff without asking you first as long as you're around and participating. Hasn't ever happened to me (and the temptation must have been there...). Cheers, * Thorsten -- 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] FlightGear aircraft repository
On 19 Oct 2011, at 12:27, thorsten.i.r...@jyu.fi wrote: Most of us are adult people, and most of the time we are able to act like civilized people, i.e. we can work out things in a reasonable way without invoking the law and waving license around. There are some rules for emergency cases necessary though. So, I'm pretty sure no one will go ahead and modify your stuff without asking you first as long as you're around and participating. Hasn't ever happened to me (and the temptation must have been there...). +1 to all of this, thanks to Thorsten for expressing it very nicely! 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] FlightGear aircraft repository
Im still not sleeping , so thanks for clearing things up. I for one like the aircraft split , just awaiting the require permissions.Will be nice to get my own work up to date without risking breaking something elsewhere in fgdata . Cheers On Wed, Oct 19, 2011 at 5:42 AM, James Turner zakal...@mac.com wrote: On 19 Oct 2011, at 12:27, thorsten.i.r...@jyu.fi wrote: Most of us are adult people, and most of the time we are able to act like civilized people, i.e. we can work out things in a reasonable way without invoking the law and waving license around. There are some rules for emergency cases necessary though. So, I'm pretty sure no one will go ahead and modify your stuff without asking you first as long as you're around and participating. Hasn't ever happened to me (and the temptation must have been there...). +1 to all of this, thanks to Thorsten for expressing it very nicely! 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 -- 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] FlightGear aircraft repository
I missed a day being offline yesterday, and now I see there's no way I'm going to be able to read every message in this thread word for word and catch (and acknowledge) every nuance of every point being made. So let me just say what I'm thinking, which probably echos the sentiments of the other long-time developers. FlightGear is licensed under the terms of the GPL. The GPL isn't perfect in all situations, but it's well thought out and (I think) does much more good that harm. And it would be *very* hard to change now at this point anyway. The FlightGear data repository has always welcomed inclusion of aircraft as long as developers are willing to be consistent with the rest of the project and use the GPL. This way we can distribute the package under a consistent license, developers can borrow code and ideas and models from other developers without worry about license issues. And there are all the other good points mentioned by others in this thread. What I don't want to see is someone's frustration with a technical issue turn into sweeping policy change. If there is an access/permission problem, let's fix it. If there is a technical issue let's build something to address that. The reason we don't mention or list other aircraft outside the central repository is not because we don't like their license terms or don't like them doing something on there own. That would be wildly mistaken. We absolutely support freedom and support authors developing and releasing their work however works best for them. Also we recognize that that central FlightGear repository can't scale to cover every aircraft and variant in the world. The reason is that there is no central repository of external aircraft and no way to keep track other than a huge manual effort. So I say: let's keep focused on the original intent of a central repository to support and help aircraft developers (but not lock them in if they don't want), and also facilitate keeping aircraft working and consistent when something on the software side changes. If there are some negative side effects, then lets build a system that allows us to track and reference external hangars and external models. (If that is what we want and need.) I have no problem putting links to other aircraft or having them somehow show up in a search, but the impediment is time and technology. So rather than argue over it, let's build something that fixes the problem -- something that helps us categorize and index and link to all the available aircraft, not just the ones that are GPL and managed within the central FlightGear repository structure. At the end of the day, I definitely want to encourage aircraft developers to consider releasing their work under the GPL and managing their aircraft as part of the central core of FlightGear. I think in the long term this has the best net positive effect for everyone. But certainly I understand there can be many reasons to do otherwise and I don't think we have any negative feelings towards developers that choose a different route, I think we'd like to support that and help them list and promote their aircraft too. Thanks, Curt. On Wed, Oct 19, 2011 at 7:57 AM, syd adams adams@gmail.com wrote: Im still not sleeping , so thanks for clearing things up. I for one like the aircraft split , just awaiting the require permissions.Will be nice to get my own work up to date without risking breaking something elsewhere in fgdata . Cheers On Wed, Oct 19, 2011 at 5:42 AM, James Turner zakal...@mac.com wrote: On 19 Oct 2011, at 12:27, thorsten.i.r...@jyu.fi wrote: Most of us are adult people, and most of the time we are able to act like civilized people, i.e. we can work out things in a reasonable way without invoking the law and waving license around. There are some rules for emergency cases necessary though. So, I'm pretty sure no one will go ahead and modify your stuff without asking you first as long as you're around and participating. Hasn't ever happened to me (and the temptation must have been there...). +1 to all of this, thanks to Thorsten for expressing it very nicely! 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 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats,
[Flightgear-devel] FGData Split First impressions
Pulled c172p, senecaii, f16, citationx, citation-bravo. c172p, f16 and citationx work fine. senecaii and citation-bravo show random splash screens during initialization and start with no cockpit or external view model to be seen. Symlinking the directories into $FG_ROOT/fgdata(NEW)/Aircraft makes no difference. Both ac work fine is I use --fg-root=where-fg-lives/fgdata-OLD Am I missing something vital or is the new system not ready for use yet? Kind regards, Alasdair -- 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] FlightGear aircraft repository
Cedric Sodhi wrote: On Wed, Oct 19, 2011 at 10:28:33AM +0300, thorsten.i.r...@jyu.fi wrote: You seem to entertain the idea of a free lunch - get the goodies which being part of the Flightgear project has to offer, but keeping the freedom to do what you want. That may be a positive creative development structure from your personal point of view, but certainly not for everyone else who is then supposed to provide infrastructure for you. If you consider those, who contribute planes, looking for a free lunch, I seriously must wonder what kind of attitude you presume in an open source project. What is that lunch exactly? The fame, perhaps? Even though I'm just citing a small part (to save everyone from browsing the entire article), I agree with everything Thorsten wrote in his posting. I may remind those who are having hard times at understanding the context that the 'traditional' development model with a combined hangar at least brought them an OpenSource flight simulation with quite a few pretty fine aircraft. Cedric, I'm not claiming that everything's perfect in FlightGear land, but until now you failed to show how you're going to contribute a solution to any of the relevant issues wrt. The FlightGear project's aircraft hangar. Instead, you're just applying a technical solution to a non-technical issue an approach which usually is destined to fail, as history shows. 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 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
[Flightgear-devel] Do not clone fgdata-new
Important message for anyone that uses Git: DO NOT CLONE FGDATA-NEW for the moment. That repository was meant for testing-purpose only. In fact we found out that there were still aircraft-commits in there and Jorg is currently pushing a new (testing!) repository. The old fgdata is still up (at the good old url) and there is at the moment no need for the mass to move over to the new repository. Once everything is in place and properly tested (and there are manuals/scripts to pull aircraft etc.) Jorg, ThorstenB or I will notify the mailing list and forum. Sorry for the inconvenience. This just proofs how important communication is... -- 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 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] Flightgear-devel Digest, Vol 66, Issue 14
Martin says : 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. Yes ! I agree. Place all the planes in a second deposit, why not. But hundreds of deposits is totally ridiculous. Regards Emmanuel -- BARANGER Emmanuel http://helijah.free.fr -- 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
Hello everybody, I apologize if my initial mail did not describe it clearly enough. I hope this mail helps with all of your questions: Before you go on a disclaimer ahead: There has been a minor (not just in a manner of speaking) complication with the new FGDATA repository, so there is now a new-new fgdata repository (which has that minor issue rectified, although the old-new fgdata was perfectly usuable aswell). We are currently doing the final reviews on the new-new fgdata and that should be the fgdata to pull, once everything is verified. There are the following repositories now: fgdata an2 14bis 21 707 717 727-230 737-100 737-200 737-300 737ng600 737ng700 737ng800 737ng900 747 ...etc... = The first repository is the plain fgdata which everyone will need to clone. It will sit in the place where the current fgdata (with all the airplaines) sits and replace that. For that, you will have to move the old fgdata to a place elsewhere. And if you don't have any local branches on it, you can already delete it. If you have local changes, you will have to prepare patches between current master-tip and your local branch-tip, and apply these patches to the new fgdata master-tip. The following repositories are the aircrafts. You will have to clone every aircraft which you would like to have as a git repository. And you should clone them into a different directory than fgdata (strongly recommented). If you want all aircraft, you will have to clone all aircraft. These are the simple facts. - For your convenience, here is a script which pulls and updates all aircrafts from our central repository which you would like to have. In order to use it, you need to create a textfile into which you put the names of all aircrafts which you would like to have. Each name into its own line. Example - an2 21 747 b29 - Then you run this script like this $ ./fgaircrafts path to list path to aircraft directory Example: $ ./fgaircrafts list.txt /usr/local/flightgear/aircraft Those aircrafts which have already been cloned will be pulled, those which are not yet there will be cloned. Note: The script operates on the repositories in parallel, so don't expect any readable output on the commandline. Script Attached #!/bin/bash if [[ ! -f $1 || ! -d $2 ]] ; then echo Usage: $0 listfile target listfile File with names of aircrafts to manage, one aircraft per line targetDirectory into which to put the aircrafts exit 1 fi ( cd $2 while read ac ; do ( if [[ -a $ac ]] ; then if [[ -d $ac ]] ; then cd $ac git pull fi; else git clone git://gitorious.org/flightgear-aircraft/$ac.git fi ) done 3 ) 3$1 -- 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: Important note
Hi FlightGear, there was little input on the fgdata split and few people speaking up when things were started. We do see a lot of responses now - many being in favor of the change, but also concerns about remaining issues. Indeed, setting up the new repo isn't as simple as it seemed initially, and there are issues which need to be resolved. We also need common acceptance of the new structure, tools and processes. Unfortunately, the call for split completed was communicated ahead of time - even before fgdata itself was switched. And we still do see a need for a proper testing phase before switching - including a chance for everyone to give input, raise concerns, etc. So, after long discussions tonight, including Gijs, Jorg, James, TorstenD, ThorstenB Curt, we agreed to the following: * We hereby announce a longer testing phase for the proposed changes, which will at least last 4 weeks (at least until November 17th). We will try to get all tools/scripts and processes in place and test how things work for everyone. We will also see how we can preserve the existing workflow for people who wish to stick with their current process (i.e. use a super-repo, possibly using git submodules). * Meanwhile, we do _REOPEN_ the existing fgdata repository - which for the time being remains the master repository. This was chosen to relieve the new repository, tools and manuals of immediately working for everybody - and to also allow possibly rewriting the new repository, if necessary. We still do invite everyone for testing the new setup. * We will try to sync changes from the master repository into the new split repositories, so these can be used for syncing and testing. We are really sorry for any inconvenience and misunderstandings this further change may cause. But now, as we have everybody's attention on the subject, we're looking forward to many people testing the proposed changes. We also invite everyone to speak up on which kind of repository they prefer. And we are still collecting issues and topics in the Wiki: http://wiki.flightgear.org/FlightGear_Git:_splitting_fgdata Finally, please be aware that, while we welcomed his input on the splitting process, some of Cedric's switch announcements do not reflect the opinion of the others involved, neither were they fully agreed upon (in content and timing). Best regards, Gijs, Jorg, TorstenD, ThorstenB, James Curt -- 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: Important note
On Thu, 20 Oct 2011 00:10:29 +0200 ThorstenB bre...@gmail.com wrote: We are really sorry for any inconvenience and misunderstandings this further change may cause. But now, as we have everybody's attention on the subject, we're looking forward to many people testing the proposed changes. We also invite everyone to speak up on which kind of repository they prefer. And we are still collecting issues and topics in the Wiki: Well, since you ask... I did start several emails at various points in the process but never sent any of them, mostly because I felt others had already made the points I wanted to state already, and didn't see any overwhelming vote for tearing up the status quo. For all the reasons previously stated, I'm completely in favour of ONE data repository for FG; if it really must be split up (and I have yet to see any convincing reason for that stated) I feel that there should be one aircraft repository. The alternatives with hackish scripts trying to download aircraft from here and there are just horrible, add extra unnecessary complexity and confusion - they don't make life easier for anyone at all. For a year or more now I've had no time to even maintain the models I spent massive amounts of time building; but I've been happy in the knowledge that at least they are in the fgdata repository and essential maintenance will (and has) been done to keep them from rotting entirely. I _don't_ want them split out; I wasn't unhappy with the previous state where my work on my own models was submitted to someone with commit rights. Indeed, a second glance at my changes before committing was welcomed from my point of view. The idea that the somehow the fgdata repository was spiralling into some gigantic out of control monster, bringing the Internet to its knees is nonsense. It's barely a DVDs' worth of data, most of us download that kind of thing without a second thought - this is 2011 after all. I do sympathise with those struggling with poor connections as I've been there too... however as Martin already pointed out there were starter snapshots of the repo available via presumably resumable HTTP, catering for those people. From my point of view all I've seen here is a few people (however well-intentioned) fruitlessly hacking apart something well proven to actually work for practically everyone that _works_ on the FG data as opposed to those who just try out the latest stuff - I'm not suggesting there's anything wrong with that (especially as these days I'm more in that category myself) but those users should have little priority. AJ -- -- 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
