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

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

> On 1 Dec 2025, at 14:36, Xavier Del Campo Romero via Flightgear-devel <fli...@li...> wrote:
> 
> 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.

From my perspective, you can use whatever host you like, so long as it’s reliable and available. However, in terms of collaborating on development, ease of ‘everything’  is helpful (and typically GitHub / GitLab score highly here, with other providers on a decreasing scale).

So, in terms of reducing the number of forks, I’d *prefer* GitHub/GitLab/etc but you can do what you want since in the end … people can always fork it. We’re just very close to:
	
	https://xkcd.com/927/

… at that point :)

Worth adding, since we discussed it last night : there is a sensible evolution of the packaging system ( https://gitlab.com/flightgear/fgmeta-python/-/blob/next/catalog/update-catalog.py?ref_type=heads )

.. where it pulls from an arbitrary number of source repos instead of just FGaddon + FGdata. In this case, we’d add more <scm> entries to the catalog config file (  https://gitlab.com/flightgear/fgmeta-python/-/blob/next/catalog/stable-2024-catalog/catalog.config.xml?ref_type=heads ) for each upstream repo, eg the A320, the c172, the c182 …. and ideally specify a brach to track. (Eg c172 2024.1 in the catalog would track some stable branch in the C172 GitHub repo)

In this case, the FGAddon SVN repo becomes gradually less important (tending towards zero) as maintained aircraft gradually get their own repos. (We’d be left with the just the attic + unmaintained acft )

This can be done *now*, if anyone cares to do the required Python hacking, just needs to extend the handling of the <scm> config blocks in the Python, and ensure everything runs on the Docker image that runs the scripts.

Kind regards,
James