Menu
▾
▴
Re: [Flightgear-devel] Suggestion for a 737-family repository in FG GitLab
|
From: Xavier D. C. R. <xa...@di...> - 2025-12-01 14:36:56
|
Hello, All of the solutions I mentioned before are listed as forges according to Wikipedia, even if their marketing teams avoid such term. [1] OTOH I understand the concerns regarding availability in small instances. In such case, big and well-funded instances such as Codeberg [2] can be a reasonable choice. Best regards, Xavi [1]: https://en.wikipedia.org/wiki/Software_forge [2]: https://codeberg.org/ On 12/1/25 14:43, Nia via Flightgear-devel wrote: > On 12/1/25 14:32, Israel Emmanuel wrote: >> Is Github/Gitlab a software forge? I thought of them as just cloud >> storage providers, more or less. > > Yes, they are more than a storage provider. > >> I personally would trust Github or at least Gitlab to handle my >> repository better than any self-hosted repository, and I know I'm not >> alone. > > Trust by which metric tho? > It still being there in 10 years? Yes! > It getting abused to train AI on it without your consent? > You can basically bet on that too! ... big reason to not trust these > platforms! > >> I suppose you can work it out with the people who will actually be >> putting real effort into it, but I sense that a more popular platform >> will be the optimal solution for a 737 reboot. We will have to wait >> and see. > > The problem with this thinking is, you'll be for ever stuck with > what's popular right now... a popular platform that gets worse and > worse, like Github did a lot in the last years, will remain popular > while new platforms don't get a chance... But in the beginning, Github > wasn't popular either... someone had to make the first repo there... > so why not take the step now, when establishing a new repo anyways? > Always easier than moving somewhen in the future. > > Forgejo will become a quite viable option once it got good federation > support, rn it has that one big downside which will be solved with > federation. > >> >> Get Outlook for Android <https://aka.ms/AAb9ysg> >> ------------------------------------------------------------------------ >> *From:* Xavier Del Campo Romero via Flightgear-devel <flightgear- >> de...@li...> >> *Sent:* Monday, December 1, 2025 3:27:53 AM >> *To:* fli...@li... <flightgear- >> de...@li...> >> *Cc:* Xavier Del Campo Romero <xa...@di...> >> *Subject:* Re: [Flightgear-devel] Suggestion for a 737-family >> repository in FG GitLab >> Hi James, >> >> Sorry for the delayed answer. >> >> I think the point behind their suggestion [1] was to ensure the project >> does not fall into the Bermuda Triangle category [2] whenever the >> repository disappears for whatever reason. Actually, to be honest I >> would prefer Forgejo (which I self-host [3], btw) over GitLab, >> SourceForge, GitHub or any other proprietary software forge. >> >> Best regards, >> >> Xavi >> >> [1]: https://forum.flightgear.org/viewtopic.php?p=436580#p436580 >> <https://forum.flightgear.org/viewtopic.php?p=436580#p436580> >> [2]: https://wiki.flightgear.org/Category:Bermuda_Triangle <https:// >> wiki.flightgear.org/Category:Bermuda_Triangle> >> [3]: https://gitea.privatedns.org/ <https://gitea.privatedns.org/> >> >> On 11/27/25 13:15, James Turner wrote: >>> >>> >>>> On 26 Nov 2025, at 14:42, Xavier Del Campo Romero via >>>> Flightgear-devel <fli...@li...> wrote: >>>> >>>> Then, I was suggested [6] to write to this mailing list so that an >>>> official repository for the 737 family in GitLab, so at least the >>>> repository is always governed by the FlightGear community and is >>>> therefore not abandoned, like happened with the others before it. >>>> >>>> I cannot guarantee I can actively work in the 737 (mostly because >>>> of other projects and IRL stuff), but nonetheless I think the >>>> suggestion above is a good first step to improve the current >>>> situation. From a first glance, the 737-800YV looks like the most >>>> mature implementation, even if I suspect its repository contains a >>>> few non-free assets that should be reviewed. The intention is to >>>> cover all 737 variants within this repository, if possible. >>>> >>>> Please let me know your feedback. >>> >>> Hi Xavier, >>> >>> We can easily make you a project on GitLab, *but* you can also just >>> do this yourself (on GitLab, or GitHub, or anywhere). And you can >>> maybe guess, there is nothing ‘official’ when you do this, because >>> we actually no such concept as any ‘official’ aircraft development >>> repo, and indeed, no one has ever defined what that would mean :) >>> >>> (We do have aircraft included in FGaddon, which have to follow >>> certain rules, eg being GPL, allowing bug-fixes from anyone, but >>> FGaddon is really a distribution mechanism now, it’s not the same as >>> a GitLab/Hub project for development work - unless you’re of course >>> happy with pure SVN and no bug tracker) >>> >>> We **could** start making aircraft as sub-projects of the FlightGear >>> *group* on GitLab, but I’m slightly worried about that for a few of >>> reasons: >>> >>> - we have some account limits for the group, not the project >>> (especially around storage, users) >>> - our open-source account requires checking every project inside >>> for compliance, each year. (And I really don’t want a minor issue >>> with one acft to impact the whole group) >>> There’s also some combined resources, eg the group-level issue >>> tracker would then include issues in your aircraft project. This >>> might be considered an advantage or disadvantage, depending on how >>> well or badly, the bugs are triaged and maintained :D >>> >>> Finally there’s also the question above of what ‘official’ means: in >>> terms of core development, we aren’t going to treat an aircraft any >>> differently because it’s inside the group than outside, but users >>> might perceive it that way, and that seems like it might cause >>> politics. >>> >>> Given this, I’d say life is simpler if you just make a project on >>> your provider of choice (which might be GitLab), and pull in >>> whatever existing 737 resources you need (since it’s all GPL), and >>> if the result meets the standard criteria of being obviously better >>> than the existing aircraft in FGaddon, we can do the established >>> procedure, of moving the older/unmaintained acft to the ‘attic’ and >>> making the new one the ‘official’ (hah) one in FGaddon. >>> >>> Kind regards, >>> James >>> >>> >>> >>> _______________________________________________ >>> Flightgear-devel mailing list >>> Fli...@li... >>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel <https:// >> lists.sourceforge.net/lists/listinfo/flightgear-devel> >> >> >> >> _______________________________________________ >> Flightgear-devel mailing list >> Fli...@li... >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel >> <https:// lists.sourceforge.net/lists/listinfo/flightgear-devel> >> >> >> _______________________________________________ >> 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 |
