Responding to Wllbragg

[IAHM-COL]

If I learned anything from this entire debacle is that the differences between GIT and SVN for our purposes are trivial.

Which means. so far, you have learnt nothing
Which surprises me when you compare how you worked with a team on the c172p and how you are a lone-ranger on the J3Cub on subversion

But, D. Meggison will summarize the point for you, which prevails any technical issue (but originates on the technical difference of centralized vs distributed, and the difference on github to promote social coding)

https://sourceforge.net/p/flightgear/ma ... /35056119/

It took me a while to from what was different about GitHub, too—in 2011, I
was still dragging my feet, thinking the differences were just technical.
Actually, what happened around GitHub was a social transformation, a
complete flip in the management of FOSS projects.

A decade ago (whether using git, subversion, csv, or whatever), you'd
organise a FOSS project around a circle of trusted developers, all of whom
had commit access. Everyone else would have read-only access, but they
could send patches to the people who had commit access and gradually earn
their trust and admission into the circle.

Most projects now use the GitHub approach, where everyone works on his/her
own private fork of the repo. The fork is tied to the a branch of the
original, so they can keep the fork in sync by pulling. When they have
changes they want to contribute back, they click a button to create a pull
request, which goes to the repo owner, who can also merge it with a single
click (assuming the contributor has kept in sync with the original repo).
Often, there is only one person with commit access on the original repo
(maybe a couple of backups on a big project), and even that person often
does her/his own coding in a fork, and sends pull requests to the original
repo.

As a result, the fork and the pull request become so-called "social
objects," like tweets and pictures in Twitter. There's no longer a sharp
barrier between an inner circle with commit access and the rest of the
world with read-only access (though, obviously, the repo owner is more
likely to accept non-trivial pull requests from people s/he trusts). You're
likely to get pull requests from strangers all the time, and since GitHub
is so familiar to everyone (even Microsoft uses it), there's zero learning
curve—no one has to go, dead a project FAQ, and learn how to contribute.

Even though I had all this explained to me, it took about three years
before I really understood how much the FOSS world I'd known since the late
1980s had changed.


Cheers, David

Those differences, originating in what git proposed via forking and being decentralized, are fundamental to the progress of an opensource project. To encourage grow. To encourage testing. To encourage visibility.

It is not gratuitous that FGMEMBERS has more visibility than FGADDon. It is designed to be so. Contrastingly FGADDon is designed to be the obscure corner of the developer. The end-user is "supposed" to be using the "aircraft center" instead. Which incommunicates the developer and the user. Cuts the feedback. And cuts the possiblity to invite to collaborate.

All I have been doing in INVITING to collaborate

[IAHM-COL]

Same thing with the terraGit. In the short term were seeing some fixes and improvements. They all could have been implemented in FlightGear had the authors chose to put the effort forth to comply with reasonable requirement.

The requirements are not reasonable (the one listed above by Torsten). And they are not because no-one that I know of has any clue how to guarantee them. The tile boundaries is a problem inherent to terragear ws2.0. It's there to stay. His request of achieving efficient merging of multiple scenery sources without human interaction requires, probably complex scripting. We are here on the point were human eye is what's needed to spot the problems and solutions. That's why terraGIT is mostly a manual update. I do it with lots of scripts. But I follow the progress by hand.

If the requirements are reasonable, then I am just not capable to satisfy them. That's that.
And so far we keep waiting for "Neo" to come and unplug that matrix.

[IAHM-COL]

What of terraGit, is it time then for an evolution and complete re-clone?

Neither.
It is very simple'
Even now terraGIT is taking the updates of Models on terrasync on a monthly scheme.

When new terrain comes through, we just pull terrasync, merge in git, and push in git, thus terraGIT is updated.
It maybe a big update, but no more than that.

It is a very simple step, and as soon as WS3.0 comes along, one more later, terraGIT will provide it.

The layouts we are building are being pushed to the database, so we wont be loosing anything here.

[IAHM-COL]

There is one step left in FGMembers path that would complete that type of process, take the code and re-brand it.

Back to the beginning of this circle. The problem seems you have been believing Thorsten bullshit way too much

FGMEMBERS is not a fork o FlightGear

It is not convenient for me to fork the software itself. I prefer the core developers to make the software. I just use it. FG will move forward, and we just will make content to enjoy it, and FGMEMBERS will facilitate making it rapidly available, rapidly updateable, problems are detected fast, and fixed.

Why would I want to fork the software if Torsten and all the core developers work on that for free?

To me, they do a great work at it by the way. Flightgear is the only opensourced FlightSimulator, and on many fronts is rapidly gaining real elegance: much of that includes work of Thorsten on the advanced weather, ALS, and all this flash. It looks gorgeous. And I love it. So, as it is, I keep profiting from their work, and keep the idea of forking away "the source code" as a very far option.

[IAHM-COL]

To me, "FlightGear" should remain in the control of the founding members and those they trust to have like minds, or at least reasonable temperaments. They haven't done so bad so far. Is there room for improvement, sure and many people are working on it every day.

Certainly that control has not been shaking off the same old hands. When I offered FGMEMBERS as a replacement to FGADDon I never said give me your software, I said Take my contribution.

[IAHM-COL]

Open Source and Brand Name seems at odds, look at all the variations of Linux.

What makes Gimp stay Gimp and Linux diverge into many?

I disagree.

I am not informed of any alternative to replace Linux.
But let me explain:

Linux, is the name of the software that corresponds to a Kernel for an Operating System, tightly based on the UNIX/MINIX Kernels.
Was created by Linus Torvalds, and used the License GPL you are familiar, and smartly he allowed contributors (instead of rejecting them away) causing his tiny unassuming project to become in 1 decade as the most important operating system Kernel in existence (compared to Windows Kernel, The Macintosh, and the Unix themselves)

Linus has used to his gain thousands of contributors/users who expanded the package from working in a very limited original machine, to basically run in any hardware you want to throw it at. The kernel is modular, and allows adding more and more new hardware support.

Linux is only 1 piece of software. And you find it here:
https://github.com/torvalds/linux

And you are wrong saying there are many variants. On that is like FlightGear: it has no real competition.

GNU/Linux Operating systems are composed on that Kernel to run the hardware/software interface, and a collection of packages all of which are supposed to be GPL licensed. But what package you put on top of that Kernel depends dramatically on the applications the user needs. Almost every user means a different machine. Distros of GNU/LInux feature flavors for those distinct needs and likes, and on there the options and variabilities are huge. The collection is unfollowable.
But you seem to see that as a caveat. When really it is the biggest gain of the OpenSource community.

Windows and Macintosh Operating systems are monothematic. That's what you get. With GNU/Linux OS family you have a World of options. I like options.

[IAHM-COL]

Would FGRebranded be a birth or a fragmentation?

Yes. I don't know. I heard group of people talking about forking. Helijah among them. I wish them success. If the product is good, there will be another openSourced FlightSimulator to try out.

[IAHM-COL]

What is the goal of those in "control" of FGMembers, is it to be contributing members of the FlightGear community, or something else?
What if I want to change the Git distribution method to something else, would you hear and act on my voice? How would you decide? Who would control that decision?

It is, simply put, to contribute to the community.
But the community at large.

Really I made FGMEMBERS to be what I'd like FlightGear to have. A lively space where creativity and cooperation is encourage. That facilitates users access to the bleeding edge of Aircraft and Scenery development. That brings content creation for the simulator forward and beyond. That is open and readily update able. That users can send pull request, and thus my planes being modified and improved every day. Sometimes every hour.
That contains a comprehensive collection of material hosted in a more stable way than dropbox links in the forum that loose dateability, and become undownloadable. How much content had users put in the forum throught the years that never made it to the "core"? You don't know nor I do, but I guarantee you is huge. FGMEMBERS makes it easy to that content to have a wide audience.

Maybe even we are the 20,000.

I don't know. I use it. And it works great for me.
And since I know how good it is I dont shy to recommend it.

And I dont have FUD to tell people of how dangerous using FGMEMBERS is. (because it is not dangerous), or how FGMEMBERS will cause your contributions to be lost (cause you are just attempting at guessing a future). Dropboxes and mediafires: those are really the death of content.

Off course, if you have something better than Git, but that guarantees, as git does, a distributed development of content. That guarantees everyone is a commiter, (on their own fork), that facilitates communicating code changes, but better. If you can make a better tomorrow, it won't be me who will not be listening.

And I think everyone controls that decision. because at the end, is the users who choose. (not a core developer behind an unaccesible devel list)

[IAHM-COL]

https://forum.flightgear.org/viewtopic. ... 20#p285210

I am questioning terraGit (even though my first reaction was favorable and still could be) because it appears to be competing instead of complementing. At this point same thing with fgmembers.

viewtopic.php?f=32&t=520&p=8786#p8782

Back to the beginning of this circle. The problem seems you have been believing Thorsten bullshit way too much

FGMEMBERS does not compete with FlightGear, nor it does compete with FGADDon. FGMEMBERS-TerraGIT does not compete with terrasync.

Having a collection of aircraft repositories, and or a repository with a version of Scenery for FlightGear is not a competition.

1. The more and better content we develop, the more we promote flight-gear usage.
The content we make is useless without flightgear. as we are just "members" or "users" of that software. As we grow, more and more people learn the intricancies of development FOR flightgear.

2. The core developers had blocked contributions from our way.
That's sad for us. And it is a reality we have to live with. But one we can live with. It's GPL, which means they authorized us to make changes and to share them as well. But indeed, they don't need to take upon the improvements, and I have to live with that.
I already talked to you how Japan was denied terrasync update. And you saw the long devel list arguments trying for the core developers to adopt FGMEMBERS and take all the content under their wings. The answer was and remains NO.

3. I Invite people to collaborate, but I have never dissuade someone to also commit or submit packages to the core content. That idea that Curtis has been selling around that I am an adversary is cheap and makes no sense. Even yourself, wlbragg have commit access to FGMEMBERS as well as FGADDon. Have you ever heard me attempting to change your mind about committing in the core?
But I can start looking for quotes showing you the numerous times others have tell you or many other users to NOT use and not commit improvements to FGMEMBERS. I am not stooping that low. The user is free, in my opinion to cooperate wherever they want, or can. My inviation is totally open.

4. The offer to take FGMEMBERS content, and even the whole collection and make it "Official" remains open. If I would have access to the devel list, I'd probably still be sending long emails to those developers attempting at suggesting to adopt FGMEMBERS every turn that is an opportunity such as D. meggison bringing the github topic again, or Thorsten saying that migrating to github of gitlab is so hard, when the job is already done
So,. no. Not a competition.

5. I rebase all FGADDon content in FGMEMBERS with a biweekly cronjob. And I will be updating Terrasync in TerraGIT monthly. I wouldn't do that if it were a "competition" of who goes faster/farther. That'll be cheating. But since it is not a competition, I just value the great work done, and I'm happy to copy it.

So. Drop the competition non-sense. I urge you

[IAHM-COL]

but any models will be lost to a third party repo and not make it into the official scenery. Is that happening very often?

VERY often indeed.
Submitting models via the database requires you to make otherwise unnecessary steps (which are actually not optimizations)

And thus
this is what you get

https://github.com/FGMEMBERS-SCENERY/

Six pages containing repositories of scenery, most of which never made it to terrasync ( I call that a waste if no hosted otherwise). and there is more that I ve failed to collect.
So yest. It is extremely common that the effort and great work of others fails to pass the "you are my friend" test that is required to push via the database.

And on top of that, most interesting work such as Project 3000, automatic groundnets, and OSM, don't fit the tiny box the database is, and that work becomes impossible to push to terrasync.

Terragit solves that problem. BIG TIME

viewforum.php?f=51
viewtopic.php?f=51&t=519

Example. The content in KMEM exists in formats that wont be accepted. Such as osm, or jetways configs, or shared models that are of no use in terrasync (because the path does not exist)
Or the models are grouped in collectives, not building of their own. or the textures are shared between multiple objects, and not named per_object.
A series of rather non-smart requirements that exist. That at the end just block the content to be sent to terrasync and promoted

In the past these collections got lost in the forums. Now, at least, they'll have a common house where to look for them, and more importantly, with much less effort, can be globally packaged (terraGIT)

viewtopic.php?f=51&t=478