Board index FlightGear The FlightGear project

FGAddon vs. FGMEMBERS, bus factors etc.

Questions about the FlightGear organisation, website, wiki etc.

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby Hooray » Sat May 02, 2015 2:37 pm

git submodule are great in theory - but they also have their shortcomings - deployment overhead and long-term maintenance being two of them. I think I actually posted links to articles covering other challenges. The other thing being that FG already is difficult to set up, i.e. especially for people wanting to set up a working build environment, i.e. coders wanting to get involved. The superbuild is supposed to make that easier (it using git submodules). Aircraft ended up in $FG_ROOT due to most of it pre-dating git by many years - cvs didn't support the notion of external sub-modules/repository, and just look the number of repositories and depedencies already needed to get everything to build FG from source.

And maintenance is a bit easier if everything is in a single repo, because people can just fix up things without having to be involved in dozens of repositories.
This isn't unlike the situation with the global property tree in FG actually: it's become a fairly messy place these days, lacking conventions and rules to establish best practices (naming conventions, suffix rules, units etc) - but it is/was so much easier that way than establishing rules and enforcing those.

Meanwhile, it would actually make sense to take a careful look at the property tree and the way aircraft developers are using it, and establish a set of best practices as well as mechanisms to help enforce those over time, because given the sheer complexity/size of the property tree (depending on the aircraft loaded/running), it's a massively complex data structure with tons of non-obvious data dependencies that should ideally be much better formalized, especially to help with the reset/re-init and save/load efforts.

The FlightGear property tree has become a fairly flexible "dump space" for tons of state variables, read/written by a bunch of subsystems, lacking any kind of explicit management - the aircraft repository kinda evolved like that, too - with tons of redundant data, code and structural helpers - with very little, if any, oversight to manage shared resources and extract common functionality.

A more modular repository will make this even more challenging, because development will become even more distributed than it is already.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11924
Joined: Tue Mar 25, 2008 8:40 am

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby KL-666 » Sat May 02, 2015 3:56 pm

Thank you for that insight Hooray. The problem seems to be a not correctly implemented one-way dependency of modules in relation to their parent modules.

In case of the properties it is not too hard to fix that. The problem is in modules *creating* properties. There a naming conflict with other modules may arise. Proper implementation should be to have a private tree in aircraft to create their own properties. Second best is to have a separate directory in the mega tree, for submodules (aircraft) to create their private properties. At no time it should be possible to create properties in areas of parent or peer modules. (read and probably even write is not against the one-way dependency principle).

As i described the programming world where i come from, there the current situation would be totally unacceptable. Either fix the one-way dependency immediately, or do not split off these modules at all.

Kind regards, Vincent
KL-666
 
Posts: 784
Joined: Sat Jan 19, 2013 1:32 pm

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby Hooray » Sat May 02, 2015 5:11 pm

properties are much harder to fix than you may think, because there are implicit dependencies in most aircraft/systems - so the situation isn't unlike dependencies among aircraft in a shared repository.

originally, what you describe kinda was the idea - as can be seen by the "FDM sub tree" in the main/global property tree: everything there is conceptually "owned" by the FDM subsystem, and given that it's using legacy property tying (tied properties), things are even "read-"only outside the FDM subsystem, i.e. the FDM subsystem running not just at frame-rate, will invalidate/overwrite any other state internally - with the /fdm tree basically just being a "read-only" mirror of internal FDM state, i.e. C++ pointers (references actually) mapped into the global tree.

This is in stark contrast to the absolute majority of property tree state which is in fact "owned" by the tree itself, and not any underlying subsystems.

At some point, this concept got violated, and wasn't adopted by other subsystems - which is how we ended up with a huge monolithic property tree, even though certain state could/should actually be read-only by other subsystems - this has also complicated other efforts, such as better multi-threading support - more recently, developers have been contemplating to phase out "tied properties" and introduce subsystem-specific property trees, that are either mirrored or "mounted" via the global property tree - with each subsystem having its own private tree, which may selectively expose certain properties, and may otherwise even be running in a worker thread (think once thread per subsystem):

http://wiki.flightgear.org/Howto:Use_Pr ... ee_Objects
http://wiki.flightgear.org/Property_threading
http://wiki.flightgear.org/Remote_Properties
http://wiki.flightgear.org/Distributed_ ... FlightGear

The main challenges are summarized at: http://wiki.flightgear.org/Recommended_ ... hancements

Fixing this is directly related to formalizing data dependencies among aircraft in a distributed repository, i.e. would -at this point- cause tons of work (and regressions!) with very little visible improvement at all, while causing a lot of havoc and maintenance challenges.

It isn't unlikely that this will be addressed over time - but the primary factor would be only having a single "official" aircraft in the fgdata repository (the c172p) which will probably increasingly become the reference implementation for "best practices" - so that people can refer to that for any breaking changes and upcoming standards.

However, tackling this would almost certainly cause quite some upstir and irritation among aircraft developers, as could be seen by other changes breaking aircraft (e.g. route manager improvements) and causing additional maintenance work.

To be honest, it would be easier to simply discontinue support for the old "free-style" system at some point and document a "structure" that needs to be adopted by aircraft supported by FlightGear - which is however unlikely to happen until some GUI-based front-end is provided that handles automated creation/maintenance of aircraft related files (think -set.xml).
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11924
Joined: Tue Mar 25, 2008 8:40 am

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby radi » Sun May 03, 2015 1:14 am

IAHM-COL wrote in Thu Apr 30, 2015 6:41 pm:I apologize to you but I revert my commit over deleting the Shuttle, and I revert my decision of not tracking its advance on the FGAddon as well.


You've just lost the last bit of respect that I had for your, Israel. Previously, you agreed on respecting a wish, although not legally obliged to. That showed some decency -- now you revert. A new low in the seven years I've been following the forums and devel list.
OSM buildings for LOWI, EDDC
Custom scenery for VHXX YMML
Edit .stg via the FG Object Placement Tool
radi
 
Posts: 645
Joined: Mon Aug 25, 2008 4:24 pm
Location: YMML, EDDC

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby Jabberwocky » Sun May 03, 2015 11:22 pm

Radi,

you try to get insulting because you ran out of technical arguments?
Jabberwocky
Retired
 
Posts: 1319
Joined: Sat Mar 22, 2014 7:36 pm
Callsign: JWOCKY
Version: 3.0.0
OS: Ubuntu 14.04

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby Hooray » Mon May 04, 2015 1:10 am

I don't agree with the previous comment, but fgmembers being an unpopular fork or not: back in the gitorious days ,most of us had clones of the whole project, and we would regularly commit stuff posted by others that seemed useful - I have never seen a single incident where this was controversial - and in fact, when I post code snippets, I consider this as a "handover" to the community - this may be a bit different with Thorsten's work, because he's still developing and maintaining this elsewhere (aka the official repository) - but I do know a number of contributors, including core developers, who have posted useful stuff that didn't make it back into sg/fg or fgdata at the time, and some of us simply took such stuff and "archived" it in some topic branch.

I do realize that the analogy isn't quite fitting - but back when artix and a few others started working on MapStructure stuff, we also disagreed with some changes, hoping to implement a different solution in fgdata master, but we weren't expecting that we could tell people what to do with our GPL'ed code, let alone asking them not to commit it to some topic branch.

I do agree that mutual respect is an important factor that's involved here - but otherwise, I find this surprisingly similar to former contributors asking for their GPL'ed work to be removed from the repositories due to some disagreement, which I find ridiculous in a GPL'ed project.

Frankly, if I were to take some OSM2City stuff I found on the devel list or forum and added that to a topic branch in a cloned repo, I definitely wouldn't expect its programmers to tell me whether to commit that code to a public mirror or not.

So may I suggest that this has more to do with fgmembers and the people involved here, than actually valid concerns revolving around the GPL and collaboration ?
I think some of us may have forgotten what all this is about, and fgmembers and the people behind it, may have managed to turn us into a piece of work as well (I do know that this applies to some postings I made recently in that context).

So maybe we should tread more carefully here ?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11924
Joined: Tue Mar 25, 2008 8:40 am

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby radi » Mon May 04, 2015 4:47 am

@Jabberwocky. I don't care for the technical details in the FGAddon vs FGMEMBERS discussion. In case you've missed it: my post is about mutual respect. Whatever technical details might be superior, if someone fails to stick to some minimum standards in terms of interaction, I'm done with that person.

@Hooray: Thorsten perhaps had good reasons for not having the Shuttle uploaded to a public repo. Israel asked for permission, Thorsten declined (implicity, but in a way which every adult should be able to understand), Israel went on anyway. Why ask if you won't respect the answer anyway? There's exactly one conclusion I draw form it: Israel doesn't care.
OSM buildings for LOWI, EDDC
Custom scenery for VHXX YMML
Edit .stg via the FG Object Placement Tool
radi
 
Posts: 645
Joined: Mon Aug 25, 2008 4:24 pm
Location: YMML, EDDC

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby Thorsten » Mon May 04, 2015 4:51 am

do agree that mutual respect is an important factor that's involved here - but otherwise, I find this surprisingly similar to former contributors asking for their GPL'ed work to be removed from the repositories due to some disagreement, which I find ridiculous in a GPL'ed project.


Case 1): I give you 100 $ and say 'here you are, enjoy it'. We work together for a while, then we disagree and I say 'Now gimme back my money.'

Case 2): You see my purse lying around and say 'Hey - there's a 100 $ in here.' I say: 'That's my purse, don't take it, I'm going to need that money for something else.' You take it anyway. A while later I say 'Now gimme back my money.'

Surprisingly similar? I don't think so. Who ever taught you moral philosophy?

So may I suggest that this has more to do with fgmembers and the people involved here, than actually valid concerns revolving around the GPL and collaboration ?


I think the GPL side has always been pointed out as fairly clear-cut - so naturally there are no concerns revolving around GPL. The concerns are all about undermining the basis for fruitful collaboration, which has nothing to do with GPL as such and lots to do with mutual respect.
Thorsten
 
Posts: 11720
Joined: Mon Nov 02, 2009 8:33 am

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby Hooray » Mon May 04, 2015 7:04 am

honestly, I am surprised seeing this line of reasoning coming from you - your #2 is a very weird analogy when it comes to your intellectual property that you are explicitly releasing under the terms of the GPL - whereas taking your money without your consent is obviously theft, even just "borrowing" it would not be okay without your permission, obviously.

Since you usually keep referring to how scientific projects and collaboration work, I would guess that this would be more akin to having a situation where you publish some "work-in-progress" state of your work into the public domain, and ask others not to use your data/formula or algorithms given its state - but obviously, you cannot prevent anybody from still using it - and in fact, others cannot prevent you from evaluating the state of their published works and determining the merits of using/not using it.

Just imagine for a second that someone would be reviewing some of your Nasal/GLSL code, which almost undoubtedly contains snippets and portions of code posted/used elsewhere, and that someone would ask you to rework some of your code, just because they deem the corresponding snippets unfit for use.

Seeing the money analogy in this context is not just surprising but also kinda disappointing, especially coming from you, and in conjunction with polemics on "moral philosophy".

If you are so concerned about applying such rules to your work and contributions, you are adding a shipload of implicit assumptions about your work whenever you are making a commit.

Either way, this doesn't affect me currently - but if these concerns are genuine, you may want to consider teaming up with Johan who was trying to document such implicit "communtiy rules" - but frankly, I would have expected in an open source project for contributors to tell which patches can be committed/shared in public repositories or not. And if you find my notion of "moral philosophy" so questionable, may I politely suggest to review/reconsider your own standards and rules without a focus on "fgmembers" ?

Like I said, I am not affected by this, I just find this ridiculous - especially your attempt to support your case with the money analogy, which is as far off as it can possibly be given the circumstances. Honestly, I am used to much better, more informed and smarter, arguments from you than what you're currently trying to pull off here.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11924
Joined: Tue Mar 25, 2008 8:40 am

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby Thorsten » Mon May 04, 2015 8:58 am

*sigh*

You managed to completely miss the point of the analogy, which is that it makes a big difference whether I change my intention (1) or I stay with my stated intention (2). Whether this is about money, intellectual property or dogs is simply irrelevant for the point.

Since you usually keep referring to how scientific projects and collaboration work, I would guess that this would be more akin to having a situation where you publish some "work-in-progress" state of your work into the public domain, and ask others not to use your data/formula or algorithms given its state - but obviously, you cannot prevent anybody from still using it - and in fact, others cannot prevent you from evaluating the state of their published works and determining the merits of using/not using it.


Since you like that, while it is legal to publish an idea someone else has had if you happened to learn of it, if you actually do it, your reputation in the scientific community will be gone for good. Science works very much on the basis of not publishing stuff someone else is working on, told you about and has asked you not to publish. By the standards of the scientific community, grabbing an idea and publishing against his expressedly stated intentions would be very much akin to theft.

Like I said, I am not affected by this, I just find this ridiculous - especially your attempt to support your case with the money analogy, which is as far off as it can possibly be given the circumstances. Honestly, I am used to much better, more informed and smarter, arguments from you than what you're currently trying to pull off here.


Just because you didn't get it doesn't mean it's ridiculous.

Just imagine for a second that someone would be reviewing some of your Nasal/GLSL code, which almost undoubtedly contains snippets and portions of code posted/used elsewhere, and that someone would ask you to rework some of your code, just because they deem the corresponding snippets unfit for use.


And the point of that is? I'm not trying to prevent anyone from working with my code. I don't want to be part of a parasitic repository which grabs content without consent and without anyone actually working on it just to have it, with the aim of 'threatening' FGAddon, and I didn't want to have unfinished code out fully in the open intitially.

Publishing under GPL isn't giving consent to every use case. FGMembers material could be used in a war propaganda game, that doesn't mean that Israel necessarily intends to support war propaganda.

Intention matters here.
Thorsten
 
Posts: 11720
Joined: Mon Nov 02, 2009 8:33 am

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby Hooray » Mon May 04, 2015 9:04 am

given the nature of binary data, and it being easy to duplicate, it is hard to establish any means for "returning" something - so if you disagree even just with a single conceivable use of "your data", you'd be much better off not sharing it in the first place.

Like I said previously, I am not affected by this, and if you asked me to remove some of your work from a public repository, I would comply with your request - but not based on the arguments we've been discussing here so far, and certainly not the "money analogy" above. And I would never *ever* expect anybody else to comply with any such requests should I make them in a GPL'ed project - if however, someone repeatedly refuses to comply with my request, I would obviously draw my own conclusions WRT to future collaboration.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11924
Joined: Tue Mar 25, 2008 8:40 am

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby Thorsten » Mon May 04, 2015 9:09 am

Like I said previously, I am not affected by this, and if you asked me to remove some of your work from a public repository, I would comply with your request - but not based on the arguments we've been discussing here so far, and certainly not the "money analogy" above.


I don't know whether you're deliberately misunderstand me or are out to throw smoke screens.

The 'money analogy' is in response to a specific point raised by you to the apparent similarity of withdrawing requests - where I argue it matters whether you withdraw something you have given freely before or something which has been taken over an objection.

It never is or was used as an argument to withdraw anything from a repository.

if however, someone repeatedly refuses to comply with my request, I would obviously draw my own conclusions WRT to future collaboration.


You'll find that very point in my words as 'undermining the basis for collaboration'.

Maybe you should read what I write in a bit more detail? :-)
Thorsten
 
Posts: 11720
Joined: Mon Nov 02, 2009 8:33 am

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby Hooray » Mon May 04, 2015 9:11 am

I guess this has more to do with the intricacies of written communication on a forum where certain things may get lost ... never mind, I'll stop wasting y/our time here, I think I made my point and you made your's - and neither of us being involved in fgmembers, I don't see any need to have even more misunderstandings between the two of us over this :D
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11924
Joined: Tue Mar 25, 2008 8:40 am

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby IAHM-COL » Wed May 06, 2015 9:42 pm

bugman wrote in Thu Apr 30, 2015 5:02 pm:In subversion you can branch everything - individual subdirectories or files included. Actually in this respect, subversion is far superior to git.


Dear Ed.
After I reviewed this a bit more deeply, I still feel the situation on a subversion repository is not that optimal when it comes to branches.
Again, subversion is a "foreign" language to me, but this is what I found:

http://svnbook.red-bean.com/en/1.6/svn.branchmerge.using.html wrote:The Key Concepts Behind Branching

You should remember two important lessons from this section. First, Subversion has no internal concept of a branch—it knows only how to make copies. When you copy a directory, the resultant directory is only a “branch” because you attach that meaning to it. You may think of the directory differently, or treat it differently, but to Subversion it's just an ordinary directory that happens to carry some extra historical information.

Second, because of this copy mechanism, Subversion's branches exist as normal filesystem directories in the repository. This is different from other version control systems, where branches are typically defined by adding extra-dimensional “labels” to collections of files. The location of your branch directory doesn't matter to Subversion. Most teams follow a convention of putting all branches into a /branches directory, but you're free to invent any policy you wish.


and furthermore

https://git.wiki.kernel.org/index.php/GitSvnComparison wrote:A summary of differences
  • Git is much faster than Subversion
  • Subversion allows you to check out just a subtree of a repository; Git requires you to clone the entire repository (including history) and create a working copy that mirrors at least a subset of the items under version control.
  • Git's repositories are much smaller than Subversions (for the Mozilla project, 30x smaller)
  • Git was designed to be fully distributed from the start, allowing each developer to have full local control
  • Git branches are simpler and less resource heavy than Subversion's
  • Git branches carry their entire history
  • Merging in Git does not require you to remember the revision you merged from (this benefit was obviated with the release of Subversion 1.5)
  • Git provides better auditing of branch and merge events
  • Git's repo file formats are simple, so repair is easy and corruption is rare.
  • Backing up Subversion repositories centrally is potentially simpler - since you can choose to distributed folders within a repo in git
  • Git repository clones act as full repository backups
  • Subversion's UI is more mature than Git's
  • Walking through versions is simpler in Subversion because it uses sequential revision numbers (1,2,3,..); Git uses unpredictable SHA-1 hashes. Walking backwards in Git is easy using the "^" syntax, but there is no easy way to walk forward.

***

Branch Handling

Branches in Git are a core concept used everyday by every user. In Subversion they are more cumbersome and often used sparingly.

The reason branches are so core in Git is every developer's working directory is itself a branch. Even if two developers are modifying two different unrelated files at the same time it's easy to view these two different working directories as different branches stemming from the same common base revision of the project.

Consequently Git:

Tracks the project revision the branch started from - this information is necessary to merge the branch back to trunk
Records branch merge events including:
author, time and date
branch and revision information
Changes made on the branch(es) remain attributed to the original authors and the original timestamps of those changes
What changes were made to complete the merge. These are attributed to the merging user
Why the merge was done (optional; can be supplied by the user).
Automatically starts the next merge at the last merge.
Knowing what revision was last merged is necessary in order to successfully merge the same branches together again in the future.

This is different to Subversion's handling of branches. As of Subversion 1.5:

Automatically tracks the project revision the branch started from.
Like Git, Subversion remembers where a branch originated.

It's impossible to see only merge related changes.
If the merging user had to modify 12 lines of code to complete the merge successfully you can't tell what those 12 lines were, or how those 12 lines differ from the versions on the branches being merged. 'I grant you this point - however, this can be overcome with standards'

In Subversion, branches and tags all are copies. Sometimes this is inconvenient, it is easy to check out the whole repository by mistake. Branch path and file path lie in same namespace but they have different semantics - this can be confusing.
If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall
User avatar
IAHM-COL
Retired
 
Posts: 4064
Joined: Wed Aug 08, 2012 5:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: FGAddon vs. FGMEMBERS, bus factors etc.

Postby bugman » Thu May 07, 2015 7:25 am

Hi Israel,

As you probably already know, I am the lead developer of the open source project relax. In the 15 year history of this project, I and the other developers have created to date 61 svn branches, and most of these have been merged back to the main development line (trunk). If you prefer a bit of simplicity in life, then there is a magical tool called svnmerge.py which can be used for very easy branch management (this makes life far, far simpler than with git). I now regularly use this, simply out of laziness.

The text you quote is an introduction to the branching concept in subversion. This concept is implemented very differently to the branches in cvs or git. As it says, you copy with 'svn cp' what you would like to make a branch of. As you can copy anything, you can branch anything. Then you simply merge back at a later point using 'svn merge' (or cheat using 'svnmerge.py'). Once you start using a subversion repository, you will quickly learn that because of this copy then merge back concept, that the linear svn repository history is far superior to git. This is one other well known area where svn is superior to git. And branches in Subversion are simpler to manage than branches in git, especially if you use tools for dummies such as svnmerge.py. Subversion is one tool of many, and it gets the job done efficiently, just like git.

Regards,

Edward
Last edited by bugman on Thu May 07, 2015 9:38 am, edited 1 time in total.
bugman
Moderator
 
Posts: 1797
Joined: Thu Mar 19, 2015 9:01 am
Version: next

PreviousNext

Return to The FlightGear project

Who is online

Users browsing this forum: No registered users and 3 guests