lastmin-II wrote:I believe that the result of the discussion in the original thread is positive, and there are a few constructive suggestions for you guys, in order to create the conditions for your repository to finally be compliant with upstream FlightGear standards, and with the established rules of free software in general:
1) form a group of trusted maintainers;
2) implement quality control;
3) implement serious GPL compatibility auditing.
I don't think there is such positive outcome. I saw Thorsten and Curtis complacent that you subdued or agreed (whatever that is). And the perpetuation of misconceptions about what FGMEMBERS is.
So, to clarify.
FGMEMBERS does not attempt to be compliant with "upstream" FlightGear standards. Basically because those are not about standards, but about power and control.
In addition, there is not such set of "rules of free software in general". Let's talk about it a little bit , but I recommend you read Raymond's "the cathedral and bazaar" for additional clarity on my perspectives.
1. A group of trusted maintainers.The word maintainer here, as it is pertinent to "FG rules" indicate that there is an "Aircraft Owner" who has somehow a final word about it. In the case of FGMEMBERS this does not make sense. We don't have aircraft owners per se, and any one in the group has access and liberty to modify (I read improve) any of the aircraft in the collection. We don't operate under "this is my aircraft" approach.
Nor we can. There are more than 850 aircraft total in the collection, and the philosophy of "maintainer" just really creates and split between maintained aircrafts and virtually orphan ones. The "maintained" are jealously protected by some 'dude' (see? control and power). The orphans are left unmodified for decades. Partly because no-one really knows at the end of the day if it is maintained or not; and thus whether it is safe to simply modify.
I had unvested the collection of "Maintainers" and I've killed the figure of Aircraft-king. It works great in my opinion. And it works best for a more consistent and unrestricted approach accross the board.
More importantly, it facilitates cooperative attitudes, rather than establish a pyramid of operations where rules drop down as a hammer. (or a cathedral according to Raymond).
Then it comes the problem of commit rights: which you briefly had mentioned as well.
Firstly, FGMEMBERS is distributable (or a decentralized system). The major consequence here is, that EVERYONE (read everyone in the world can commit) [WHAT!!! WHY!?? many ask horrified]
Well this is how it works with commit priviledges. There is the "fork" button in github, which creates a clone of any aircraft (or repository) in someone's sandbox. There is not restricting that person liberty to commit to his own fork, therefore, effectivey being a comitter.
Yo don't need to be able to commit directly to FGMEMBERS's repository to be able to stand your aircraft aside, make your own sandbox and have commit priviledges on your own sandbox. That is distributed. It gives you a voice. (or the developer). It gives you a way to present your proposal without messing no-one else work immediately. On top of that it allows you to join the cooperation via pull requests.
In addition Github platform is usually very transparent to show you network trees of repositories and who is working on them, who is more progressed, who has more branches (a.k.a more popular --tipically a good example of wellness) etc.
See? think hard about this. We dont need "trusted" committers, or aircraft kings, in a world where everyone can fork, improve and send a pull request. It takes a few minutes to send our way a step (forward or not).
In the case of FGADDon, thou, and their rules, they have a centralized system (subversion) where no-one has commit access. It is just to share the code, not to share the ability to create and participate. Then the subversion starts having a trusted key-ring of known "safe" contributors, which have access to the code, because a long time demostrated knowledge of the code. And they all write directly to the only-single one repository. If you damage something there, you damage it for everyone (you did not mess "your fork" -- you messed the whole thing!)
That is why a subversion repository, centralized and monolithic is fragile, and you can't freely give keys openly. And that attempt to compete in openness with FGMEMBERS may end up having unexpected consequences.
Think about it for a second. Even long-standing knowledgful commiters keep sending wrong commits our way (FGMEMBERS rebase FGADDON), and we end up detecting these and correcting them, ie
https://github.com/FGMEMBERS/PC-9M/issues/1Which brings an interesting example of the problems of centralized repos, and the huge advantages of distributed ones.