Board index FlightGear The FlightGear project

On the Current State of Affairs in FlightGear

Questions about the FlightGear organisation, website, wiki etc.

Re: On the Current State of Affairs in FlightGear

Postby Philosopher » Sat May 02, 2015 3:25 am

What do you mean? There was the whole SVN/sourceforge thing, and when Israel showed up late to the party, he missed a chance to (effectively) participate in the discussion, because it was already carried out by that time. That's the sense in which it was very bad timing, not what was going on, but what was done.
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: On the Current State of Affairs in FlightGear

Postby curt » Sat May 02, 2015 3:47 am

This might be a poor analogy in some ways, but imagine a wedding that has been planned for years. At the "speak now or forever hold your peace" portion of the vow, someone walks into the church and realizes for the first time that those two are getting married and jumps up to protest. They fully expect to veto the wedding because they think they have a better plan in mind. Maybe they can make a good case, maybe there is some merit to what they are saying, and it wasn't their fault they didn't see the wedding notice in the paper and stumbled on it late the day of, but in the final analysis, it was unfortunate timing. Decisions had already been made, wheels were in motion. From there, the veto attempt and the follow up to that were not handled well from an interpersonal standpoint. Rather than accept a community consensus and work to build relationships with the development community so that future cooperation would be possible, the response was more along the lines of trying to vilify the long term development group. As we tried to respond and explain, it only agitated the situation worse. I'm hesitant to even post a reply here, just because it seems like every time I address this in any way with any strategy, it simply agitates the situation. Lots of words are said, with lots of logic and lots of quotes and facts, but ultimately it's the tone underneath the words that carries the stronger message, and that exponentially agitated itself with every response and quickly out paces any words that are being said ... to the point that nothing further could be accomplished in a cooperative way. I think both sides recognized this. The development community discovered that any response led to exponentially increased agitation so they disengaged from the discussion. fgmembers realized their veto was actually going to be ignored and was obviously at this point highly agitated, so fgmemebers proceeded in an adversarial way. And now here we are talking about the inherent structural problems of the project rather than questioning why it is ok for someone to push their agenda in an adversarial way? I've always felt that most people in the world would look for ways to work together and build community and relationships ... because that is how you accomplish the most positive in the long run. In this case, fgmembers is doing everything possible to split up the community and sour relationships with the code development community and forge new relationships with the aircraft developers and actively trying to pit one against the other. I understand what's going on, and from a short sighted perspective it is (a) retribution for an ignored veto and (b) and subsequent power play. But from the longer term perspective, to have someone actively working to split up the community and pit one group against another ... that is harmful to the project, even if the original point of contention had some technical merit.

So it really was an issue of unfortunately timing due to the person presenting the veto not being aware of the discussion and the decision process until well after the decision had been collectively made. And then there are subsequent issues of how a person deals with their veto being overridden, how they speak to others, and if they actively seek to divide the community and pit people against each other.

If you have any content that could in anyway be sucked into fgmembers, you are fgmember's best friend right now. Fgmembers is in aggressive alliance building mode. Sweet words are being showered all over the forum in just about every thread. If you were in any way involved with the structure or discussion or decision to split the fgdata aircraft out into it's own separate repository called fgaddon, or have subsequently supported that decision, or said anything implying weariness with the response of fgmembers to veto the veto, then you are on the enemy list.

Those with discernment can weigh all this, connect the dots that they see, and decide for themselves.
curt
Administrator
 
Posts: 1174
Joined: Thu Jan 01, 1970 12:00 am
Location: Minneapolis, MN

Re: On the Current State of Affairs in FlightGear

Postby Jabberwocky » Sat May 02, 2015 4:23 am

None of those "bad timing" lines and also not the "wedding" analogy describes what actually happened. The whole subject was discussed behind closed doors which is a result of the isolation between core development on one side and users and content development on the other side. The majority of the community was just told to swallow it despite some technical cons.
IAHM-COL came up with FGMEMBERS AFTER you decided behind closed doors but BEFORE it was actually implemented. And yes, on a mere technical level, FGMEMBERS or under what name ever, could have been the better solution for everybody and could have replaced FGADDON. But instead of going over the pros and cons, all IAHM-COL got was a gag on the dev-list. So there was no chance to discuss it. We have actually a similar problem again with the scenery now, but also in this case, resentments and the attempts to silence others block the technical situation. So we will voer time probably end up in the same trap again.
So, what can we do? Well actually, the first part of the turbulence is over, FGMEMBERS has more than 600 planes and variants, users load from there all the time, shared development is going on ... FGMEMBERS has nothing else to do but to work on. You can be against it, you can hate it, but since it works, you have no way to kill it. And I advise strongly against more banning attempts, you lost more than enough credibility by that kind of stick beating over the heads of your own community. If IAHM-COL is not safe from being banned for saying the technical truth, who is? That's a question every member of FG has to ask himself now after this practice became the permanent threat.
So, the second stage of the turbulence, the shuttle project. Thorsten wants to add to the GPL an additional need for his personal permission which puts his project outside of the GPL because such a need for permission is not and never was part of the GPL. And since his shuttle is not GPL anymore by his de facto demands, I doubt, it can be hosted in FGMERMBERS in the first place. So, technically, this stage of turbulence is over as well.
Leaves the third and currently last stage, our scenery problem. Well, we will see what the future brings, will we? I honestly have at the moment no clue how that will play out. But then, it won't be the last turbulence, this project will face. Honestly, I believe, as long as we face such changes, it is more or less a sign, the project is alive.

Here is the B-side of it: During this process, old pillars of the community lost credibility by attempts to silence instead to discuss. This damage needs to be repaired over time, it's nothing that happens in a few minutes.
Newcomers were confronted with a flame war that went far beyond the technical issues. Some of those newcomers, and I think, there were also some returns from longer absences, are potential we shouldn't just waste. Hooray's idea that any newcomer who hasn't programmed in the first three minutes of being here ten-thousand lines of C++ source code for the project is simply ridiculous. To build up knowledge, one needs time, resources and information. We should rather try to involve the whole community than to beat people over the head or label them worthless from the start.

I read sometimes on this board comparisons, for example with FSX. Well there are some things, FG can do that FSX can't. But then how many pilots have we online at peak times? 50? I remember when I was new, there were sometimes over 60. At FSX, there are of course at every time at least hundreds if not thousands. Even if we could spark that interest, our MP system would be fried by those numbers. So the question is, what does FG want to be? In which direction does it grow? A small community with always better shaders (I love a good shader)? Or a bigger community with more pull, more resources? Don't argue what is possible or not, just answer it by what do you want? What do WE want, the community as a whole? Regardless what the answer will be, I am pretty sure, we can't afford to lose potential by banning, scaring newcomers off or label them from the start as a burden to everybody. We all were once new, some only were new earlier. So there is no need to jump on everybody simply because he has just discovered FG.
Jabberwocky
Retired
 
Posts: 1319
Joined: Sat Mar 22, 2014 7:36 pm
Callsign: JWOCKY
Version: 3.0.0
OS: Ubuntu 14.04

Re: On the Current State of Affairs in FlightGear

Postby IAHM-COL » Sat May 02, 2015 5:49 am

http://sourceforge.net/p/flightgear/mai ... /33412228/
I cannot see that any group decision made. In
http://sourceforge.net/p/flightgear/mai ... /32338968/ you
declare that you went ahead with SF and subversion. Reading the whole
thread does not reveal anything like a majority for choosing any path
forward. There were some strong players for subversion and you simply
took the opportunity to push through the SF path. I think this was well
intended and resolved the much needed (part) split of fgdata.


Referring to the thread last spring does not really disqualify Israel's
concerns and objections.

**
Well, nothing is broken but I'd say resources are limited and it is a
pity that we need to become proficient in several SCM-systems. Your
argument is a non-argument really - because not braking anything means
that it must be good? Better use James Turner's argument of wrong file
type for git revision control.
**

It depends on what you mean with "works". It disables sharing of code
and ideas that is not accepted by the gate keepers of the centralized
system. I think this is the largest issue with SVN and the reason why I
think something else that subversion should be used.
**

Well, maybe you should not give commit permissions to non-proficient
gitters? Israel actually outlines a scheme where people can mess up
their personal clones without affecting everyone else, and gate keepers
can cherry pick contributions to the master branch for each aeroplane
repository.

**
There is no zero-fail solution and projects are not stronger than their
weakest links. I haven't cloned Israels set up yet but it seems like it
is well away achieving a nice set up for a split of fgdata and aircraft
(and more once the community is prepared for it). Doesn't Israels scheme
actually pave a road for taking out more from fgdata (as suggsted in
http://sourceforge.net/p/flightgear/mai ... /32342020/). I'll
examine Israel's work with interest, for fg use and in my professional life.
**
I think the issue is really that - you just wanted to split fgdata.
Aircraft should have been split as well. The one monolithic fgdata was
replaced with one large aircraft repository. If also aircraft was split
there would not be a problem with github terms of service since each
aircraft maintainer creates their own project. Each of the 400+ project
is well below github requirements.



http://sourceforge.net/p/flightgear/mai ... /33414352/
I have decent download speed so I performed the test (slightly modified
for anonymous read access since I have no account on github). There was
no glitches:



http://sourceforge.net/p/flightgear/mai ... /33443900/
Works great at my end. I even see that the dash model is updated.

I think this is the way forward for now, having parallel paths to
download Aircraft and at the same time providing an git infrastructure
for non-subversion aircraft maintainers. A simple hook-up to the current
fg infrastructure.

Cheers,

Jari


http://sourceforge.net/p/flightgear/mai ... /33444328/

http://sourceforge.net/p/flightgear/mai ... /33445993/
That does not mean that you have to abort your fork, your are of course
free to continue it.
What it does mean is, that _I_ will continue working with the fgaddon
repository
w.r.t. code maintenance, checking backwards compatibility and
release preparations. Also, the official aircraft download page will be
created from that repository. Aircraft developers commiting their work
elsewhere might want to keep this in mind.

Torsten


!! http://sourceforge.net/p/flightgear/mai ... /33492344/
http://sourceforge.net/p/flightgear/mai ... /33494492/

http://sourceforge.net/p/flightgear/mai ... /33494492/

http://sourceforge.net/p/flightgear/mai ... /33498320/

Just wanted to counter the impression that Israel is the only one who promotes
this solution. From what I've read so far the proposed fgdata with submodules
is an elegant, simple and future proof solution. It's easy to use and avoids
downsides of other solutions (like losing history). Users only need to learn
one single version control system. Just clone fgdata and init all submodules
for the optional pieces that one wants to use. It's that simple. And it's
almost done with a credible volunteer for doing the rest.

Really, how can this proposal be not considered more? The whole thing could be
done in a week and important contributors could get back to working on the
simulator right now. Everyone wins!

Stefan



http://sourceforge.net/p/flightgear/mai ... /33499030/
The problem is that many of the users have proved to be incapable of learning Git. Particular a couple of key aircraft developers. Multiple different people have tried and failed to educate the rest of the contributor base about using Git correctly.


http://sourceforge.net/p/flightgear/mai ... /33501145/
Would it be perhaps beneficial if the people engaged in this discussion
created a wiki page with structured checklist of all known problems and
issues? Then those suggesting a different solution could check and state
how their solution would solve (or ignore) those issues. It would make
it easier (I hope) to concentrate on the relative merits of various
proposals.


Cheers,
Edheldil


http://sourceforge.net/p/flightgear/mai ... /33504503/
That's simply not true! With Israel's submodule proposition all of FG fits
nicely into GitHubs terms of service. Well except for two files that are
larger than 50 MB, but really, that sounds much less of a problem to me than
even the current situation.

Stefan


http://sourceforge.net/p/flightgear/mai ... /33503282/
I think it is perfectly doable to restructure fgmeta. There are no problems
with sub-sub-modules at all.
The problem is that for fgmeta you only want a certain set of submodules to
be included.

This is how I would approach that
***


http://sourceforge.net/p/flightgear/mai ... /33503383/

We should remember that the goal with Israels action was to show another
solution for aircraft/fgdata split than the one currently in effect.

Also one should remember, everything released under GPL is open for
forking and changing but I agree that one should credit original
contributors and explain actions taken. Israel has explained his actions
in this thread and maybe should do it also in the (now) forked git repo.

I'd say that Israels change of an aircraft is really a compelling
argument to keep development in git. If the official repos would be in
git, one for each aircraft with the proper owner of the repo, Israels
change would simply end up in a personal clone in parallel with the
official repo. The p51d owner doesn't have to use the proposed change
but others who actually think the change is something beneficial can use
it. The original (official) master will still be there untouched but
everyone who chooses to can cherry pick contributions to their own
clone(s). I also recognize the that such freedom can feel like a threat,
but really, it is a invitation for shared development.


http://sourceforge.net/p/flightgear/mai ... /33503561/
And this is how I had imagined fgdata / aircraft development would work with the switch to git in the first place. It seems to make perfect sense to me (assuming I've followed correctly) - the actual main author/s of each aircraft maintain their own repo and a branch of this is (semi?)automatically pulled into the "official" fgdata as some kind of submodule. The fact that someone has already done the donkey work to prove that it's a valid solution and done it in a very short space of time suggests to me it probably has a great deal of merit.

Obviously as I am sadly for the time being mostly an ex-contributor my opinion doesn't count for much, but I have had a fair bit of experience of both the old and newer workflows and the one mentioned above seems by far the best option in my opinion. No combination of suggested mishmash of git and SVN repos has seemed anything but utterly confusing to me, and I'm quite used to dealing with confusing IT mishmashes in real life...

AJ


http://sourceforge.net/p/flightgear/mai ... /33503595/
For the record, the hybrid SVN / Git suggestions have always been borne of necessity, not elegance.


http://sourceforge.net/p/flightgear/mai ... /33586444/

Hi Israel,

I just test and indeed your solution is fine technically - no problem.


http://sourceforge.net/p/flightgear/mai ... /33546987/
5) Once you get that git repo hosted in sourceforge, I am guessing I will
be completely able to host a fork and add aircraft as submodules. That way,
I sit my fork downstream and sync all changes. Therefore, a really
alternate solution would exist.

If there is someone that strongly oppose to me doing what I outline in step
5, I will appreciate knowing the reasons for that.



http://sourceforge.net/p/flightgear/mai ... /33547521/
Bear in mind that your fork _will_ diverge over time from the svn fgaddon
respository as there's no guarantee that any commits made to the fgaddon
svn will merge cleanly with your downstream repository. You will need to
take responsibility for resolving any conflicts. It'll also not be used
for official release downloads, so I don't see any real benefit for an
aircraft developer wanting to publish their work in as widespread a way as
possible.

As someone whose been involved in FlightGear development for something like
10 years now, I put a lot more faith in the long term longevity of the plan
supported by people like Curt, James and Torsten, as I'm pretty sure
some/all of them will still be around in 10 years time and those repos will
be maintained by the project as a whole. I'm sure you plan to maintain
your fork for just as long, but your interests or available time may change.

Personally I think it's a complete waste of effort for you to fork over
what is a relatively minor code management difference of opinion this and
dilute extremely valuable resource that could be better used to improve the
actual simulator. But your time is your own, and you're welcome to do with
it as you wish.


Best regards,

-Stuart


http://sourceforge.net/p/flightgear/mai ... /33550327/
Would arguments really be fruitful? Following the discussion regarding
SCM and its hosting doesn't really show any value in putting effort in
arguing for an alternative (for what is decided already) path forward.
***
It is simple, it is a regression and would not pass a regression test in
many projects. And the chosen solution is suboptimal and there was a
window of opportunity to take a step forward since the repositories had
to be changed anyway. Now, a step forward in FG management has to wait a
few years for the next convulsion in the project.


So, I am waiting for the dust to settle so FG can take a couple of steps
forward to compensate for the step taken back ;-)
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: On the Current State of Affairs in FlightGear

Postby bugman » Sat May 02, 2015 10:03 am

bugman wrote in Fri May 01, 2015 9:11 pm:1) The FGMEMBERS idea did not grow from within the organisational structure of the FlightGear project. Rather, it was an outside initiative presented to the organisation to be considered as a viable replacement for a core piece of its of its infrastructure - FGAddon. There are plenty of permanently archived development list messages that can be found around the time of that thread which present FGMEMBERS as a flexible and viable FGAddon replacement. I know some people will try to dispute this, but I also know that both Israel and myself will not. But the announcement of the FGMEMBERS modular solution was long after the organisation had settled on the FGAddon solution (it sounds like after many years of discussions), was already working with it, and sorting out the initial teething problems.


Let me clarify that to understand this, you need to see this from the perspective of the bazaar analogy. Outside here does not refer to outside of the bazaar. The influential book The Cathedral and the Bazaar will shed light on this.
bugman
Moderator
 
Posts: 1736
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: On the Current State of Affairs in FlightGear

Postby Philosopher » Sat May 02, 2015 11:46 am

Jabberwocky wrote in Sat May 02, 2015 4:23 am:IAHM-COL came up with FGMEMBERS AFTER you decided behind closed doors but BEFORE it was actually implemented.

Sorry JWocky, but the facts don't support your opinion: Clément made the move in September 2014, while Israel didn't show up on the devel list until March 2015.
And yes, on a mere technical level, FGMEMBERS or under what name ever, could have been the better solution for everybody and could have replaced FGADDON. But instead of going over the pros and cons, all IAHM-COL got was a gag on the dev-list.

Oh, and thanks for arguing our point for us – that he came too late, even though it might have had merit.

PS/edit: the "Splitting fgdata" discussion goes back to 2011, and I'm sure it was discussed a lot back then. As for "closed doors", I can not find any discussion regarding the September 2014 actions, but SVN and sourceforge were likely seen as the only options, because, absent Israel's clever way to split into several Git repos, any other Git solution would involve the same massive download size of fgdata, and also hosting and other problems.
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: On the Current State of Affairs in FlightGear

Postby Hooray » Sat May 02, 2015 12:59 pm

Admittedly, this thread was certainly inspired by the fgmembers dilemma, but I was really hoping that the people involved in this wouldn't be using this thread as yet another platform to make their case over and over again, the events are extensively well covered by having an objective look at the archives.
Curt's "wedding analogy" is actually spot-on, and accessible enough even for the laymen among us.

The collection of quotes posted above is in my eyes neither helpful nor useful, and is only adding to the confusion.
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: 11493
Joined: Tue Mar 25, 2008 8:40 am

Re: On the Current State of Affairs in FlightGear

Postby stuart » Sat May 02, 2015 5:28 pm

Hi drdavid,

Firstly, thanks for your original post. It's always fascinating to see how members of the FG community can use their professional knowledge as part of the project.

Personally, I don't recognize a lot of the points from the CKW list. However, I can see why someone who isn't on the fg-devel list might see it that way, particularly given that not many core developers engage in the forum (see below for more on this :) ).

It's also not clear to me whether these organizational principles apply to a project like FG, where there's no formal organization, but given I haven't read the full paper, and am not an expert on this, I'll leave that to your judgement once you've read The Cathedral and the Bazaar and perhaps gotten involved in the fg-devel list which may provide you with more context.

In your original post you mentioned the need to train the next generation of core developers. For better or worse, there's no formal training, though people are always happy to answer questions provided the questioner has tried to find the answer themselves. Core developers (by which I mean those developing the C++ code and related core infrastructure) become core developers by getting their hands dirty, understanding the code and contributing useful patches that are accepted. If they have a track record of submitting useful patches, they will get the ability to commit directly. If you look on the fg-devel list, you'll see that there are quite a few new contributors to the core code doing exactly this, and indeed that is how I and everyone else became a core developer.

I don't think there is a massive generational issue here - it has always been the case that FG is core development time constrained with a wish to do many more things than we have the resources to do. IMO, what is is different is that there is now a far larger community of content developers (aircraft, scenery, websites, MP fly-outs, VAs etc.), who feel their opinion should be listened to more by the core developers. I'm going to pass on giving my opinion on this right now, as I've run out of time.

-Stuart (not in his capacity as a mod, just incase anyone cares ;) )

PS: Somewhere in the thread you asked why the "core" developers aren't engaging in this topic. In my case, it's because I've been away for a couple of days. In fact I spent yesterday doing a big cross-country flight in my microlight - East Fortune, to Oban, to Colonsay, to Islay, to Bute. 5h45 of quite challenging VFR flying in cold conditions and an open cockpit. Quite tiring! I've also avoided getting pulled into the FGMEMBERs discussions as much as possible because frankly I'm not sure I can add anything that would be considered constructive and not waste everyone's time.

I've been involved in the project for more than 10 years. It's certainly the case that I don't have quite the time available for FG C++ development that I once did as I now have a young family. To give you an idea, developing the tree rendering took 3-4 days of solid full time effort during some Christmas holidays, and the clouds took a similar length of time. So I now have to manage my time very carefully indeed if I'm going to do any significant FG core development, and I imagine that some of the other core developers are in a similar position. So I ration myself, and only contribute where I think it's truly beneficial.
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1474
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: On the Current State of Affairs in FlightGear

Postby Hooray » Sat May 02, 2015 8:56 pm

Stuart wrote: It's certainly the case that I don't have quite the time available for FG C++ development that I once did as I now have a young family. To give you an idea, developing the tree rendering took 3-4 days of solid full time effort during some Christmas holidays, and the clouds took a similar length of time. So I now have to manage my time very carefully indeed if I'm going to do any significant FG core development, and I imagine that some of the other core developers are in a similar position. So I ration myself, and only contribute where I think it's truly beneficial.


right, which kinda does prove the point that the project may benefit from "fresh blood", i.e. committers and core developers who may not yet have certain obligations, with plenty of time on their hands - which is supported by the track record of existing developers and the nature/degree of their involvement when this applied to them.


So even without looking at all the other points in the introductory posting, it would make sense to consider having regular nominations/polls to get new developers, and committers involved maybe 1-2 times per year (e.g. at the beginning of each release cycle) to ensure that there's a steady number of active core developers/committers involved, which is a recurring theme even on the devel list, raised by a number of long-timers:

http://sourceforge.net/p/flightgear/mai ... /15444471/
Curt wrote:we've experienced some significant attrition recently in our core
group. I want to tread delicately here, but we've also experienced several
flaming threads recently that were primarly driven by one or two strong
personalities. (This thread may even be an off shoot of one of those.) This
has magnified the issues and set everyone on edge.

Perhaps the core issue here is (or should be) how do we fill the voids in
our core development group? Does our conservative and safe "earn your way
in" approach perhaps needs to be replaced with something more agressive and
risky so we can build our core set back up to healthier numbers. How do
other projects select core developers?


http://sourceforge.net/p/flightgear/mai ... /30768741/
Stuart wrote:Personally I think most of the active FG devs are currently very overstretched
in terms of the areas that they have ownership of, which is affecting how much
can actually be done. Fundamentally we need more core devs.


In other words, this is beyond just stating how many people have commit access "in theory", but instead about how many developers are able to regularly make commits, and help review issues reported on the tracker or even help review merge requests (think osgearth) - which is another bottleneck frequently identified by core developers.
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: 11493
Joined: Tue Mar 25, 2008 8:40 am

Re: On the Current State of Affairs in FlightGear

Postby Thorsten » Sun May 03, 2015 6:05 am

Does our conservative and safe "earn your way
in" approach perhaps needs to be replaced with something more agressive and
risky so we can build our core set back up to healthier numbers.


You know, after sleeping over this, I think my personal answer is that I'd rather have a slow and sometimes too slow development than play out the equivalent of the FGMembers story on the FG and SG core code because people who don't understand team-play, mutual respect and the need to accept decisions which have been made after long discussions end up being given commit rights 'agressively' to bolster numbers.

Or, as NASA puts it - it's better to fly a safe entry to an alternative landing site than to reach the designated site without wings.

Being able to code is just one aspect of it. And I think, Hooray, you're seeing only that.

Btw., drdavid - I am part of that second (third) FG generation you're always talking about. :-) Clearly I'm not one of the founding fathers - I do patches now where I need code changes to make some rendering stuff work - in time I may get formal commit rights to FG and SG or I may not. There's a few others. Strange how you seemed to miss that this second generation is already there and 'in training' :-)
Thorsten
 
Posts: 11378
Joined: Mon Nov 02, 2009 8:33 am

Re: On the Current State of Affairs in FlightGear

Postby Hooray » Sun May 03, 2015 10:52 am

Thorsten wrote in Sun May 03, 2015 6:05 am:Being able to code is just one aspect of it. And I think, Hooray, you're seeing only that.


actually, I don't - you should take a look at the predominant practice back in the CVS days, vs. how things have meanwhile played out due to the migration to gitorious/git - then, you'll see, that what Curt suggested above, has actually already been taking place every now and then - i.e. most core developers in the CVS days, contributed patches literally for years until they became committers/maintainers (with some core developers, like mfranz, actively doing what you're now opposed to in the fgmembers context: taking patches from the forum and others place and reviewing/committing them without having to be specifically asked) - whereas, since the migration to git, we do have a number of "new" core developers/committers, who were granted commit access relatively soon (e.g. ThorstenB, TheTom, Rebecca) - usually, by Zakalawe - who's kinda become the epitome of a core developer with a strong background from the CVS days of the project, and who had to go through the tedious process described by Curt above.

And so far I fail to see the "horror scenario" you outlined above - and I really fail to see why this needs to be compared with fgmembers, let alone their behavior - and you know for a fact that some people on the devel list may not have granted commit access to you either, had it been up to them.

The core development/committer bottleneck is generally acknowledged by all core developers, and we have already arrived at a situation where maintainers decide on a case-by-case basis whether they may exempt people from having been contributors for a number of years before getting commit access, and this has nothing to do with fgmembers at all.
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: 11493
Joined: Tue Mar 25, 2008 8:40 am

Re: On the Current State of Affairs in FlightGear

Postby bugman » Sun May 03, 2015 11:43 am

For the nomination/poll concept for attracting new developers - I agree with Thorsten here. This is from my general perspective of open source and not an internal perspective of FlightGear. And it has to do with what motivates people to dive into the non-trivial, established code base to make improvements for the benefit of all. The system, like most free and open source projects, is a meritocracy. I guess this is starting to sound repetitive, but the free The Cathedral and the Bazaar (Eric S. Raymond) and Producing Open Source Software (Karl Fogel) books really clarify the operation of such a system. The following list is a small, incomplete summary of this. If you would like to contribute positively to any open source project, you probably would wish to:

    - Have motivation and interest. This is by far the most important factor.
    - Be willing to learn and to accept the practices of a very well established system (to avoid being disruptive).
    - Make positive contributions.
    - Work directly with the project as you are developing, documenting, translating, administering, etc. Never do this outside, as the git SCM system strongly encourages, and then present a finished work to the project, as that just makes huge amounts of work for others who will then not be happy (the stand-alone aircraft for the official FGAddon aircraft repository is probably an exception, as these are wonderful individual gifts from the aircraft developers back to the project which gave them the gift of FlightGear).
    - Avoid being a drain on the limited human resources, and understand that this is limited.
    - Accept decisions by the group or more senior/involved developers, as technical merit is often only one of many factors at play.
    - Have good intentions and avoid all conflict (lively discussions are productive, conflicts are destructive).

This is only a short list - the referenced free books will complete this general free and open source software perspective. There are probably other points specific to the FlightGear project which could be added to the list. Anyway, there is no formal rigid system or structure. Anyone, really absolutely anyone, even those without a coding background but who are willing to dive in and learn, could contribute. And once you prove yourself, that you follow by the rules and that you have good intentions, you will likely be granted commit access to one or several of the many official source and data repositories. This is meritocracy.

For such a motivation-based system, the concept of nomination/polls for pulling in new contributors would not work. Far more effective is to informally encourage and motivate people to jump on board, dive in the deep end, and to play by the rules. He or she who is willing and has good intentions can help make FlightGear even more awesome than it currently is!
bugman
Moderator
 
Posts: 1736
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: On the Current State of Affairs in FlightGear

Postby Hooray » Sun May 03, 2015 5:14 pm

honestly, you may want to look at other FG related development efforts that satisfied most (if not even "all") of your criteria above by most standards, but whose developers still were not provided with commit access (osgEarth being a recent/current example). I don't think we need to keep spoon-feeding how OSS works, most of us have been involved in quite a few other projects, including much more prominent ones than FG - and I guess that most are familiar with those books. But it is true that there are some challenges inherent to FG and its community.
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: 11493
Joined: Tue Mar 25, 2008 8:40 am

Re: On the Current State of Affairs in FlightGear

Postby Thorsten » Sun May 03, 2015 5:31 pm

contributed patches literally for years until they became committers/maintainers


And why would this be wrong in itself?

I mean, this smells like an ego-game - 'If I don't get access within six months, then I don't feel my genius appreciated and leave.' If it's really about contributing to FG rather than personal satisfaction then - what's so wrong with contributing via patches?

What is the time scale you consider relevant? And why?

honestly, you may want to look at other FG related development efforts that satisfied most (if not even "all") of your criteria above by most standards, but whose developers still were not provided with commit access (osgEarth being a recent/current example)


My impression was this wasn't exactly a case of working with the team, but stalled over a disagreement on a patch review. That's kind of the prime example why I said you're not seeing this - gracefully dealing with disagreements and being able to pull together and try again is a skill that's just as important as coming up with good code.
Thorsten
 
Posts: 11378
Joined: Mon Nov 02, 2009 8:33 am

Re: On the Current State of Affairs in FlightGear

Postby bugman » Sun May 03, 2015 5:53 pm

Hooray wrote in Sun May 03, 2015 5:14 pm:honestly, you may want to look at other FG related development efforts that satisfied most (if not even "all") of your criteria above by most standards, but whose developers still were not provided with commit access (osgEarth being a recent/current example). I don't think we need to keep spoon-feeding how OSS works, most of us have been involved in quite a few other projects, including much more prominent ones than FG - and I guess that most are familiar with those books. But it is true that there are some challenges inherent to FG and its community.


Most of my post was for the benefit of the original poster, as some of this is only in the more advanced 'Producing Open Source Software' book. I've been trying to keep my posts general, simple, but detailed for the benefit of the main parties in this topic, not all of whom are familiar with all the details of the open source process. I'm sorry for not making that clear. Anyway, for the nomination/poll of new developers/contributors, why is nomination necessary when they can join the development list and simply start submitting patches for review and creating merge requests?

The osgEarth integration is a rather unique example, as it is far from a trivial change. But this is moving forwards in the normal sense - this is work in progress and it sounds like a new set of patches will soon be forthcoming. This looks like the standard issue with a large external development effort, it takes a lot of work to bring it up to the standard required for integration. Fortunately Jeff is working on it! And it looks like it will be worth the effort.
bugman
Moderator
 
Posts: 1736
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 2 guests