Hi Gilberto,
gsagostinho wrote in Mon Sep 21, 2015 11:36 pm:I managed to contact Heiko and I do plan to collaborate with this amazing 182, I just gave it a spin and it looks really promising (I just love that 3D cockpit and I can't wait to texturize it!)
I have also had contact with Heiko. It is clear that the aim is to have this aircraft included in FGAddon (if you look at the
aircraft download pages, you'll find Heiko's name all over the place, so this is normal procedure). I think Stuart has been contacted about this, but I would assume that he is very busy with the
FlightGear policy and roadmap document, the
FGMEMBERS statement, the
FlightGear v3.6 release process, many other administrative tasks, and RL (real life) added on top. So I wouldn't expect a response for a while.
These are two independent developments and some things are better in Stuart's $FGAddon/Aircraft/c182/ and some better in Heiko's. For example the instrumentation in Heiko's version requires a lot of work to come up to Stuart's standard. So maybe it could sit along side the current c182 and c182rg, and Stuart's developments pulled into Heiko's c182s? It sounds like Heiko has very big plans for the C182S, but he may need help in a number of areas.
As for the FGAddon commit access, I haven't thought about it because all the projects I worked with so far had their own separate repository and so it wasn't needed.
The FlightGear community encourages aircraft development directly within FGAddon (this has been mentioned a number of times, and matches the old FGData position). Therefore it would be good, after communicating with Stuart, to move Heiko's C182S into FGAddon. The Aircraft/c182s directory might be a good destination.
What would be the main advantages of this type of commit access in your opinion?
The main advantage is that development is centralised. This allows the FlightGear community to maintain the aircraft, keeping it in a working state, as the project evolves in the decades to come. The concept of aircraft abandonment is also very different, as the aircraft can never disappear. It will forever stay a part of the FlightGear project. Abandonment is rather defined as a period of inactivity until someone new comes along to pick up the next stage of development. This is also similar to how many of the venerable private hangars function (however if the entire hangar is abandoned and the aircraft are GPLv2+ licensed, the entire hangar will often be absorbed into FGAddon, ensuring their survival). Most importantly, developing directly in FGAddon is essentially giving a gift back to the FlightGear community that has provided us with such a wonderful flight simulator.
I am currently in the process of completely rewriting the
FGAddon wiki article. In the new section on
development scenarios, I hope to show how powerful and flexible the centralised development strategy can be. When combined with git-svn, this allows for a combined centralised+decentralised strategy. Have a look at the
private team development section - this is probably closest to how the c172p-detailed project was run. The idea is to have a decentralised development of a single aircraft in a private git repository under the team leader's SourceForge home page, which is directly linked to FGAddon using git-svn as a bridge to regularly push the developments into FGAddon. A
dedicated development team, and even admin team, can be defined to set permissions on each piece of SourceForge infrastructure set up for the aircraft development. Communication is much easier on the in-house SourceForge infrastructure as the team leader can set up a
forum dedicated for development of the aircraft. You can also set up a ticket tracker for the aircraft on your SourceForge home page (I should add this to the wiki). The team members can then develop directly on the team leader's git repository, or fork it and make merge requests, discuss on the dedicated forum, file bug reports on the dedicated tracker, etc. (see the admin section of your SourceForge homepage to see the other infrastructure elements available to you). Therefore, using this strategy, I believe that you could recreate exactly the same workflow as with the c172p-detailed on GitHub. But instead you'll be linked directly to FGAddon with commits freely flowing into the official repository, and you'll be using the in-house infrastructure of the FlightGear project.
For the c182s, using this private team development scenario, either Heiko or yourself could be the team leader. I think Heiko is planning a return to development of this aircraft. You two could then be in an admin team, and anyone else who would like to help can be in the development team. I can help with any of the details, but I'm hoping to expand the FGAddon wiki page enough so that that will be sufficient and no help would be required.
After you're efforts with the c172p and regional scenery, you have more than proved yourself and shown knowledge in the important licensing issues. Therefore if you were to set up a SourceForge account and then ask for FGAddon commit access on the
FlightGear development mailing list, your access is pretty much guaranteed.
Cheers,
Edward