20,741
edits
How the FlightGear project works: Difference between revisions
Jump to navigation
Jump to search
m
How the FlightGear project works (view source)
Revision as of 14:59, 8 February 2012
, 8 February 2012→To be discussed: http://flightgear.org/forums/viewtopic.php?f=18&t=13298&p=134793&hilit=supply+developers#p134786
mNo edit summary |
m (→To be discussed: http://flightgear.org/forums/viewtopic.php?f=18&t=13298&p=134793&hilit=supply+developers#p134786) |
||
| Line 66: | Line 66: | ||
* FlightGear has never been in a better shape than it is in right now. In fact, admittedly FlightGear -as a software project- has actually been in a much worse shape for many years (for example: no forums, no wiki, no bug tracker, no git repository, no gitorious merge requests, no build server, no formal release procedures etc)- still it somehow managed to stay around for over 10 years, despite all its deficiencies... | * FlightGear has never been in a better shape than it is in right now. In fact, admittedly FlightGear -as a software project- has actually been in a much worse shape for many years (for example: no forums, no wiki, no bug tracker, no git repository, no gitorious merge requests, no build server, no formal release procedures etc)- still it somehow managed to stay around for over 10 years, despite all its deficiencies... | ||
== Mods and forks (built on top of FG) == | |||
* You're here asking for help from the Flightgear community. Help is hard to find in the first place (that's a fact, not a threat - there are calls for volunteers for many different projects that go unanswered). | |||
* You're planning to fork in a substantial way. The difference for me is - as long as what you're doing is Flightgear, I will care that my own development work (integrated weather system) runs fine on your system because I develop for Flightgear. If T4T is off to the degree that I'd have to download and compile different code, then I won't care that my weather system runs (it may or may not, dependent on what you do to the environment) - it has become your problem. Not because I am mean, but because I don't have the time and inclination to maintain compatibility to two different development branches. Whenever you develop using a different repository, you are 'them' and we are 'us'. We can be a friendly 'us' and 'them' as between Flightgear and JSBSim, we can exchange code, people can be part of both projects and maintain compatibility and work together - but the basic fact is that there is 'us' and 'them', and (probably like many others) I feel responsible for my part in 'us' but not for my part in 'them'. | |||
http://flightgear.org/forums/viewtopic.php?f=18&t=13298&p=134793&hilit=supply+developers#p134756 | |||
* Do you have a clear idea what your project involves? | |||
* Do you have a clear idea what is already there? | |||
* Will it help Flightgear? | |||
* Will my voice be heard? | |||
* This community is far more likely to get involved if you involve it - and that'd mean opening your previous decisions for debate - than if you ask people to get involved with a project of your design which is no longer up to debate (speaking of resistance to change...). Again, that's your call, I'm not threatening in any way, I'm simply trying to explain how things (according to my best understanding) are and what the likely consequences of your project design are. I don't mean to imply that I or others would actively block you if you're not doing it 'the Flightgear way' and hold information back. I hope that is sufficiently clear. | |||
* We get to see new forum members posting interesting "project ideas" here every month, sometimes even several times per week. And we know from experience that "ripping FlightGear down to its core and rebuilding it" isn't going to happen that easily, it's not necessarily because of objection from the community - quite the contrary, sometimes people actually post ideas that everybody agrees would be great additions to FlightGear, ideas that would quite obviously involve tearing down some major subsystem and replacing it with something better. | |||
* Really, FlightGear is where it is now after 10+ years of ongoing development, many contributors (especially core developers) are long term contributors who have contributed to FlightGear for several years. | |||
Still, FlightGear is a complex piece of software and there is probably not a single core developer who is familiar with ALL of FlightGear (features, code etc). | |||
* all long-term FlightGear users know for a fact that there is usually a short supply of C++ developers, knowing not only how to program in C++, but also familiar with 3D graphics, OpenGL/OSG programming and many other aspects that are important when creating/developing a simulator. | |||
* So we are really standing on the shoulders of giants here, because we are now -after 10+ years- in the position to create significant new features within the constraints of the FlightGear base package, without even touching the C++ source code at all - simply because FlightGear has become so flexible and extensible. | |||
* So I guess you see where I am coming from: new people now asking to "tear down & rebuild" the whole thing, or people asking to introduce DRM-like measures into FlightGear (content protection) are of course not going to receive a very warm welcome | |||
* I consider what you want to do perfectly possible, but I advise you to rethink your strategy: your decision to build upon FlightGear to create a combat simulator illustrates an admirable degree of foresight and experience that many other people with similarly ambitious ideas lack, but announcing to "rip out parts" and rebuild the whole thing is very unlikely to happen anytime soon. | |||
* And like I said before: this is not necessarily because we don't want to see this happen: you could probably talk to any core-developer and each of them could tell you that there are a number of parts that SHOULD be ripped out and replaced eventually (i.e. such as some legacy code), but more often than not, things are simply not as easy as they may appear at first glance. When you take a look at the mailing list archives or at the wiki, you'll certainly find plenty of things in the fgfs source code that everybody agrees should be replaced eventually. | |||
* And if people who have experience working with the code for a number of years refrain from making some important changes, you may want to re-consider your strategy. | |||
* After all, this is all "for fun" - it's an open source project, so it should be "fun" and enjoyable. | |||
* you'll have a better chance of getting your code upstream (if that really is your goal) by coordinating your plans with the fg core developers and asking for recommended paths to proceed. Getting your code contributed back is obviously a good idea because it will be much less of a maintenance burden for you guys if your changes become part of the mainline. | |||
* Ultimately, this being open source, you don't need the approval of anybody - as long as you obey the requirements of the GPL, but rest assured: it will be much easier to deal with the FlightGear community and to get help if you play it "nice" and this very help will be very much needed in the beginning. | |||
* Suggesting "drastic" changes is all neat and dandy, but after familiarizing yourself with FlightGear you'll probably see quickly that it doesn't really need drastic changes at all: We have witnessed this in the "Local Weather" project, you could say it now *optionally* replaces the old system, but to work properly it only needed a way to switch off the old code - which just involves setting a bunch of properties (variables) from a Nasal script. There was no need to completely remove the legacy code, it was just made optional by setting a switch at runtime. Similarly, the bombable script leverages hard-coded C++ code for instantiating AI models dynamically - but the objects are controlled from scripting space. | |||