Re: Issues updating planes located in FGAddon

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)

--
Josh Davidson
________________________________
From: Nia <[email protected]>
Sent: Monday, June 1, 2026 13:59
To: Josh Davidson <[email protected]>; James Turner <[email protected]>
Subject: Re: [Flightgear-devel] Issues updating planes located in FGAddon

On 6/1/26 18:54, Josh Davidson wrote:
 > Tbh as much as I dislike gitlab, I think moving there so all the stuff
 > is in one place is a good idea.

You're absolutely right, gitlab is the logical choice for consistency...
Just not the most user friendly or sustainable one.

Moving it to gitlab is certainly a win tho!

> I didn't understand anything James said about the complications of
> submodules. Can't you just treat them as sub repos like we do in svn
> kinda? Apologies if I'm just not educated

We could just have them as a collected organization containing all the
aircraft as individual repos. This would also allow for git based
development happening right there in that gitlab organization, with the
mentioned benefit of maintaining control over the repo when devs leave.
We can have easy pull request work flows too.

> Or maybe we can consider another svn provider? Or self host? (I'd be
> willing to assist)

I don't understand why some folks still cling so much to svn...
That's the part I would really like to understand. I truly don't see any
benefit to it anymore in 2026.


> ------------------------------------------------------------------------
> *From:* Nia <[email protected]>
> *Sent:* Monday, June 1, 2026 6:54:44 AM
> *To:* James Turner <[email protected]>; [email protected]
> <[email protected]>
> *Subject:* Re: [Flightgear-devel] Issues updating planes located in FGAddon
> I've already suggested this a while ago in a discussion, James back then
> suggested a different organization on gitlab. The way gitlab
> enshittifies so fast with the AI bullshit I don't see it as a
> sustainable option tho. My go to would be codeberg, which is run by a
> german non-profit. They use forgejo which looks a lot like github so
> folks like Josh should feel right at home there. (And don't have to deal
> with that awful gitlab UI)
>
> On 6/1/26 10:18, James Turner wrote:
>> (Eg, can we find a provider which allows non-Git access over something
>> like SFTP, for people who really can’t use Git?)
>
> Honestly? This is just a huge pile of technical debt at this point!
> Why do we so desperately need this? Who is that really for? You can
> learn the git basics in 30min and are good to go! And it is effectively
> standard these days! The chances that someone has to learn git vs svn to
> contribute, that's a difference of probably a few magnitudes! Most devs
> know git already and need to learn svn!
>
>> Just saying 'use submodules’ doesn’t help us, we will get banned if we
>> auto-create a project for each aircraft on most providers, I would
>> guess. (And do we even want that anyway?) And eg if we added all those
>> submodules on our current GitLab, it would make a bunch of the Group-
>> level stuff pretty tricky to manage. So there’s the technical thing of
>> do we want solution X or Y, and there’s the biz / political thing of
>> what providers will be long-term ok with a particular solution, and what
>> is the intersection of those two things.
>
> The most biz/politically safe thing, (which isn't self hosting) would
> imo be codeberg, as said, run by a non-profit, using software developed
> by a group of devs that put great effort into creating a sustainable
> fork after gitea (from which is got forked) went into "core devs abuse
> the project for their own commercial gain"-mode
>
>> However, one thing maybe worth pointing out: with the improvements to
>> the catalog build scripts, you do *not* need to have your aircraft in
>> FGaddon, to have it be included in the default catalog. We can ‘just’
>> add your upstream SCM to the config:
>
> Problem with that is, that we don't have a centralized place anymore...
> Other repos go down, people leave... if someone wants to pick it up,
> they have to find it... $somewhere, then fork it to $somewhereElse then
> update the references... and then maybe the initial dev comes back and
> wants their version back and we're in for conflict. This wouldn't happen
> if the repo was in a central place... If it's a git repo, and the dev
> REALLY doesn't wanna use the solution we pick (which I would totally
> understand if the choice is gitlab) then with git, we can just declare
> the new fgaddon git as a pull mirror for the time the development is
> elsewhere, keeping an up-to-date copy under project control!

_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel