Re: Issues updating planes located in FGAddon

No thanks, that would take WAY too much work. I have no interest in that. It's just an XML being fed by a JSBSim system which is specific to each plane, and the XML just animates it... I have no interest in trying to make that XML animating it account for tons of different airplane's systems.

Kind Regards,

--
Josh Davidson
________________________________
From: Frederic T. <[email protected]>
Sent: Tuesday, June 2, 2026 13:26
To: FlightGear developers discussions <[email protected]>
Subject: Re: [Flightgear-devel] Issues updating planes located in FGAddon

Then the instrument in question needs to have an interface that allows it to be configured to the aircraft's need, putting only the actually common code into the generic implementation :)

Am Di., 2. Juni 2026 um 20:24 Uhr schrieb Josh Davidson <[email protected]<mailto:[email protected]>>:
Agreed. I have common code across aircraft but it still needs tweaking to each aircrafts systems.

Generics are not usually a great solution.

--
Josh Davidson
________________________________
From: Frederic T. <[email protected]<mailto:[email protected]>>
Sent: Tuesday, June 2, 2026 1:20:26 PM
To: FlightGear developers discussions <[email protected]<mailto:[email protected]>>
Subject: Re: [Flightgear-devel] Issues updating planes located in FGAddon

> I’d prefer we get some tooling in place to allow at least search-and-replace operations across the whole set, working on eg instrument changes or AP changes without that would be more error-prone.

If we need to do that, we did something wrong, and we are doing it wrong since the beginning - instruments / APs / etc. should not be copied into every aircraft but at the very least be in a separate repository integrated into the aircraft as a git submodule, or even better we have a framework that allows integration of instruments etc. from a repository like FGAddon.

Am Di., 2. Juni 2026 um 18:58 Uhr schrieb James Turner <[email protected]<mailto:[email protected]>>:


On 1 Jun 2026, at 23:00, Josh Davidson <[email protected]<mailto:[email protected]>> wrote:

How about a git organization with planes as sub-repos? That shouldn't be a problem at all. (Suggested to me by a private email)


That is possible but needs (I think) the following:
 - get permission from GitLab (formally, eg in writing) that a group/org with 200+ repos is valid use of their SaaS service, and they won’t consider it abuse.
 - apply for an open-source org (like we do for Flightgear already) for that group (I could help with that, but we need to show that every repo is license compatible, and do some other house-keeping)
 - have scripts that extract aircraft from the svn history and create corresponding projects/repos **with Git LFS enabled**.

(The LFS part is really important, to make the checkout experience ok)

And having done that, we would have 200+ discrete repos: so no way to grep / modify multiple aircraft at once. I’d prefer we get some tooling in place to allow at least search-and-replace operations across the whole set, working on eg instrument changes or AP changes without that would be more error-prone.

What we can’t do is make them all submodules of one super-repo, I think that will be just as slow / bad to checkout as the current SVN, or close to it. (My experience is more than 10+ submodules is asking for trouble)

However, if we do that, there is no reason to have a GitLab repo for eg the A320 or C172, since we’re just mirroring a repo that exists elsewhere (on GitHub or anywhere else); I think we may as well have the Fgaddon catalog builder just pull from the primary repo for each aircraft.

There’s also the user education part of this, we’re changing the workflow and tooling for a bunch of people, many of whom are not ‘coders’. Concepts like push-ing and rebasing are going to need some hand-holding for them, I expect, and the state of Windows GUI git-clients is a bit tricky, to put it mildly.

I’d be curious to hear from Torsten D, who did the private negotiations with SF originally to be allowed the current SVN setup, if the above seems feasible, since this is all just based on my experience.

Kind regards,
James

_______________________________________________
Flightgear-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
_______________________________________________
Flightgear-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel