WARNING LEVEL High. FGMEMBERS under official Attack!

[IAHM-COL]

Erik Hofman wrote:
> Maybe it's a good idea to point out that FGAddon could be
> synchronized
> with a private git repository to get best of both worlds.

If you mean using git-svn by people who have commit privileges and can
exercise their gatekeeping duties, then that is technically true but
would be relevant only to them.

If you mean automatic syncing from FGMEMBERS or any other private git
repository, then that's a no-no due to the licensing issues.

If you mean manual merging of private hangars by FGAddon committers,
you should know it's a huge amount of work. I've done it for the
Lockheed1049h and Hamza is only beginning to prepare to do it for the
CRJ700 family. Basically each and every change needs to be audited
for license compliance. I would much prefer contributions to be made
directly to FGAddon even if this implies granting privileges to more
people.

--
Ludovic Brenta.

[IAHM-COL]

> The relations seem to have deteriorated since then,
> but FGMEMBERS did _not_ start as a hostile fork

The statement doesn't say that.

> The only fault of the git
> based suggestion was that it came just months too late, when the switch to svn
> already happened and everyone was understandably tired of the discussion.

And when FGMEMBERS started, they were given a dedicated subforum and free use of the wiki page, indicating
every willingness to give the thing a try. If that is not collaborative spirit towards a fork, what is?

We've moved on since from a git-based solution to abusive letters to developers, blatant copyright
violations and edits of license texts on FGMEMBERS, forum insinuations that core developers would
deliberately create bugs to block some planes.

At this point, it's not about a GIT-based solution or not, it's what is been done with this solution.

> If all the time
> that has been wasted by refuting FGMEMBERS and putting it down had been
> invested into vetting commits and merging them into FGAddon, there would be no
> concern about repositories drifting apart.

Which is to say, if the majority would have done what the vocal minority suggested, the vocal minority would
not be unhappy? Probably true, but in my view not a sustainable model to run a project.

> As a constructive suggestion on how to improve the summary, I humbly suggest
> to stick to technical arguments and real facts.

I think given the actual behavior of some FGMEMBERS proponents (which you probably have not seen since not
all of them have been public and some of them have been removed rapidly) the statement is very measured.

Cheers,

* Thorsten

[IAHM-COL]

Hello all,

As a new member to the list and FlightGear I don't really think I have a say (or a horse in this race for that matter) but maybe I can give some feedback from the perspective of someone who arrives and tries to figure out what's going on (I hope my audacity is forgiven)

I agree that the explanation is a bit long and it takes a while to digest. As a new user all I want to know is "what's this branch and how does it relate to the other", and while this distinction can be extended, the main point should be clearer.

Whatever the technical reasons for the fork, it is clear from the discussion and the statement there's too much personal stuff going on. I'd avoid any judgement because it will divert attention into trying to figure out who, if anybody, had the wrong attitude throughout the discussion that lead to the fork. While I think it's only natural to try to justify one's position I'm not sure things like "the core FlightGear team have been working on this project for 15 years and has a long track record of ensure the long-term health of the aircraft" are particularly informative, as true as they may be, as I don't think any fork of any project has ever had the intention of killing them, even if confrontations often involve personal pride or the will to do things one's way. If anyone's taken anything personal or acted disruptively I'm not sure that would be the right place to explain (as it has nothing to do with the content or quality of the repositories themselves; what and how over why), even if briefly mentioning these personal conflicts do exist would be relevant. If details are needed those should probably be presented towards the end or elsewhere.

I just think the very first paragraph should concisely explain there's a fork with different submission criteria and subsequent divergence on this and that and yadda yadda. Nobody will keep reading if they don't understand immediately what the main issue is. After that, anything goes, but I'd just focus on explaining the differences between the repositories and approaches and what users should expect when/if deciding to move from one to the other, why reconciling both is believed unfeasible (from what I understand), and objective reasons to track one over the other, if any (for example being more prone to license violations isn't exactly one as I don't think that's measurable). I know it's all there already, but after a lot of trimming.

Again, sorry for stepping in. It's just the opinion of a humble bystander

Regards,

Ernesto

[IAHM-COL]

Hi,
Even if the majority wanted to move to a git based system (and there are valid technical reasons to do that),
I'd still go with the core devs' decision simply because they have demonstrated over and over a very high
commitment level to the project.
Sorry but I don't think fgmembers holds the high ground here.
Cheers,
Adrian

[IAHM-COL]

In a normal universe, people have disagreements, but they tend to be short term and people generally want to move in a direction of agreement and understanding. We also can have 'fundamental' disagreements with someone, but when you are in a group or partnership, you eventually have to accept those and move on in a common direction. We assume that for most people, this is a core value and core understanding.

We are facing a situation where one member of the community had a fundamental disagreement with the project choices. He has chosen to work against the group consensus, contest that there is even group consensus, and actively work to dismantle the group consensus and even make attempts dismantle the group. His clear objective is not to add value to existing project structures, but instead subvert and replace existing project structures.

There is a clear impasse here that does not appear to be something that will resolve itself on it's own. We cannot assume that all the parties involved wish to make peace and concessions so the larger group can move forward constructively.

There are a lot of firsts here with this situation for the FlightGear project, tracking all the way back to our start in 1996. We have been dealing with this situation patiently (it has been ongoing for 6+ months). We have tried to keep our responses measured and fair, even in the face of some really nasty messages being directed towards a lot of really good people. Some of that nastiness has been posted in public, but much of it has been directed through private messages and emails or through 3rd party proxies, so that fgmembers can maintain a public appearance of being the good guys, nice and helpful and reasonable. This situation continues to force significant conflict. Sadly methods of conflict resolution that have worked well for the project though it's history (and even in our own personal lives) do not seem to work in this situation.

Regards,

Curt.

[IAHM-COL]

I would like to thank everyone working or thinking on this official statement. It is at least a step toward action.

Although tangential to the main issue, the problem of FGMEMBERS runs a little deeper. In the past, material from 3rd-party sites were provided to other sites (including the official repository) through the courtesy of the originating author. With the advent of FGMEMBERS, such material is now acquired without seeking consent. Sure, many license cases make this possible. Yet this gives FGMEMBERS the appearance of being the definitive Flightgear source while diminishing the community role of the originating sites and authors as well as the official repository.

To be fair, not all FGMEMBERS enthusiasts support this entitlement policy, but the repository owner does. It presents a dilemma to some of us who would otherwise make public unfinished projects not yet ready for donation to the official repository. I have no wish to be involuntarily employed to populate a pseudo-official repository, particularly when it is clearly competing with the official repository.

I hope Stuart's statement will be helpful, but I fear it comes rather late. FGMEMBERS is now deeply embedded in much of the community and has energetic and vocal supporters.

-Gary, "Buckaroo" on the forums

[IAHM-COL]

An excellent example for the kind of situation we have in the forum:

http://forum.flightgear.org/viewtopic.p ... ow#p257445

1) claim that legal entry standards on FGMEMBERS are not lower than on FGAddon and that the argument about
not being able to merge back would be a ruse.

(factually wrong, see recent discussion, and as later mentioned in the thread, Israel committed a sound
package without even asking for the license)

2) followed by a statement that all FGMEMBERS planes under license issue discussion would be pulled from
FGAddon, so any claims to license violations would originate from FGAddon

(factually wrong, the CRJ700 under discussion was e.g. pulled from Ryan Miller's devel repository, the
A-330 was from Omega-hangar I believe,... - the pattern seems to be to pull the more evolved devel
repository planes under a different license and publish them as GPL with the argument that FGAddon has a
GPL licensed version).

So the whole start of the post is a flat-out lie, with a purpose not difficult to guess. And again it takes
precious time to refute the claims,

Anyone else thinks we're getting the facts wrong?

* Thorsten

[jwocky]

Time to torpedo them ...

[IAHM-COL]

well... it will be ineffective. They don't negotiated this publicly, and thus can't be contested in the forum

This is all information in the "devel.list"

[IAHM-COL]

This is my viewpoint

Curtis is trying to find a sell out point to ban FGMEMBERS to use "official infrastructure"

He is very encouraging to everyone supporting his role, but will come cutting to any other calling to "fairness".

The situation is really messy

1. There is a clear view that there is "an authority". If you read Richard Stallman's messages, he speaks openly about how developers can't have the power to abuse users. How users and the groups they form "community" are the ones controlling the software and how they deem to use it.
In this case, clearly there is a very obvious authority of the developer to deem how the software is to be used, and how the community should interact with the developer. That is the developer having an upper hand

2. I defied authority!. This meaning, more in a paternal figure --as well-- and I defied the core developer leadership.

3. There is an "ownership" of the project that begins by who is paying for such official infrastructure. They had actually made clear already They OWN flightgear and we the users have only 2 options: 1) use it as they deem appropriate and not otherwise, and 2) if wished, work for their infrastructure

4. Clearly there is a very strong reaction to the fact that FGMEMBERS has commits not existing in FGADDon. That has created the last wave of attacks,

we saw it always; FGADDon closed paradigm of development could nt compete the openess of the FGMEMBERS development and we were being faster. They can't handle the fact that aircrafts could be more appealing if they are more developed in other place not the officially endorsed.


They can't see how clearly they are opposing Free Software and its principles, and they are clearly very dissapointed to note (maybe too late) that the proposal I outlay would have been a better solution for the aircraft development in Flightgear. And there is a very strong movement to avoid they loose face value...


But their statement lifts many questions about the legitimacy of Flightgear as a Free Flight Simulators (as in Free Software), and clearly places them in the rank of proprietary Software. --in addition, this could even be a violation of GPL license!


IH-COL