Re: [Flightgear-devel] Issues updating planes located in FGAddon

[Frederic T. <the...@gm...>]

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 <
jos...@ou...>:

> 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. <the...@gm...>
> *Sent:* Tuesday, June 2, 2026 1:20:26 PM
> *To:* FlightGear developers discussions <
> fli...@li...>
> *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 <
> ja...@fl...>:
>
>
>
> On 1 Jun 2026, at 23:00, Josh Davidson <jos...@ou...>
> 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
> Fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
> _______________________________________________
> Flightgear-devel mailing list
> Fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>