KL-666 wrote in Sun May 10, 2015 2:07 pm:Now that i understand better what you wanted to achieve, there are arising some concerns. You say that if the original developer wants to avoid sudden unexpected changes during his work, he should stay developing in his own fork in some obscure place on the internet. Then you say that others will happily work on fgmembers and endure unexpected changes during their work. I fear such thing will not be long endurable for them, and they will also start working on their own fork at some obscure place on the internet.
In that case everybody is working again at their own place, just as it was. The only difference would be that there is a fgmembers that nightly copies their work to a central place. But then i think a bunch of links to all the private workplaces would have sufficed too.
It is not a bad idea to rethink the authorization question, to make more people comfortable with working inside fgmembers.
Kind regards, Vincent
HI Vincent . Interesting points.
1. I actually had been suggesting several authors to not work in obscure parts of the internet. The totally opposing is true.
I try to make FGMEMBERs as a "mall" or a "market"
The "original developer" or "current maintainer" is better "integrated" to fgmembers. If the current maintainer has a fork of the FGEMEMBERs repo, that is all-toghether "non-obscure". You can find his fork directly, just by looking at the FGMEMBERs repository. And in 99% of the cases, the maintainer's fork will be the "master" branch --that is when he and all potential collaborators agree.
By working integrated within FG members, the original maintainer work remain with the same visibility as the FGMEMBERs repository, since there is linkage. And there is also git ways -diff- (and github ways -compare- ) to compare the "maintainers work" and any possible alternative branch, so the differences between versions is always transparent.
2. In a few, maybe several cases, I had not achieve the "original developer" or "the current maintainer" to develop with us. In a few cases they develop in FGAddon. But in other cases they actually had personally chosen working in independent work areas. Sometimes, when they choose github, I can fork from there (the GPL work), and we go back to square 1. But when they choose to work in other repo hosts, then I can't "fork" per se. Their development, therefore goes, as you say, to an obscure internet corner. And frequently it takes me hours of digging to find where these authors placed their repos. What I've done is clone, make a repo in github, and sit it downstream, fetching changes from them. This way I integrate other development occurring elsewhere into FGMEMBERs, and off course, I bring it to a place that most people could know to look for. --FGMEMBERS
A classical example. The extra 500.
Looking at the FGMEMBERS repo:
https://github.com/FGMEMBERS/extra500You will see this repo has no forks. But if you see the short description, I point people to the original groups repository.
FG Aircraft | extra500 (
https://gitlab.com/extra500/extra500)
As you can see, I actually did my bit to give their repository collection more light. as opposed to less light.
3. I completely agree with you that aircraft developers should try to avoid developing in obscure corners.
among FGMEMBERs intentions is to create a complete collection of GPL aircraft development repositories. Where many developers work together.
The idea was that the developers would do two things: 1) join and 2) fork their work (or get their repo forked--the direction matters very little), and as such, they will get their personal area, while having access to the communal area.
The developers will then develop in their "own areas" -- see our B727 dev. for an example, or Jwocky's or HerbyW's setup.
And then they will pull requests to FGMEMBERs repo for a wider distribution.
4. But FGMEMBER repo is not any "developer" repository. It is the collection of repos where others can collaborate. That is the exact reason why I did create it. And the exact reason why I insisted Aircraft should be developed in git, not in svn.
What I look for is an environment that facilitates, and if may, rewards cooperation in aircraft development. In this set up you can start having 5, 6 or even more people joining into suddenly being interested in a same aircraft. All of them forking from the same point makes them immediately vissible to each other. And people with similar interests going to the same project can start to cooperate on that project. That is what I encourage with my "all open FGMEMBER repo" policy.
Think of the c172p-detailed project. Or the 727 project.
5. BUT, some people is not interested, able, or yet know how to accept other collaborators to their turf. They kind of don't understand that each aircraft is an "open Source" project on its own. And as such other people (users/ developers) and very likely to look at their work from the inside/out. Testing profusely. Reading their codes. And having ideas of how it could/should change. They want an aircraft to be their ninth symphony. Their personal masterwork. And their attitudes toward incoming collaborators are a bit medieval.
In the first point. That is not a huge concern for FGMEMBERS. They can fork. Work on their protected castle. And submit pull requests. Their own repo can avoid merging downstream, and avoid getting other's commits. And it will have full visibility as a fork of the "community" repo in FGMEMBERS. If new commits start showing up, because someone makes changes to this "Beethoven's" work, then the FGMEMBER repo starts diverging from the particular separated author that is unwilling to join a mob.
What FGMEMBERs does is that we create a "branch" that means --this author's vision or version of the aircraft Z. That is where branches come with this new meaning. That branch can be kept as the place where that author copies to/from. and Where others are not so invited to modify.
Therefore that maintainers work is fully available. Not in the dark.
As a branch any one can check it out. And the fork is also transparently located in the github world
Example of forks:
https://github.com/FGMEMBERS/Antonov-An ... rk/membershttps://github.com/FGMEMBERS/CRJ700-fam ... rk/membershttps://github.com/FGMEMBERS/dhc6/network/membershttps://github.com/FGMEMBERS/MD-10/network6. The intent and reason why FGMEMBERs is created, and what I am trying to achieve, is that aircraft can be easily build and constructed with everyone. As community efforts.
I understand, since many people had told me so in many possible ways -- that is not what FG is used too.
FG is used to aircraft maintainers. People that hold 100% decision of how the aircraft is made and work.
In FGMEMBERs, each aircraft is more like an opensource opendevelopment project. Where a group of people interested in such plane revises and debugs such code. Many eyes. Many testers. Many coders. Many minds. This is what FGAddon cannot achieve. And that is the battle I had been giving from day 0 of this project.
I tried to invest my time to remove the "my aircraft idea" from at least some aircraft developers. And turn it into "our aircraft and our FG communal resource". everyone can fix. Debug. Test. create and fix issues. And move aircrafts forward (as in improve them).
And do it liberally, since forks for more protected development can and do exists.
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