Re: [Flightgear-devel] Suggestion for a 737-family repository in FG GitLab

[James T. <ja...@fl...>]

> 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