Board index FlightGear Support 3rd Party Repositories

FGMembers Suggestion

FGMembers Suggestion

Postby themadgreek » Sat May 09, 2015 11:15 pm

Currently, anyone who is a part of the FGMembers organization on Github (all developers using FGMembers for their planes) has full permissions for all planes.

This allows them to make any changes they wish without consulting the original developer.

My suggestions is not to institute a set of rules or even technical restrictions, but instead a simple convention:

If you're going to change another developers repository, do not push the code directly to the branch, but instead, make a pull request

The developer (since they have a deeper understanding of that repository) can then check whether that code is going to affect it in a way the contributor may not know, perhaps even breaking something.
If they see nothing wrong with the contribution, with one click they can accept the pull request on github.

For example, Israel converted someone's stereo sound files to mono, without consulting him with before doing so. However, while, not directly applied to the plane, that person was using those stereo files to generate the mono files that are applied in the planes.
If he had made a pull request for the change instead, he could have declined it before the code, since he still required those files.

While this is a relatively harmless example, the same thing could happen with file changes that could cripple a plane. It's valuable to have the people who are most familiar with the repositories "proof read" the code changes to that plane, before it's pushed live where everyone pulls from.

What do you guys think?
themadgreek
 
Posts: 156
Joined: Sun Jun 23, 2013 4:43 am
Callsign: MD-GRK

Re: FGMembers Suggestion

Postby KL-666 » Sun May 10, 2015 2:48 am

The way i had envisioned it, everyone would have write rights only on their own branch. So the "owner" chooses what to merge in the "main" branch. On the other hand others can elaborate on their own branch and subbranches, completely separate of the "main" branch.

Never had i expected that a super user would misuse his power to write immediately in any persons branch. In this case in the "main" branch.

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

Re: FGMembers Suggestion

Postby wkitty42 » Sun May 10, 2015 3:32 am

it is one repo... not a bunch of repos... i'm not aware of git being able to assign certain rights to certain accounts based on branch or module... but then, the maintainer acknowledges in numerous posts that they are a newbie at git and repos in general...

there is no insult intended to anyone at all! this is nothing more than an observation...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: FGMembers Suggestion

Postby KL-666 » Sun May 10, 2015 3:41 am

Separation of rights is doable with hooks, or whatever they call it. Also git cloud providers offer such functionality. The only question is: Does Github?

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

Re: FGMembers Suggestion

Postby IAHM-COL » Sun May 10, 2015 4:37 am

The way we actually organize things is called Teams.

I havent been very vocal about the Teams thing because we were a very small house, but we are now growing into the size that it makes greater sense.

What is a "Team"?
FGMEMBERS is an organization. A team is like a "suborganization"

A team contains a sub-group of FGMEMBERS, and a subgroup of the repositories with configurable set- of permissions (Admin, write or read)

I created several of the teams already and began populating them.

The FGAircraftDevelopers Team
This is the current "default" FGMEMBERs team. It contains all the people suscribed, and also all the repos. Also every person has written access: Thus the system so far does not have granularity of writting permissions (as of yet)

The Other teams

the other teams contains selected repositories and selected people assigned.

On the screenshot below I blanked out the members's names and pictures to respect privacy on all of our members that keep their affilliation as private
Image
Image

As you can see, some of our teams, such as Helijah contain about 268 repos, while others contain a few 3 or 4 repos to the most. And some contain only 2 people assigned (FGDATA is the current only management account : think of a "linux root") and 1 more member, while other teams contain several members in the team area.

Every team that I had set has "writte" permissions over the repos added there

Wait a minute? but people don't need double permission to write a repo?!

Yup. That's true. But at any time I could remove any repo from the "AircraftDevelopers" team. So the General Team looses the "writte permission" over the repo, while the "specific team" maintains the "write permission". that way any repo can be controlled specifically who writes over it and who does not, directly.

Immediate write access is a better and more direct way to collaborate over a repo. But sometimes you want to control more finely who is currently writting, and that's the way I currently set up.

Anyone (within or outside) FGMEMBERs can send pull request to any of our repositories.
Only thing needed is a github account.

Can you give writting permissions over only a branch

Not that I know of.
Pre-hooks are in my opinion an innapropriate solution to the problem. Everyone can fork a repo and gain full writing access to his/her own version of the aircraft.

Branches over FGMEMBERS had, sometimes, as an objective, to allow that "new voice" to have an space of expression. And in general we expect people to respect writing to his own branch and respect the work of others. That means, not writing directly over other person branch, but sending a pull request. We all make mistakes here and there, but we start learning the ropes of cooperating and "space of others"

So far I have not got a critical case where someone insists in violating a boundary. Yet, we admit with only 20 subscribed members we are still young and small. But we expect keep growing with no cap -- and with the expansion we may need to limit certain repos from global write access (meaning dropping them from the "general" team


Very few repositories currently have an official FGMEMBER maintainer


Meaning that
1) everyone could take ownership of that master branch (temporarily -- while intent to develop such aircraft is maintained)... but released to other interested party to continue develop when done
2) There is not, as Phil suggests, an owner of the master branch is most cases.
3) ownership, or such, over the master branch does not guarantee that others pull request over that one, and even write directly. If some one needs greater control, they should FORK into their own zone, and continue by sending pull requests.

I hope it clarifies, but please let's continue this very interesting topic

Best,
IH-COL
Last edited by IAHM-COL on Sun May 10, 2015 6:57 am, edited 2 times in total.
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: 4057
Joined: Wed Aug 08, 2012 6:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: FGMembers Suggestion

Postby IAHM-COL » Sun May 10, 2015 4:54 am

themadgreek wrote in Sat May 09, 2015 11:15 pm:This allows them to make any changes they wish without consulting the original developer.


Original developer?

Many "original developers" are not with FGMEMBERS. They keep their repositories elsewhere. Exceptions:: see above.
FGMEMBERS repo is an independent development repository looking for encouraging and fostering cooperation.
No one within FGMEMBERs should be afraid of commiting interesting features to our aircrafts FGMEMBER repo, directly, but should act with greater caution over a "topic" branch. That assigned to another collaborator isolated.

Pull requests are indeed a convenient and encouraged method, because it allows every independent developer to have a "private" fork of the plane they are working on. The only difference being, a FGMEMBER can merge the pull request automatically, while anyone else needs a FGMEMBER to approve the merge for them

Our current "policy" if it fits the word policy here --as you mention before the word is double-edged -- our current policy is: if the commit is valuable we just allow it in. Period. Every voice is accepted.

My suggestions is not to institute a set of rules or even technical restrictions, but instead a simple convention:

If you're going to change another developers repository, do not push the code directly to the branch, but instead, make a pull request


That's the critical part. Most of our repositories belong to really no-one. There is not a "assigned" maintainer. Think of them as communal property, not as "a given developers" vision.

For those cases that we have "a given developer" vision. We create a "branch" to isolate such developer in his own area.
One that in spite of not being "critically protected", I O.K. a person to restrict content. Given that a "master" branch remains that is open to the community, to develop as they please.
Any aircraft can have as many branches as we get to need.

The developer (since they have a deeper understanding of that repository) can then check whether that code is going to affect it in a way the contributor may not know, perhaps even breaking something.
If they see nothing wrong with the contribution, with one click they can accept the pull request on github.


That is where you and I don't agree.
A developer has his own branch/fork/and github zone. And it is ok for him/her to restrict commits to that particular branch/fork/zone. And in his zone, deciding the group of collaborators is very simple do.

If necessary, that topic branch is created for such maintainer. but the aircraft keeps a branch open to the community in general, where anyone can feel free to cooperate into

FGMEMBERS is not about looking a "protected area" for each developer. They can actually fork and develop in their individual area, and make their protected castle by this simple means.
FGMEMBERS is about encouraging Communal development on the aircrafts. Real OpenSource software / aircraft development.

For example, Israel converted someone's stereo sound files to mono, without consulting him with before doing so. However, while, not directly applied to the plane, that person was using those stereo files to generate the mono files that are applied in the planes.
If he had made a pull request for the change instead, he could have declined it before the code, since he still required those files.

While this is a relatively harmless example, the same thing could happen with file changes that could cripple a plane. It's valuable to have the people who are most familiar with the repositories "proof read" the code changes to that plane, before it's pushed live where everyone pulls from.

What do you guys think?


I converted everyone's stereo to mono. And copy that to the "community" branches. I rarely transfer that also to topic branches, but I did with a few people that I thought they may be accepting of the change. As an example JWocky and HerbyW.

In the particular case you mention that person rejected the change. And the problem was that given I was a "collaborator" in his own repo/fork
(in his github zone)
I thought he cleared me for doing this type of modifications on his repo (on his fork on his own zone). [it does not make me a super-user]
He already clarify he does not want that situation. And I am fine with that. I will change it over FGMEMBERs only.
And keep a separate branch for his "vission" whatever that is. --also I sent a message to that person into how he can remove any collaborator from his fork --including me if he is deeming that appropriate. He is very protective of his turf. But his personal set of forks, are indeed his turf and I respect that. Currently, I being a Collaborator on his fork is just a coincidence. I thought of it as an invitation to cooperate, and I already apologized for that.

The FGDATA next will follow the "community branch" which can pull from his vision, but it does not need to be exactly what he got in his zone.
Last edited by IAHM-COL on Sun May 10, 2015 7:05 am, edited 7 times in total.
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: 4057
Joined: Wed Aug 08, 2012 6:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: FGMembers Suggestion

Postby IAHM-COL » Sun May 10, 2015 5:04 am

KL-666 wrote in Sun May 10, 2015 2:48 am:The way i had envisioned it, everyone would have write rights only on their own branch. So the "owner" chooses what to merge in the "main" branch. On the other hand others can elaborate on their own branch and subbranches, completely separate of the "main" branch.

Never had i expected that a super user would misuse his power to write immediately in any persons branch. In this case in the "main" branch.

Kind regards, Vincent



That's quite correct Vincent. But the users will separate their own development on a fork on their own zone.
Collaborators on that fork (who writes and who can't write) in every one's for is configurable privately

When different vissions appear. IE, a collaborator insists that commits coming into the main FGMEMBER's master branch is undesirable, we don't question that.
The commit still comes into the master branch, and the "collaborators" work is separated into a branch that follows the alternative development.

Everyone else, can still commit into FGMEMBERS master, even if someone is actively maintiaining a separated branch (which he/she can protect from changes on the master all he/she want, and can decide cherrypick or copy any commit coming into the master as well)

For the particular case that Phil mentioned above, I happen to be an authorized writting collaborator to those repos, in the non-FGMEMBER zone.
I wrote this person an email indicating how to modify the list of collaborators, including, if he deems important, removing me from the list.

There are not "superusers" in FGMEMBERS
All are simply "MEMBERS" with the same priviledge of writing in every repo we have.
Last edited by IAHM-COL on Sun May 10, 2015 6:51 am, edited 2 times in total.
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: 4057
Joined: Wed Aug 08, 2012 6:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: FGMembers Suggestion

Postby IAHM-COL » Sun May 10, 2015 5:18 am

wkitty42 wrote in Sun May 10, 2015 3:32 am:it is one repo... not a bunch of repos... i'm not aware of git being able to assign certain rights to certain accounts based on branch or module... but then, the maintainer acknowledges in numerous posts that they are a newbie at git and repos in general...

there is no insult intended to anyone at all! this is nothing more than an observation...



Very accute observation. But
What is the observation again? Cause it completely went above my head!


This is how it works.
With an example

JWocky.
He has several repos of his own he maintains.
See the list here
https://github.com/JWocky?tab=repositories

Now let me show you an example:

https://github.com/JWocky/Condor-Jsb

Here, this is the Condor by JWocky. His repo. His "fork", or branch.
Who writes there is TOTALLY under control of Jwocky, And what gets written there is also 100% under his control.
I happen to be a written permission collaborator of his, but that is just circumstantial.

Now. The FGMEMBERS repo. Or fork.
https://github.com/FGMEMBERS/Condor-Jsb

This is a "different" repository.
Indeed "it is a bunch of repos". Not 1 repo.
And each repo has different permissions and different collaborators set.

on FGMEMBERs Condor repo, anyone that is an FGMEMBER already have write permission, and they are encouraged to cooperate and modify it.
This will not have direct impact on Jwocky's repo. and it is Jwocky or his collaborators, who decide what gets transferred to his repo, and what is not.

Anyone can fork either of these repos and send pull requests.

FGMEMBERs repo, happens to be the most promiscous one. Unless, it is clearly a mistake, all commits, and pull requests are highly likely to be accepted.

JWOckys repo is his own house, and the decision of what goes there belong to him. The decision of What goes into FGMEMBERs does not.

Now. On the assumption that JWOCKY considers that the FGMEMBER repo goes in a direction he does not like, and thus he is not merging "upstream", then that is when the FGMEMBERs creates a "topic" branch to follow his version . That is, we will synchronize his topic branch with whatever he does in his "fork" or repo.
But the FGMEMBER repo will begin to have additional branches that differ from that "topic" branch. And that's all


Now, if I reread your message it sounds to me you are all (Israel's English problem _ it should read: completely) mistaken with one exception:
I am not an expert in git.

Take your only point. Which is a bit insulting. But, a true fact.
Last edited by IAHM-COL on Sun May 10, 2015 4:07 pm, edited 1 time in total.
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: 4057
Joined: Wed Aug 08, 2012 6:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: FGMembers Suggestion

Postby KL-666 » Sun May 10, 2015 2:07 pm

Hi IAHM-COL,

First of all it looks like you take discussion as a means to viciously destroy you or your ideas. That is not what discussion is about. It is about transferring thoughts from one person to the other. i.e. I said what i thought how you would set it up, so you know which parts in my thought about your plan you have to set right. And you did. But it is a bit awkward to end with saying that we are all mistaken. Being mistaken or cross checking if one is mistaken about someone elses thoughts is exactly that what discussing a subject is for.

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
KL-666
 
Posts: 781
Joined: Sat Jan 19, 2013 2:32 pm

Re: FGMembers Suggestion

Postby IAHM-COL » Sun May 10, 2015 3:17 pm

KL-666 wrote in Sun May 10, 2015 2:07 pm:t we are all mistaken. Being mistaken or cross checking if one is mistaken about someone elses thoughts is exactly that what discussing a subject is for.

Oh no. not you (plural). Wkitty (singular) is all mistaken! he says is only 1 repo! and , that it is his participation in this important discussion, of course, that I am not a git expert.

So 1) fully incorrect statement -- FGMEMBERS is not 1 repo. Not even one repo only for many of our aircrafts. Totally oppose to what he thinks, we are indeed a bunch of repos. And permissions and collaborators, and such can be assigned to each repo differently.

and 2) His unnecessary qualification of my skill. --which is the only true stamentent in his two liner. And what I feel he really wanted to say. He just gave me a C-. But is he my teacher? and is he here to give me a grade? (he surely thinks so!)

So I dont get what his point is at all.

I tried to take care to quote him on that reply as to make sure, the message went direct to the correct person. Please don't assign it to yourself, because you had raised very important points.
Last edited by IAHM-COL on Sun May 10, 2015 4:06 pm, edited 2 times in total.
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: 4057
Joined: Wed Aug 08, 2012 6:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: FGMembers Suggestion

Postby IAHM-COL » Sun May 10, 2015 3:52 pm

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/extra500
You 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/members
https://github.com/FGMEMBERS/CRJ700-fam ... rk/members
https://github.com/FGMEMBERS/dhc6/network/members
https://github.com/FGMEMBERS/MD-10/network

6. 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
User avatar
IAHM-COL
Retired
 
Posts: 4057
Joined: Wed Aug 08, 2012 6:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: FGMembers Suggestion

Postby wkitty42 » Sun May 10, 2015 5:00 pm

IAHM-COL wrote in Sun May 10, 2015 3:17 pm:and 2) His unnecessary qualification of my skill. --which is the only true stamentent in his two liner. And what I feel he really wanted to say. He just gave me a C-. But is he my teacher? and is he here to give me a grade? (he surely thinks so!)

you definitely need to work on your reading comprehension, dude... YOU have stated that you are not a git expert several times over numerous posts...

EG:
IAHM-COL wrote in Sun May 10, 2015 7:48 am:Specially since you are a knowledgeful git user --which I am not


That is all i was saying... and it was all a huge joke, too!! but your comprehension, even with the specific statement that no insult was intended, failed... whatever... if you can't take a joke :roll:

but you do post as if you are the one who designed and created git... can you perform all the same tricks manually at the command line without github's hand holding? serious question! things like creating pull requests are easy to do from the command line but then where does it go? how do others see it and react to it... github and sf have these built in via their interface but how does it work without their interfaces...

submodels? never heard of them until i was reading your posts on the -devel list... in the projects i've worked on, no one has ever mentioned them... if we needed something from another project, that project was a completely separate installation and requirement to be satisfied when installing our project OR we included their code within our project and updated our copy of their code at certain specific points... this page doesn't say that submodules are a bunch of repos... it says that submodules allow you to keep another repo in a directory in your project and treat it separately from your project... so what you have is a project repo with directories containing other projects'... not a whole bunch of repos unless one paints the language with a wide and loose brush... but again, whatever :roll:
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: FGMembers Suggestion

Postby IAHM-COL » Sun May 10, 2015 5:27 pm

Yes. Wkitty.
I rarely get your sense of humor, at all.
Not here, neither when you told me about kissing your anatomy.
Sorry. Not a native english speaker here, so bare with me.
I like comedy, but I'm not good at it.

So. What is exactly your point about my git expertise? Have I lied saying that I am the all-knowing git master? Why do you say I act as if I had created git? no-sense! That was Linus Torvalds. I don't even read git's source code: I probably would understand more of "War and Peace" if I read it in original language on cyrillic characters. (which is close to nothing)

I do use the command line in my daily activities. And most stuff I do with git, I do on the shell. I am an ok linux user with more than 10 years of experience using bash. And I default to shell applications most of the time (example Terragear vs Terragear-GUI). There are 152 git commands. I use on a daily basis, maybe 15 of them. The others are totally obscure to me on what they do, and why they're there. So, an expert, not in this chair.

End user experience on SF and on github are totally different. And I think github is more amiable to regular -non-technical users than SF. That is one of the main reasons I decided hosting FGMEMBERS on github, instead of SF: Where FG lives. But on user interfaces, beauty is in the eye of the beholder.

About is only 1 repo.
I have no idea what you are talking about. Not when the context is git.
In git, everything is Just Another Repo. From the moment an user clones locally to his computer on. That moment there is no longer 1 repo. There are two, or even possibly 3 independent complete full fledged repos already. They can have or not the same content.
FGDATA next with submodules, you are more likely referring too, is just another FGDATA next repo, such as the one called "official". It just contains a few tenths of commits belonging solely to that particular branch (the commits that manage the submodules).

FGDATA next with submodules links 608 independent repositories: aircrafts. if 608 does not make "a bunch" for you. It certainly does to me.
And several of these 608 aircrafts have forks and independent development repositories elsewhere.
And the limit is the sky!

That is quite my definition of a bunch of repos.

Submodules always create a subdirectory that points to another repo. It works kinda like "nested" repositories. So a project like FGDATA next with submodules is no longer a repo, but a repo with lots of repos inside. Quite a lot of repos indeed.
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: 4057
Joined: Wed Aug 08, 2012 6:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: FGMembers Suggestion

Postby wkitty42 » Sun May 10, 2015 7:24 pm

IAHM-COL wrote in Sun May 10, 2015 5:27 pm:Yes. Wkitty.
I rarely get your sense of humor, at all.

i can see that... it is all ok, though... at least as long as you don't take things the wrong way and run off into left field with them ;) [baseball term]

IAHM-COL wrote in Sun May 10, 2015 5:27 pm:Not here, neither when you told me about kissing your anatomy.

that statement was made because i thought you were talking about me instead of another individual... let's not even go back to that conversation, ok? i was trying to express something and apparently was not very successful at it... we can just move on and forget about it...

IAHM-COL wrote in Sun May 10, 2015 5:27 pm:Sorry. Not a native english speaker here, so bare with me.

i started to ask you what your native language was so that perhaps i and others could try using something like google translate to express our thoughts but decided not to... the idea is still there and you can respond if you like...

IAHM-COL wrote in Sun May 10, 2015 5:27 pm:I like comedy, but I'm not good at it.

me either... and i have what some might call a weird sense of humor... "free association" is one factor... that's where someone says a word or phrase and you respond with the first thing that comes to mind... for reference on what it is/means, some psychologists/psychiatrists use this as a means of determining one's mental state... for me, free association can be quite funny if one can follow the twisted pathways of the mind that produced them...

eg: weather girl says "today is wednesday, right? hump day. there is no rain in sight so we should have a dry hump day." her male colleagues choke up trying not to laugh. why? look up the phrase "dry hump"... even though she didn't mean it that way, that's the portion of her statement that jumped out at folks...

IAHM-COL wrote in Sun May 10, 2015 5:27 pm:So. What is exactly your point about my git expertise?

there was no point... as i already wrote, there was no insult intended and it was a joke based on your own statements of not being a git expert...

IAHM-COL wrote in Sun May 10, 2015 5:27 pm:Have I lied saying that I am the all-knowing git master?

no, you have not lied but the way you write your posts related to git make it appear that you are a "git master"...

IAHM-COL wrote in Sun May 10, 2015 5:27 pm:Why do you say I act as if I had created git? no-sense!

see above... it makes perfect sense when viewed from this perspective...

IAHM-COL wrote in Sun May 10, 2015 5:27 pm:That was Linus Torvalds.

yes, i'm quite well aware of that as i'm sure most others are ;)

IAHM-COL wrote in Sun May 10, 2015 5:27 pm:I don't even read git's source code: I probably would understand more of "War and Peace" if I read it in original language on cyrillic characters. (which is close to nothing)

i hear that! i would probably be in the same boat with you there :lol:

IAHM-COL wrote in Sun May 10, 2015 5:27 pm:About is only 1 repo.
I have no idea what you are talking about. Not when the context is git.
In git, everything is Just Another Repo.

you are still missing what is being said... i'm trying to figure out how to explain it but you keep bringing up other stuff like clones and forks... those are not part and parcel of the specifics i'm trying to point out... i'm done, for now, trying to explain further... i might as well try to learn the glukgluk language and translate from there... the language barrier, slight or large as it might be, is just something i cannot cross right now :(
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: FGMembers Suggestion

Postby KL-666 » Mon May 11, 2015 1:13 pm

Hi IAHM-COL,

There are different development models, closed and open. You want to achieve an open model as opposed to closed where you have to get past a gate keeper for your commits. That is a good idea. But you forget that there are different open models that equally let all developers join in.

Open 1) where everyone can mess up any branch he likes
Open 2) where developers are protected against having their branch messed up

You chose Open 1), but the developers prefer Open 2). So there is a problem with getting developers involved now. I will show you that Open 2) is not less open than Open 1).

Say developer X works on the first branch of a repository, let's call it branch A. He is the only one that can write in that branch. Now developer Y comes along and wants to work on the same repository. X knows Y and trusts him not to mess up, so he gives Y write permission to branch A.

Now developer Z comes along, but X and Y do not know him or trust him, so he does not get write permission on branch A. Now Z can still develop in that repository. He makes a branch B of A and starts working. When Z is finished he tells X and Y about it so they can have a look. Different things can happen now:

1) X and Y say: great idea, we will merge it in branch A
1a) delete branch B and join in with us on branch A
1b) keep branch B because we are not yet sure about your capabilities

2) X and Y say: This is a really bad idea that breaks a lot of functionality.
2a) Z agrees and deletes his branch
2b) Z disagrees, and continues his own branch with his features. Either he likes changes on branch A and merges them in branch B, or he does not, and goes a complete separate way.

In case 2b) there are 2 branches with different features, and anyone can choose which one he wants to develop on, or download from. For branch A he will have to ask X or Y write permissions. For branch B he has to ask Z. If he does not get the write permissions, he will branch from ether A or B and do his thing anyway.

I hope you can see now that such a model is extremely open, but prevents messed up branches. This is what i think the developers want. Open 2) can probably be achieved in several ways, the branches method is just one example.

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

Next

Return to 3rd Party Repositories

Who is online

Users browsing this forum: No registered users and 1 guest