Board index Other Hangar talk

What is a fork (split from How the project works)

Talk about (almost) anything, as long as it is no serious FlightGear talk and does not fit in the other subforums.
Forum rules
Please refrain from discussing politics.

What is a fork (split from How the project works)

Postby D-ECHO » Tue Sep 06, 2016 5:21 pm

To clear this up about what is fgmembers (please, if I'm writing something wrong, correct me)
FGMembers is a fork of fgaddon, the official aircraft repository. Its advantage is that there are more aircraft, also aircraft under development, in it and some updated versions which have, for whatever reason, not been submitted to fgaddon. The disadvantage is that it's not officially maintained so it's not as well embedded in the flightgear software and there have been problems with copyright violations because many people have access to the repo.
Is this correct, anything I've forgotten?
[EDIT]Git brings also the disadvantage that the folder size is higher than by using svn and it takes longer (IIRC)
D-ECHO
 
Posts: 2460
Joined: Sat May 09, 2015 1:31 pm
Pronouns: Bea (she/her)
Version: next

Re: How the project works

Postby bugman » Tue Sep 06, 2016 11:15 pm

A normal fork is defined as contributing back to the project (the maintainers of the fork create merge requests, or equivalent, asking for certain changes to go back upstream). However FGMEMBERS is a hostile fork. To understand this, see https://forum.flightgear.org/viewtopic.php?f=85&t=29559&start=285#p285662, and the definition at https://news.ycombinator.com/item?id=5490456 and http://meatballwiki.org/wiki/HostileFork.

It is also not just an attempt to out do and provide "better" FGAddon aircraft than the original upstream source (by fixing small problems, announcing it, but not contributing it back with the excuse that the fix is there to be backported by those interested), but also all of the venerable 3rd party hangars, and individual aircraft. In quite a number of cases, this is against the wishes of the aircraft authors, who nowadays try to hide their aircraft prior to release or use strange licencing to avoid being pre-announced and distributed by the FGMEMBERS group. This sometimes results in lost advertising revenue, as the FlightGear user using FGMEMBERS will no longer need to visit the upstream website.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: How the project works

Postby curt » Tue Sep 06, 2016 11:59 pm

D-ECHO, I appreciate your attempt to ask fair questions in the midst of all this craziness. I don't know if you will be successful in moving nearer the truth, but I get the sense your intentions are honorable. Good luck! :-)

Typically the intent of someone creating a hostile fork is try to get everyone to use their new fork and abandon the mainline repository. This could evoke a defensive response from the original project and gives some context to jwocky's frequent mention of me "clinging to a dying dictatorship and dreaming of armies that don't exist" (which is also a WW-II nazi/hitler reference for those that missed it.). The strategy as Edward points out is to roll every possible aircraft source into the fgmembers fork to try to make it more attractive than the mainline. They are now doing this with scenery as well. In addition they make a directed effort to recruit new developers away from the mainline and contribute only to their fork. Again, for the purpose of obliterating the mainline repository in favor of their own work. The danger is they have often ignored and disrespected the original authors of the material or been sloppy with copyrighted material in their rush to be 'value added'. The second danger is that they fragment the community and waste resources when everyone would be better off pulling together and working in sync. There is no interest by the fgmembers founders in contributing back to the mainline repository because this dilutes their goal of replacing the mainline repository. Some aircraft authors choose to contribute their work in both places which is fine. I think most people want to do the right thing and are confused by the hostility and arguing. Several users choose to post in both forums which is usually fine (as long as they conduct themselves respectfully here.) However, a person only has to search their forum for my name or the names of other moderators and long time contributors to get a sense of the personal hostility that also exists towards us by many of the more prolific users over there. You can also see how that attitude is carried back here by certain users as they propagate endless arguments that do nothing to add information or ask fair questions in this forum.

So just to be clear "hostile fork" would not have to mean personally hostile, it technically just means a difference of opinion and parting of ways. However, because fgmembers only forked the aircraft and scenery portions of the project, they can't completely part ways. Because they created the fork as a result of significant drama and actual real personal hostility (I still have a few f-word laden messages in my archive that I haven't published to save people from being embarrassed even though they don't deserve that level of respect), this creates an uncomfortable situation and certain people don't deal with this friction very well.

Thus we have an uncomfortable situation.

I will also say that I do appreciate the efforts of those that have a foot in both worlds and are trying to be fair minded and reasonable. I can't tell you who to believe (well I could tell you, but you have to decide for yourself anyway) so my best advice is to continue to try to ask fair questions, strive to be wise, beware of political-style word warping tricks, and be aware and measure the things that are said with your own mind. I think there's always hope when people are willing to ask fair questions and consider the responses.

Best regards,

Curt.
Aerospace Engineering and Mechanics
University of Minnesota
curt
Administrator
 
Posts: 1168
Joined: Thu Jan 01, 1970 1:00 am
Location: Minneapolis, MN

Re: How the project works

Postby PINTO » Wed Sep 07, 2016 12:13 am

Just wanted to point something out...

bugman wrote in Tue Sep 06, 2016 11:15 pm:A normal fork is defined as contributing back to the project (the maintainers of the fork create merge requests, or equivalent, asking for certain changes to go back upstream).


That's not actually true. A fork is just a derivation of source code, no merging back necessary. Google can come up with more sources than I can list to support this.

In fact, almost every major fork in the opensource world would be considered "not-normal" by your definition. Almost every derivation of a *nix distro, *BSD, LibreOffice, Nethack, Apache HTTP servers, OpenSSH, Inkscape, WordPress, XOrg... the list goes on.
Actively developing the MiG-21bis (github repo) (forum thread) (dev discord) (fg wiki)

http://opredflag.com is an active flightgear dogfighting community (using a system that isn’t bombable)
User avatar
PINTO
 
Posts: 966
Joined: Wed Oct 21, 2015 7:28 pm
Callsign: pinto
Version: stable
OS: Win10

Re: How the project works

Postby curt » Wed Sep 07, 2016 1:46 am

To continue refining terminology, wikipedia says the following about "forks":

Distributed revision control (DVCS) tools have popularised a less emotive use of the term "fork", blurring the distinction with "branch".[15] With a DVCS such as Mercurial or Git, the normal way to contribute to a project is to first branch the repository, and later seek to have your changes integrated with the main repository. Sites such as GitHub, Bitbucket and Launchpad provide free DVCS hosting expressly supporting independent branches, such that the technical, social and financial barriers to forking a source code repository are massively reduced, and GitHub uses "fork" as its term for this method of contribution to a project.


I think originally, a "fork" was more as you suggest Pinto (a fork was inherently a parting of ways between two groups of developers.) I believe Edward was thinking about the newer "github" style of fork when he said "normal fork" (the meaning more blurred with a branch and more collaborative.) As we know, language and meaning is inexact and evolves, and often at a quite high rate in the tech world. Our use of the term "hostile fork" differentiates from a newer style collaborative fork combined with pull requests.

Best regards,

Curt.
Aerospace Engineering and Mechanics
University of Minnesota
curt
Administrator
 
Posts: 1168
Joined: Thu Jan 01, 1970 1:00 am
Location: Minneapolis, MN

Re: How the project works

Postby wlbragg » Wed Sep 07, 2016 6:13 am

bugman wrote in Tue Sep 06, 2016 11:15 pm: This sometimes results in lost advertising revenue, as the FlightGear user using FGMEMBERS will no longer need to visit the upstream website.

I have to say, I never really thought about that potential.

In the beginning I liked the concept of the "all in one location" that fgm tried to accomplish with aircraft. I didn't like having to search out all the different sources and wanted all aircraft available and in their most current state. That is a huge task.

As time marched on I discovered a couple things that made it less and less useful.

The first issue was my GUI shell just doesn't play nice with sub-module approach.

I don't like the free for all effect of branching any aircraft, even those that might have come from another source such as FGUK, or FGADDON, and making changes to them without insuring that they replace the original in the original repo. It is too confusing and not user friendly at all. Not to mention the disregard at best or disrespect at worst to the original repo owners. I find that I can't trust the work to be compatible with the original intent of the originator or with FG as a whole.

If FG did a really good job with their "other repo" list and made sure it was up to date and included as many third party repos as possible, it would basically accomplish the same thing.

I think a better approach for fgm would be to not branch "all" aircraft, but only those that are being modified. The rest of the collection should simply be a URL to the source code of the original. It would accomplish the same thing without disregarding or disrespecting the original authors. In fact it would be closer inline with the concepts of the internet site to site linking.

This should also include FGADDON, any aircraft in FGADDON that are still being updated and attended to on external repos should have a link to that repo. However it is somewhat different as the original or current maintainers of the FGADDON aircraft are mostly those external repo owners.

The negatives I point out with fgm may not seem like a big deal to some, but to me they are a deal breaker. It is too confusing, too risky that your not getting the original source but possibly some modified version that may or may not continue to be the intended quality or concepts of the original.

When I get the aircraft from the originating repo I know it is as intended. When I get the aircraft from FGADDON, I am confident it is with the approval of the originating repo.

I still maintain an fgm repo, mainly as a collectors tool, to help insure I have most or all the aircraft that are available, but unfortunately I haven't used any of them since its inception. What really is annoying to me is that I know there is a lot of work that has gone into some aircraft for events like USA Tour and other events. Also lots of work on individual aircraft that are mostly duplicates of FGADDON or other repos that is simply lost to me because I haven't followed all the work being done. It is too fragmented. While I don't doubt there may be ways to sort or look at the data of fgm, as a casual user of GIT I have no clue what that might be.

So in summary, for me fgm is a collectors tool that I practically never use with the hope that someday I may find something I need or want contained within the collection. It's day to day practical use for me has never materialized. My vision of what I thought it was and would do for me is far from the reality of what it has become.

EDIT:
Something else that made fgm appealing to me originally is I was opposed to splitting up aircraft from fgdata. I have done a complete reversal on that. I think it was a very smart thing to do. It makes perfect sense to me now. It was too much data mixed together and I like the separation. It just makes sense.

In fact I would like to see a method to allow for users to make their own catalog of any combination of aircraft from varying sources or from one giant repo. I think it would be so useful to have catalogs you could load like Boeing, Piper, Cessna or helos, tankers, airliners, twin engine, etc. You get the idea.
Last edited by wlbragg on Wed Sep 07, 2016 6:32 am, edited 1 time in total.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7588
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: How the project works

Postby Thorsten » Wed Sep 07, 2016 6:31 am

There's the small matter that GIT really sucks at dealing with binary files such as textures, models,...

Simple html download of the Space Shuttle: ~ 120 MB
Current SVN version of the Space Shuttle: ~ 406 MB
Current GIT devel repo of the Space Shuttle: ~ 2.6 GB

The stored GIT data after 1 1/2 years of development is a factor 20 more than the actual project data. Doesn't look like a particularly scalable or future-proof concept to me.

And now imagine the factor 20 on 90 GB of scenery data that gets edited over the course of a few years...
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: How the project works

Postby PINTO » Wed Sep 07, 2016 6:51 am

Code: Select all
$> git clone --depth 1 /*github-shuttle-repo*/
Cloning into 'SpaceShuttle'...
remote: Counting objects: 481, done.
remote: Compressing objects: 100% (421/421), done.
remote: Total 481 (delta 89), reused 314 (delta 59), pack-reused 0
Receiving objects: 100% (481/481), 195.38 MiB | 1012.00 KiB/s, done.
Resolving deltas: 100% (89/89), done.
Checking connectivity... done.
Checking out files: 100% (455/455), done.


Used FGM repo as I couldn't locate yours, Thorsten. But, using --depth 1 solves the size issue.

edit: also, just for reference, here's the entire output of git log:

Code: Select all
$> git log
commit 641938cf38e9676326cb3dee9002bfaf8cf74069
Author: Thorsten Renk <thorsten@science-and-fiction.org>
Date:   Sun Aug 14 18:07:12 2016 +0300

    Add p_meds_autonomous page nasal code
Actively developing the MiG-21bis (github repo) (forum thread) (dev discord) (fg wiki)

http://opredflag.com is an active flightgear dogfighting community (using a system that isn’t bombable)
User avatar
PINTO
 
Posts: 966
Joined: Wed Oct 21, 2015 7:28 pm
Callsign: pinto
Version: stable
OS: Win10

Re: How the project works

Postby Thorsten » Wed Sep 07, 2016 6:56 am

But, using --depth 1 solves the size issue.


Only for GIT power users, and certainly not for the hosting space provider or the project manager.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: How the project works

Postby PINTO » Wed Sep 07, 2016 6:58 am

Well, if it's automated via scripting, then it doesn't have to be just power users.

Like I said, it solves the problem.
Actively developing the MiG-21bis (github repo) (forum thread) (dev discord) (fg wiki)

http://opredflag.com is an active flightgear dogfighting community (using a system that isn’t bombable)
User avatar
PINTO
 
Posts: 966
Joined: Wed Oct 21, 2015 7:28 pm
Callsign: pinto
Version: stable
OS: Win10

Re: How the project works

Postby wlbragg » Wed Sep 07, 2016 7:01 am

The stored GIT data after 1 1/2 years of development is a factor 20 more than the actual project data.

Yes, then there is that also. That is incredible.

I guess as much as I am a hoarder, I really need to research a way to fetch only the final, current aircraft, and keep it locally. Leave the historical storage to GitHub.
But, using --depth 1 solves the size issue.

I can't even finish composing a post and someone is already answering my questions.

But it still leave me fragmented, I have fgaddon and various other collections straight from their sources and then all that fgm duplication mixed in with who know what. That is what I was getting at in my post, it no longer is useful to me in a practical way. Only for collection backup of sorts.

The one remaining benefit in that context, is I can do a pull and it is up to date with all the originals, except all the branching and not knowing what came from where and what is new, old or changed. It just doesn't work for me.

Maybe others that use it exclusively, or only pull certain aircraft, or follow all the work done in the entire collection, or aren't concerned that they may not be getting the intended original work or version still find it useful.

But if I were to try to design a similar concept today, I would do it completely different in many aspects as outlined above.

Anyway, just thought I would share my experience with the concept and my evolution of thought. There is no attempt here to sway people away from or denigrate fgm. I see room for improvement in the way we present aircraft data also, it's just not a priority for me.

I'm done here as this is really not on topic at all, so I apologize for the off topic posts.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7588
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: How the project works

Postby Thorsten » Wed Sep 07, 2016 7:05 am

Well, if it's automated via scripting, then it doesn't have to be just power users.


And if it's automated via http, then there's no history overhead whatsoever. GIT as distribution mode doesn't make much sense if you just want to use something in the first place.

Edit: See, I don't know whether this is wide-spread knowledge, but a project the size of FG can't just appear on a free hosting service and use the infrastructure. With your private project, you sure can, and if you have a few dozen users, nobody will ask much.

But if you come 'here I have 90 GB of scenery data, another 400 GB of history to it, and there's some 30.000 users who will pull that next - that's not the same thing. There's actually been negotiations with SourceForge before the scenery data was moved from google code, you just can't simply put it somewhere and expect it to stay. The amount of bandwidth you intend to consume matters - just as the amount of storage space matters. The hosting service also wants it to be scalable and future proof, not just the user.

Someone pays the bill for it, even if you don't see it.
Last edited by Thorsten on Wed Sep 07, 2016 7:18 am, edited 2 times in total.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: How the project works

Postby PINTO » Wed Sep 07, 2016 7:17 am

Dude, lol. Okay bro. There's no winning with you, I know.

You said "git size is large!" I said "no it doesn't have to be". You said "but that's for power users!" I ignored your obvious moving-the-goalposts, and responded. Then you move the goalposts again and say it's "not good just for normal people downloading."

I mean, come on.
Actively developing the MiG-21bis (github repo) (forum thread) (dev discord) (fg wiki)

http://opredflag.com is an active flightgear dogfighting community (using a system that isn’t bombable)
User avatar
PINTO
 
Posts: 966
Joined: Wed Oct 21, 2015 7:28 pm
Callsign: pinto
Version: stable
OS: Win10

Re: How the project works

Postby Thorsten » Wed Sep 07, 2016 7:28 am

I'm summarizing part of the arguments that drove the decision by the developers to use SVN on SourceForge to you - and yes, that goes beyond convenience for the normal user.

You said "git size is large!" I said "no it doesn't have to be".


I said GIT really sucks at dealing with binary files such as textures, models,... and yes, it has to be large for the service provider (and that's chiefly what I had in mind when making the statement), and it conceptually sucks. Your argument doesn't fundamentally change that - it mitigates the effect for an end user and partially reduces bandwidth, yes , but then again, http is the much better option for an end user.

Since you're apparently not interested in what I say, we can leave it here.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: How the project works

Postby D-ECHO » Wed Sep 07, 2016 8:21 am

Okay, about the hostile fork, we can change that. As far as I'm informed, the FGMEMBERS maintainers are willing to merge the contributions from git back to fgaddon, who has to be contacted to do so?
Thorsten, I think you are the one to contact about terrasync? For example the Japan terragit scenery is ready to be merged to terrasync.
D-ECHO
 
Posts: 2460
Joined: Sat May 09, 2015 1:31 pm
Pronouns: Bea (she/her)
Version: next

Next

Return to Hangar talk

Who is online

Users browsing this forum: No registered users and 5 guests