|
From: Frederic T. <the...@gm...> - 2026-06-02 18:26:57
|
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 > |