Gitorious shuts down

[Necolatis]

Gitorious will soon shut down it seems.

Will merge into GitLab, which does not seem to support free hosting, as I get it.

Edit: Was maybe a bit fast to say that, it seems to support free hosting through its web-interface.

[legoboyvdlp]

GitHub is an excellent alternative (and no, nobody paid me!) It seems more user friendly than gitourious.

[elgaton]

It's GitLab, not GitHub

[legoboyvdlp]

I know. If the gitourious database gets wiped or something in the move. (uh-oh) I would support a move to GitHub. Or even if we have to pay, GitHub seems to be free.

[Hooray]

it's definitely interesting and touching on the whole fgdata/fgaddon debate that's been taking place over the last few weeks on the devel list.

[gsagostinho]

One more vote for GitHub!

[Hooray]

fgdata isn't easily moved to github due to its sheer size and the nature of the repository in its current form (it mainly containing binary data).
So, one of the project maintainers would need a statement in writing exempting FG from the corresponding TOS.
However, even if that was the case, moving to github might very well bring some of its own momentum with it, and FG as a project is generally not very good at dealing with "too much" momentum - i.e. projects on github tend to attracht a rather active following of contributors, with tons of "pull requests" and bug reports - which is something that FlightGear is particularly bad at dealing with (just look at the existing backlog of feature requests and merge requests) - thus, if the project should end up using a popular service like github, it will inevitably need more maintainers (developers and reviewers)...

[gsagostinho]

[...] moving to github might very well bring some of its own momentum [...]

That's exactly what I thought, but I saw only the good side of it. You do make some interesting points above though.

[IAHM-COL]

A few thoghts:

1) The size of all flightgear repositories (except FGDATA) is not that much. EVERYONE of them will fit comfortably the requirements of any host
2) I don't think WHERE the core developers host the sources matters, much at all. GitHub, Sourceforge, Gitlab, etc etc. A few considerations about git versions the host run, the friendliness of their web-page interface, the licensing of their own in-house plattforms, etc are secondary, but not central to, again, WHERE we host.

About size: All Fligthgear project IS mirrored in Github already (except FGDATA):
https://github.com/FlightGear
Not a problem with its size... at all!

3) The delicate issue we are dealing right now is about the future of FGDATA repository.

It used to hold the most complete version of FGROOT available and up-2-date.
Not anymore.

The aircraft had been versioned OUT to a Subversion repository hold in sourceforge, called FGADDON. Changes occuring in that SVN repository where never rebased on the FGDATA, meaning that for the aircrafts, these had been out of sync for at least 6 months.

SVN is a very rustic/primary Source Code Management system, and one with many fallbacks, the most important one is its difficulty of branching, thus difficulty of having a large manpower to improve. Apparently no-one else but me really care to understand the fact that we are LARGELY limiting our abilities to easily contribute to the aircraft base: the one single part of Fligthgear where most people could put a grain of sand to build a better project, even those without a deep understanding of computer programming.

Furthermore, currently, the core developers are executing a surgery on FGDATA that splits this repository to its end. Binary assets all being transferred to multiple SVN repositories (not good for aircraft and not good for much anything else, for that matters), and then a lot of configuration files being move to "flightgear" repository: where the compilable code resides.

Splitting FGDATA like this really means that such repository will cease to exist. And thus no location will really be hosting the most complete and up to date FG_ROOT that one could use.

This idea is lamentable, but strongly favorished by the "deciders" in flightgear development, and

Unless, many other people speak their voices in favor to maintain a purely gitted (as opposed to a git-svn hybrid alternative), nothing can hold the execution of this unfortunate alteration.

With all this, I am really making a call to fight the correct battle!
We don't need to vote for GITHUB vs Sourceforge or vs Gitlab etc.

We need to make our voice be heard about how important it is for us that Flightgear development maintains a CURRENT and UPDATED repository for FGDATA, available, and strongly developed. Size being a consideration, I had already made a simple proposal that makes all that possible (and easily doable!), and certain hosts will not be unfriendly to our current size: Sourceforge give us "no-limit" permissions, and GitLab limit is at 5GB.

Best Regards
IHCOL

[Thorsten]

I won't respond to you much in terms of arguments (which have been exchanged on the mailing list already) but just correct a few statements which I think are grossly misleading.

The aircraft had been versioned OUT to a Subversion repository hold in sourceforge, called FGADDON. Changes occuring in that SVN repository where never rebased on the FGDATA, meaning that for the aircrafts, these had been out of sync for at least 6 months.

The move was widely announced, and judging from the commit histories, aircraft contributors were aware of it - I haven't seen anyone try to push aircraft updates to FGData GIT except for base package. Of all GIT users, you are the only one known to me who managed to miss the migration.

The decision to split aircraft from FGData is in fact even older.

Apparently no-one else but me really care to understand the fact that we are LARGELY limiting our abilities to easily contribute to the aircraft base

In fact frequently the opposite argument has been made that SVN is far easier for the average user to comprehend than the intricacies of GIT merging and rebasing, and that by using SVN we would in fact not limit but enhance the ease of contributing. So people do care (and you know this, because you have been told) - they just happen to draw different conclusions from the same facts.

And thus no location will really be hosting the most complete and up to date FG_ROOT that one could use.

Which, as has been argued, is a virtue rather than a problem, because update cycles for different parts of the repo are very different, and the large size of an all-in-one repository has prevented people from cloning it and has created lots of problems.

Binary assets all being transferred to multiple SVN repositories (not good for aircraft and not good for much anything else, for that matters), and then a lot of configuration files being move to "flightgear" repository: where the compilable code resides.

That's an accurate summary of the initial proposal, but not of the agreed-upon path after we had a discussion.

[Hooray]

to be completely fair, there are major merits to using a decentralized RCS/SCM system like (git, hg, bzr): FlightGear ended up moving away from CVS mainly because the central server (its disk) got corrupted back then - so it was a move out of necessity. Equally, we are now having to move away from gitorious as per: https://about.gitlab.com/2015/03/03/git ... gitorious/

It is because of the fact that we're using a distributed system -namely, git- that this is a no-brainer in comparison to moving away from CVS or SVN, because everybody keeps a copy of the whole repository. So there is no single point of failure. Once people start using a centralized system like subversion again, there will be a single point of failure again - and the corresponding repository will be in the hands of whoever donates hosting/bandwidth, as long as the project doesn't pay for its own hosting.

And even with paid subversion hosting, we'd be worse off than with free git hosting, due to the SPOF.

Personally, I don't care at all - I am familiar with source code management, and I won't be affected by it, even if people decided to use 10+ different systems ...
But redundancy will be sacrificed by using a centralized SCM like svn again, which was the whole reason why Tim Moore and others pushed for moving to git:

http://sourceforge.net/p/flightgear/mai ... /23489767/

The advantages of distributed version control systems over centeralized
ones like SVN are numerous, and I won't hash them out here unless it
becomes necessary code.google.com does support Mercurial (also known
as Hg), and I would urge you to consider that as a target instead of SVN.
That said, I have not used Hg; from what I have read, git's support for
branching, merging, and preserving the history of merges is stronger.
These features were very useful in creating the 1.9.1 maintenance release,
where new development was able to continue on a mainline branch and specific
fixes could be pulled into the maint branch, or made on the maint branch
and merged to the mainline.

But you should remember that the fg developer expertise lies very much
with git. If you're willing to consider other hosting sites than google,
savannah.org and github.com are worth checking out; we might be able
to get opendesktop.org to host us as well.

http://sourceforge.net/p/flightgear/mai ... /25312355/

And a huge thanks to Tim and Martin for doing the work to make this possible.
And another thanks to whoever poured coffee into the CVS server

[IAHM-COL]

That's an accurate summary of the initial proposal, but not of the agreed-upon path after we had a discussion.

Thank s for your response Thorsten.

Can someone actually summarize the agreed-upon path?
Cause I really don't know of that.

All I know it has been agreed upon is that James proposal will work and its supported.
I just don't know if there is a new proposal and if so how it does differ from James' "original"

Best
IHCOL

[IAHM-COL]

That's an accurate summary of the initial proposal, but not of the agreed-upon path after we had a discussion.

Sorry to insist, but was this an open discussion? or some sort of higher class meet and call-it a final?
I.E: Was the final "agreed-upon" path openly presented, discussed, and convened upon on the devel-list? I may have just missed just a chunk of communications.

[IAHM-COL]

I couldn't agree more with you Hooray

It kind of saddens me that there is a group of people inside FG devel-system that will deffend the aircraft move to SVN out of any possible argumentation!

Oh-well

On the other hand, If its true that they are planning to keep a simplified FGDATA in git, just without aircraft, a fork can be done, and aircraft can be appended as modules. It is a "no brainer".

[Hooray]

it's a matter of improving accessibility for those actual doing aircraft development, which are rarely, if ever, people with a background in programming or source code management.
Some of our most talented aircraft developers belong to a group of people who regularly screw up with git basics, i.e. making errors when committing stuff - unnecessarily convoluting/breaking the history for others, more familiar with SCMs.
I have personally "mentored" a number of contributors to become familiar with git - and it took even exceptionally clever folks like Thorsten quite a bit of tinkering until they felt comfortable using gitorious/git, and until they saw the merits of doing so.

Also, the "group of people" you're referring to above is basically the "core" of active core developers - and those who are known for being consistent and persistent in what they do, much more so than many others.

I believe, it is a good thing for fgdata, and more generally, FlightGear, to become increasingly modular - which includes the base package, but also the core itself.

While I am personally not convinced that moving back to a centralized system is a particularly smart choice, I can see the merits of having free infrastructure/hosting (provided by SF), without the project having to bother with maintaining such things - just look at other FG infrastructure like the website, forum or the wiki: while the people behind each of those regularly state that they have a professional background administrating such resources, it is simply a fact that maintenance is a bottleneck - as could be seen by the increasing number of outages, sometimes even including data loss.

Thus, maintaining also our own SCM infrastructure would not be such a good idea - as could be seen by what happened to the CVS server a few years ago.
The forum, and the wiki, are obviously great - but they're already "SPOFs" - and it is outside our control to ensure that data/databases are regularly backed up and that software (wikimedia/phpBB) is regularly updated.

FlightGear is a volunteer-based project, and unfortunately, even good ideas take often many months/years to be recognized as such and implemented - while you may disagree with some of the more senior contributors like Torsten or James now - they, also, once were pretty much in your position and urged "others" (mainly Curt) to implement certain changes. Which goes to show that being persistent can pay off, over time ... however, truth being spoken, most people simply don't have the time to stay around for almost a decade until they've proven that they can be just as reliable.

Which is why I'd suggest to just watch the process unfold - those people involved in this now, have a long-time track record of contributing to various key parts of the project, and they may even still be around when we have moved onto other projects/interests.

You should however keep in mind that it is this tiny core of handful of people that are actually running the project meanwhile, because they manage to shoulder having families, jobs and other obligations - while also being very involved in FG matters. Speaking from experience, most people showing up here, just have a temporary interest in FG - and even my own interest would have been temporary, if I hadn't used it professionally/at work.

So there's something to be said about being persistent and consistent, and it makes absolutely sense to let those people handle the decision-makingg and the corresponding responsibilities.
If in doubt, I'd suggest to check back with this introduction about how the project happens to "just work", despite lacking any formal organization/leadership: http://wiki.flightgear.org/How_the_Flig ... ject_works