Board index FlightGear The FlightGear project

FlightGear Development Push

Questions about the FlightGear organisation, website, wiki etc.

Re: FlightGear Development Push

Postby CaptB » Mon Nov 23, 2015 10:37 pm

In order to understand more about why there are problems, I'm curious to know more about the internals of the project:

1 - How are decisions made about accepting new contributions?
2 - How are decisions made about accepting new core developer candidates?
3 - How are decisions made about the general direction of the project?
4 - Is the userbase in any way consulted or taken into account in regards to points 1 & 3?

On a side note, my observation is that free/open projects with a strong BDFL personality at the helm tend to fare a lot better.
CaptB
 
Posts: 538
Joined: Thu May 23, 2013 6:36 pm
Callsign: EKCH_AP
IRC name: CAPTB
Version: 2018.1
OS: Xubuntu, Win7 64

Re: FlightGear Development Push

Postby curt » Mon Nov 23, 2015 11:02 pm

FlightGear is often a meritocracy. I have received patches in the past with comments like: "I didn't understand what xyz did, so I just removed it." I have also receive amazing contributions from brilliant coders like Andy Ross who has a wonderful ability to create complex and highly functional results with really simple looking code. (Yasim, nasal, etc.) (It is Andy's birthday today by the way.) :-) New core developers are considered after they have established a positive track record and the other core developers are comfortable handing them a copy of the keys. Often specific decisions are made by the people who are doing the hard work (as is the case with most/all open-source projects.) For example, James' new Qt launcher design and implementation is his own, although he is planning to review it with his day-job's usability expert. He is also asking for and taking feedback on the developer mailing list.

We are real people who enjoy each other's company, enjoy working on FlightGear, and enjoy seeing what cool new things other people come up with. So when someone brings a good attitude, is friendly, shows that they are wiling to consider feedback and rework their contribution to address our concerns (if there are any)... that goes a long way.
curt
Administrator
 
Posts: 1174
Joined: Thu Jan 01, 1970 12:00 am
Location: Minneapolis, MN

Re: FlightGear Development Push

Postby Hooray » Tue Nov 24, 2015 1:36 pm

Those are all very good points, but as long as patches are not reviewed/integrated and committed within a reasonable time frame, it is unlikely that it makes sense to get external contributors involved - and ironically, this is also adding to the problem that Nasal is seeing an increasing rate of adoption (despite it having GC issues), because a shortage of core committers also means that it is much easier to add functionality at the Nasal level, like "someone" mentioned a while ago:

http://sourceforge.net/p/flightgear/mai ... /15645373/
Torsten Dreyer wrote:its not that easy to get your changes into the system. I am not complaining about this and I acknowledge that changing the internal
program is a thing that has to be carefully reviewed. Writing some Nasal code usually does not affect the whole system and can be maintained for a single
aircraft. To make things easier for developers, can we think of a plug-in system for callbacks so a potential developer write a library that is linked in
dynamically by the flightgear core? I think having a plug-in system for compiled/binary extensions whould give us great flexibility without touching the flightgear-core to heavily.
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: 11340
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear Development Push

Postby stuart » Tue Nov 24, 2015 3:04 pm

Hooray - I think you've made that point quite enough times on this thread. Thanks.

CaptB - there is a FlightGear Policy Statement which should answer all but the last of these questions. It's currently waiting for Curt to publish it on the website, but the -devel list thread regarding this is available here http://sourceforge.net/p/flightgear/mailman/message/34183645/.

The answer to the last questions depends on who you mean by user-base. Certainly we try to make decisions thinking of the users - James' recent work on the launcher to improve useability is a case in point. And some of us do read the forum to get feedback, ideas and understand concerns users have. Consultation goes as far as the -devel list, as that's where the core discussions take place and people ask for comments on their development plans and features. Users are welcome to take part in those discussions, but as Curt says, this is largely a meritocracy, and those who do the work get to decide where the project goes.

Curt - could you post the final version of the Policy statement and Roadmap onto the website so it is public.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1469
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: FlightGear Development Push

Postby Hooray » Tue Nov 24, 2015 5:56 pm

stuart wrote in Tue Nov 24, 2015 3:04 pm:Hooray - I think you've made that point quite enough times on this thread. Thanks.


well, you are very welcome, thanks for appreciating my comments ;-)

more seriously though:
Like I said already, I fully realize that I am being a PITA by pointing out such unpopular issues.

And also that this must be very annoying from where you (core developers in general) are standing because you must perceive this as being part of the problem rather being part of the solution.

However, you in particular should be able to relate to this, because you were expressing these concerns long before anybody else found the right words for this dilemma, which clearly encouraged other core developers to also look at the underlying problem (i.e. among the group of active core developers).

And in the case of osgEarth and the corresponding merge requests, you -Stuart- were clearly trying to be part of the solution, not the problem, by being extremely responsive and instrumental to the whole process.

However, beyond pointing out the obvious, you cannot do much about it - last I checked, there were 2-3 project managers, i.e. those able to add new gitorious/sourceforge users as committers to sg/fg. With Torsten/ThorstenB being inactive at the time, and James the only one to add new people. Maybe that is part of the problem here ?

This thread is about "pushing core development", possibly by using crowd-funding or some other form of funding.
While you -and others- rightly pointed out on several occasions that the project needs more core developers and more active committers.

I really feel the FlightGear project could easily ridicule itself by starting a crowd-funding campaign like the one originally suggested given the circumstances that we all know about.

It would be extremely premature to get outsiders involved before such internal matters are resolved.

Keep in mind that osgEarth was basically development that took place using sponsoring/funding (at least in part), so we would be making such issues even more prominent the very instant we are dragging external people into this dilemma, without also providing for a way for such contributions to make it back into the project.

I do understand that my postings in this thread must be unpopular to some long-time core developers, but just like my postings are based on exchanges behind the scenes of the project with non-committers, they are also triggering exchanges between core developers - which is a good thing, no matter if you agree with the nature of my postings or not: there is an actual problem, and it needs to be faced.

We've had many other situations where long-timers would either look away or close their eyes completely (including the whole multicore debate), yet, we are seeing fruitful results in response to such debates - whereas you can find tons of quotes in the archivces (even just from a few years ago), suggesting that "it's a common misconception that flightgear doesn't have good multicore support", we are now seeing public interviews on souceforge where we actually, and finally, admit that "Currently we don’t take good advantage of multi-core CPUs.", and even the corresponding comments on ongoing HLA/RTI work - all that, despite having seen massive improvements in the PagedLOD/OSG department in the last 3 years.

And now, look at the context behind all this - not too long ago, I would receive messages from you, and other core developers, that people were "mis-representing the project" by posting references to ongoing HLA/RTI and PagedLOD work on the wiki, whereas you and others are meanwhile jumping on this very bandwagon.

So either people were wrong previously, or all the ongoing work is irrelevant ?

Without meaning to sound disrespectful, something pretty weird is going on here - either we accept that there are problems and do something about that, or we move on and keep closing our eyes.

Either way, we would be doing a huge disservice to the project should /anybody/ attempt to get funding involved unless there is a clear roadmap in place to deal with the obligations resulting from that, which includes having processes in place to deal with future contributions and contributors without them getting the impression that the FlightGear project is giving a **** about their work.

For the time being, I would actively discourage anybody, with a schedule/deadline and on a budget, from getting involved in FlightGear core development, especially professionals wanting to see their work in FlightGear sooner or later, because we as a community only tend to waste people's time - that is much better spent contributing elsewhere, or creating a fork of FlightGear and push everything to github to comply with the requirements of the GPL.

That may be extremely sad, but the last time core development was "fun" for outsiders was when people like Melchior would actively get in touch with contributors to get their patches committed.

These days, there's simply nobody around to handle such things, and even if you know someone with commit access, it easily takes several months before people have time to review things.

I don't even want to imagine what it's like to create a patch for an unmaintained component without any active maintainer feeling comfortable reviewing such stuff.

Subject: FlightGear Development Push
CaptB wrote:I'd like to quote Einstein here: "Insanity:doing the same thing over and over again and expecting different results"
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: 11340
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear Development Push

Postby curt » Wed Nov 25, 2015 4:04 am

CaptB wrote: I'd like to quote Einstein here: "Insanity:doing the same thing over and over again and expecting different results"

Hooray: I would actively encourage you to read every 2nd post in this thread!
curt
Administrator
 
Posts: 1174
Joined: Thu Jan 01, 1970 12:00 am
Location: Minneapolis, MN

Re: FlightGear Development Push

Postby Hooray » Wed Nov 25, 2015 3:46 pm

Curt, I would actively encourage you to state if you disagree with any of my concerns and conclusions, and if so, please tell us why - like I said, I understand perfectly well what you -specifically- are thinking about those postings, but I am pretty damn sure that you would also not particularly appreciate a crowd-funding campaign targeting FlightGear, no matter how "successful" it might be.

However, if you think that I am wrong, it is obviously easy to not only say so, but also do what people are asking you to do - and I would in fact be glad to be proven wrong.

Your call, not mine - I do not think that the FlightGear project, and in particular its remaining share of core developers, can pull this off.

If I am wrong, all the better - it will be great to witness this.
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: 11340
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear Development Push

Postby curt » Wed Nov 25, 2015 8:44 pm

Hooray, my main gripe is not with what you are saying, but that you are beating a drum of negativity every other posting on this forum. Now you have gotten worked up enough to start 'actively discouraging' people from contributing to the project, and are 'extremely sad' about the state affairs. You've mentioned a hoped-for fork in just about every posting as well. It's fine to state your opinion, but the forum has become saturated with your 'gentle' and self appointed guidance. You clearly are frustrated if you feel you are being ignored, but forum postings are not an effective way to direct or guide any open source project. As said many times on many forums with many projects, it is the people who actively engage and contribute code and content that set the direction and tone of the project.

Best regards,

Curt.
curt
Administrator
 
Posts: 1174
Joined: Thu Jan 01, 1970 12:00 am
Location: Minneapolis, MN

Re: FlightGear Development Push

Postby Hooray » Thu Nov 26, 2015 1:53 pm

I am surprised seeing that you, specifically, are still participating in this discussion.

Anyway, this must be extremely entertaining for people that were recently banned from these forums.

Especially, seeing that you are now giving me the same kind sermons that I am usually giving to newcomers (it would be even more hilarious if you sent me a link to the wiki article explaining how the project works) :lol:

my main gripe is not with what you are saying, but that you are beating a drum of negativity every other posting on this forum.

So, here we are: 5 pages and 60+ postings later, we are arriving at the conclusion that I am not exactly wrong in what I said, but that you don't appreciate the tone ?
All this, despite your earlier comments that could have easily encouraged people to pursue crowd funding ?

You can go and ignore all postings I made on this thread and help people pushing for a crowd-funding campaign, but somehow I am pretty convinced that having this discussion is the lesser evil, and you probably know it, right ?

Because there's clear difference between stating something unpopular and something that is just plain wrong.

Look, had I not participated in this thread, but had instead supported a crowd-funding campaign, you might be in for a much bigger challenge/problem now. But, maybe you want me to do that next time to make that point ?

In other words, you would now be facing exactly what I described in a number of postings - without you, or any other core committers, stating and admitting that there are certain organizational challenges that would complicate matters tremendously for those few remaining core committers.

Why is it, that I am the only one to tell people about these issues, despite you now finally admitting that these concerns are not unsubstantiated, but that they're indeed for real ? Especially in the light that you stated earlier that you were not opposed to the idea ?

It is exactly this kind of torn-attitude that makes people spend their time working on/contributing to FlightGear, only to realize months, or even years, later, that they were really just wasting their time dealing with people who cannot get their act together.

Now you have gotten worked up enough to start 'actively discouraging' people from contributing to the project, and are 'extremely sad' about the state affairs.

nope, I specifically restricted my discouragement to a certain group of people, i.e. those with a professional interest in FlightGear, who are on a budget/deadline and want to see their work merged upstream.

I don't remember if you are self-employed or have an employer - but just imagine having to tell your boss that you've literally spent 18+ months trying to get feature X merged into FlightGear, but that things are proving "a bit tricky", on a purely non technical level.


You've mentioned a hoped-for fork in just about every posting as well.

"hoped-for"?
That's also wrong, I mentioned that a number of people were/are contemplating such a fork, but I also mentioned specifically that I don't support it, and that I also think that there's a certain barrier to entry involved for anybody trying to do this.
Indeed, you could make the case, that the mere fact I am discussing this here in public (with you), is the strongest way of disagreeing with such a fork. If I were hoping for/supporting such a fork, I could just as well help and make it happen.

It's fine to state your opinion, but the forum has become saturated with your 'gentle' and self appointed guidance.

My suggestion would be not to shoot the messenger here - you may not like what I am posting (or my attitude), but like I, and others, have mentioned - this is not about my involvement or my posting history on the forum. The underlying problems would not go away if I stopped posting here, neither if you deleted everything I ever said about the FlightGear project and the challenges it is facing. Unless of course, you prefer to turn a blind eye to everything that is complicating FlightGear matters.

I guess, it's time for a reality check, if you think that the devel list is a much better place (without any self-appointed guidance being posted there), here's is what former core developers are stating about the atmosphere among core developers these days:

Subject: Turning off turbulence
daveculp wrote:This is why I don't submit a feature request or bug report. The answer is always so pat. And I don't visit the devel list either, because that unhappy place would be even unhappier if I was there.




You clearly are frustrated if you feel you are being ignored, but forum postings are not an effective way to direct or guide any open source project.


I am not disagreeing with the latter, but like I said originally: I am not feeling ignored.

If I were trying to "direct" things, it would be much easier to express my support for a potential fork and have my way with those people.
What I did in this thread is to make people aware of the challenges, so that they can reconsider for themselves if crowd-funding is worth the hassle, and if FlightGear as a project can deal with the addtitional challenges resulting from it, given the backlog of patches (and other issues) that haven't yet ben addressed in years.

As said many times on many forums with many projects, it is the people who actively engage and contribute code and content that set the direction and tone of the project. and contribute code and content that set the direction and tone of the project.


That's just awesome: That must be the most hilarious closing comment in the context of an OSS project's core committers not accepting those exact external contributions, and contributors, that could actually help set the direction and tone of the project.
This is exactly how egcs came to be and where gcc was failing at the time.

Are you actually trying to prevent or cause a fork here ??

Look, I know what you are doing/trying here, since you are trying to make this a personal thing (i.e. looking at the messenger and his involvement in FG matters) - so I could just as well respond accordingly, even though I think that this says more about the lack of FlightGear project management (skills), than us wanting to further the debate and identify, address/fix certain underlying issues ?

Now, I haven't been following the commit logs recently, so I don't know how much FG related hacking you have done lately, or how many patches/merge requests you were actively involved in reviewing - or if you primarily consider yourself the spokesperson/website manager of flightgear.org ?

However, another frequently expressed concern I am seeing is that the low number of active core developers have to deal with an increasing number of inactive developers, who still want to "direct" the project, without backing their vetos/statements with actual coding hours. It was specifically said that this would be "poor style", and complicate matters for those wanting to contribute, including external contributors.

Funnily, just recently, I responsed to such a message and disagreed with that FG contributor (fgdata), basically suggesting that while this is correct, this trend would serve kinda like a "FlightGear Steering Committee", to ensure that even if experienced contributors don't have much time, their expertise and experience can still help shape the project, while also acknowledging that there are other important, non-coding, areas that may require attention (think maintenance of infrastructure like scenery, forum, wiki, website etc).

However, down-playing someone's own involvement is not going to help address such problems, unless you want to suggest that people should not feel appreciated around here, at which point they may really be better off starting their own fork ?

You may consider someone's involvement marginal, and even insignificant, which is fine with me (frankly, I don't give a damn about attribution and track records)- but if that someone is bringing across a point that was previously made by some of the most senior contributors to the project, it may be beneficial to still look at its merits.

In fact, you were doing exactly that when Tim, Torsten and others made the exact same points a while ago, because you could not just play cheap tricks and pull the "you are not a major contributor card" on them.

So, you took the time and drafted a carefully written response finally admitting that they were right. Just like you were recently admitting that FlightGear is not making good use of multicore platforms.

Sure, they sugar-coated their words, and they made sure to make their statements in a very polite fashion, but fundamentally, people disagreed with the way the project was headed.

I don't know if this ever made it to you, but a few years ago, the people contemplating a fork were not external contributors, but FlightGear core committers, sending out messages to others - I guess there's a reason, why this never made it to the public list ?

You may disagree with people's coding style, attitude, personality, postings, opinions or even their contributions, but you should still look at what they can bring to the table.

Admittedly, my own involvement may not be very visible or obvious to you (and others), but I can assure you that you certainly don't want to offend people like myself to team up with others contemplating a fork, because that me be one of the few things remaining they are still missing to pull this off.

And this kind of response from your side is again extremely unfortunate, because you are empowering those who are considering such a fork, by dealing with my message like this, and by dividing the community even further, without realizing that there already is a number of people who have done tons of FG related hacking (C++, OSG etc), whose contributions don't make it into FlightGear.

So this has nothing to do with me or my involvement - this problem would persist should I decide to move on, or should someone lock such threads, censor/delete postings or remove my forum/wiki accounts.

Personally, I am not convinced that FlightGear should depend on the proverbial "bus factor" to finally rejuvenate its core of remaining committers, unless the people "in power" really want to see a fork sooner or later, just to be left alone.

From where I am standing, I don't endorse/support such a fork, but I will closely watch how/if the FlightGear core developer community responds to these challenges, and I will also act accordingly - especially, should we see more and more substantial contributions that don't make it into FlightGear, without a rejuvenation process in place to deal with the increasing attrition rate we're seeing among core developers.

At which point some of you may be in for a surprise when they realize that there are companies interested in FlightGear, who may have to move on without being able to afford the luxury of befriending people over the course of 5+ years before being granted commit access.

Sorry, but this is just not a viable model for people who have schedules, deadlines and budgets to comply with.


You have helped create, shape and maintain something that more and more people care about, including not just hobby users, but also professional users wanting to contribute their work back to the project.


As long as the FlightGear project does not find a way to accommodate such contributions and contributors, it is empowering the very scenario that you are so opposed to, i.e. a potential fork somewhere down the read.

Alienating contributors, potential ones or former ones, by disregarding their involvement/contributions and feedback, is a pretty sure way to make that happen.

By the way, this is the point where people like bugman would usually recommend newcomers to actually read "The book The Cathedral and the Bazaar", as well as "Producing Open Source Software". ;-)

Now, I don't know if you have ever read any of those or not, but should that not be the case, you will actually find "forks" being covered in those, i.e. what needs to happen to prevent forks, and how forks come to be in the first place.

Equally, I don't know if you have/are contributing to other OSS projects, but the situation with FlightGear is indeed frustrating for people just wanting to get patches in.

And that does not have much to do with technical reasons - in fact, someone recently mentioned "I have contributed to gcc and the linux kernel, and back when I was in college, I used to give computer graphics and C++ lectures as a TA, but with FlightGear, I highly doubt that my patches would "pass" the standards of those doing the reviews, some of whom obviously only just have begun dabbling with C++ according to their commits").

So we have on the hand people holding ATPL/CFI(I) ratings, PhDs and other related qualifications doing C++/OSG or flight training for a living
without their contributions making it back into FlightGear.

Like I said originally, FlightGear tends to attract hackers, not lawyers, tax experts or "project managers" - so it is kinda to be expected that such challenges will keep on being a common theme, regardless of the messenger - simply because the FlightGear project has become more successful than the remaining core of developers can realistically handle, so sporadic/cyclical collapses seem inevitable unless these issues are recognized as such, and dealt with accordingly.

Mutually belittling our involvement/contributions is only going to divide the project even further, and will empower a potential fork, and those wanting to see that happen.

Given mfranz's track record, we are probably lucky, that Melchior didn't just fork the project a few years ago, or FlightGear could easily be irrelevant these days, had he managed to gather a group of active contributors, especially those with a professional interest, around him whose patches are actually reviewed and integrated in a timely fashion.

And in fact, in a world where cloning repositories is just a mouse click away, the only major USP (unique-selling-point) the FlightGear project would still have are its non-code and non-data assets, i.e. its vibrant community of contributors, referring especially to the wiki and the forum, which cannot just be "cloned" or "forked".

Like I said, my role in all this may not be obvious to you, and you certainly don't appreciate it for understandable reasons, but I am an active part of this very community, and also a part of your USP should someone actively seek to fork FlightGear (just like I were opposed to the FPS efforts).

Were you more involved in fgdata/forum matters, this would be more obvious to you. But I don't blame you, after all, people not being mutually aware of their involvement, is exactly the issue we are talking about.

I think you may be able to relate to this argument, i.e. community importance, given the impact that the web 2.0 phenomenon had on FlightGear (facebook, website, wiki, forum), but also given that running Google AdSense seems to be the only recurring way for FlightGear.org to monetize on the success of FlightGear, without tons of obligations resulting from it.

There are clearly conflicting priorities colliding here, i.e. a tiny group of spare time hackers doing it for the "fun" of it, while others are actually making a living using, modifying/extending and integrating FlightGear - some of us on a weely/daily basis.

In another interview, you mentioned that "the possibility to do flight sims for a living never presented itself", more recently stating something along the lines of "FlightGear is hoping to become more relevant to industry leaders by adopting HLA/RTI".

The question is, and remains, if FlightGear can deal with this disparity between those hacking FG internals for a living, and others doing it as a hobby (like you apparently), so that patches may not be reviewed for months, at which point a fork may be the only viable path forward, unless the project is willing to rejuvenate its core of active committers and project admins to ensure that a constant stream of flesh blood is maintained.

While the flightgear.org TLD may admittedly appear like a strong asset for the time being, seeing a fork of FlightGear supported by code from companies like Boeing, Honeywell etc could easily make FlightGear irrelevant within a few months.

Like I said, you may not agree with all of the point I made, and even strongly disagree with my tone/personality and attitude, but maybe you can see the merits in some of the points I made, and maybe -someday- you should consider discussing this during one of the weekly hangouts you are having, to see if something can be done about this, i.e. to specifically welcome new contributors, and to be much more proactive (or even aggressive) when it comes to recruiting new core committers.

It seems that James and Torsten are halfway there, but their offer to "prepare the corresponding groundwork" is unlikely to be found/seen by aspiring core developers.

At the end of the day, all of us share a certain passion for FlightGear - apparently, just for different reasons, you -and others- wanting to enjoy hacking in your spare time, while some of us want to see it evolve to continue working with it at our day jobs, which is why clocks are ticking differently for both camps of contributors.
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: 11340
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear Development Push

Postby punkepanda » Thu Nov 26, 2015 2:11 pm

Chapter One - How to write to long posts :mrgreen:
punkepanda
 
Posts: 237
Joined: Mon Nov 04, 2013 9:11 pm
Callsign: LostFlight
Version: 2.12
OS: Arch Linux

Re: FlightGear Development Push

Postby Hooray » Thu Nov 26, 2015 2:57 pm

yes, but the whole discussion has become pathetic - which still may be preferable over the alternative, i.e. having to deal with an ill-informed crowd-funding campaign started by some overly ambitious folks who are not aware of certain issues.

And even without expecting anybody to ever look back at this thread (let alone read all postings), it will be good to have this in the archives, if -some day- a fork of FG should really show up.

And if that does not happen, it means that the FlightGear project learnt something along the way, which would be even better.

In the meantime, I suggest to closely coordinate any activities related to funding with Curt and Torsten, to ensure that this will not backfire at the project and its reputation.
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: 11340
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear Development Push

Postby bugman » Thu Nov 26, 2015 4:16 pm

Firstly, I do not recommend the The Cathedral and the Bazaar and Producing Open Source Software to new comers. Rather to people wishing to do something for the FG project, I recommend that they read the section that covers in fine detail what they are interested in doing. This avoids me from having to explain exactly the same points. And Eric S. Raymond and Karl Fogel have written it in a much better way than I ever could.

Secondly, I disagree that opening the flood gates to the official repositories and granting anyone and everyone access without first performing any pre-screening is a good idea. You can't just appoint new developer without them first proving themselves. No open source project does this! It is a recipe for disaster and the death of a project. So let me pull out the Producing Open Source Software citations again, specifically the section on choosing committers:

Producing Open Source Software wrote:In the Subversion project, we choose committers primarily on the Hippocratic Principle: first, do no harm. Our main criterion is not technical skill or even knowledge of the code, but merely that the person show good judgement. Judgement includes knowing what not to take on. Someone might post only small patches, fixing fairly simple problems in the code, but if her patches apply cleanly, do not contain bugs, and are mostly in accord with the project's log message and coding conventions, and there are enough patches to show a clear pattern, then an existing committer will usually propose her for commit access. If at least three people say yes, and no one objects, then the offer is made. True, we might have no evidence that the person is able to solve complex problems in all areas of the code base, but that is irrelevant: the person has made it clear that she is capable of judging her own abilities, and that is the important thing. Technical skills can be learned (and taught), but judgement, for the most part, cannot. Therefore, it is the one thing you want to make sure a person has before you give her commit access.

When a new committer proposal does provoke a discussion, it is usually not about technical ability, but rather about the person's behavior in the project's discussion forums. Sometimes someone shows technical skill and an ability to work within the project's formal guidelines, yet is also consistently belligerent or uncooperative in public forums. That's a serious concern; if the person doesn't seem to shape up over time, even in response to hints, then we won't add her as a committer no matter how skilled she is. In an open source project, social skills, or the ability to "play well in the sandbox", are as important as raw technical ability. Because everything is under version control, the penalty for adding a committer you shouldn't have added is not so much the problems it could cause in the code (review would spot those quickly anyway), but that it might eventually force the project to revoke the person's commit access—an action that is never pleasant and can sometimes be confrontational.

Some projects insist that the potential committer demonstrate a certain level of technical expertise and persistence, by submitting some number of nontrivial patches—that is, not only do these projects want to know that the person will do no harm, they want to know that she is likely to do good across the code base. This isn't necessarily harmful, but be careful that it doesn't start to turn committership into a matter of membership in an exclusive club. The question to keep in everyone's mind should be "What will bring the best results for the code?" not "Will we devalue the social status associated with committership by admitting this person?" The point of commit access is not to reinforce people's self-worth, it's to allow good changes to enter the code with a minimum of fuss. If you have 100 committers, 10 of whom make large changes on a regular basis, and the other 90 of whom just fix typos and small bugs a few times a year, that's still better than having only the 10.


Let me repeat - the potential developer must do no harm and be able to play well in the sandbox. You can cry to high heaven that we should bypass the basic checks in the FG project just to get more developers into the core, and that not doing this will cause forks, lost developers, anger, and resentment. But that does not remove the need to be careful to whom commit access is granted to.

Lastly, you make it sound like it is impossible for a new developer to join the project. This is patently not true. FlightGear is a meritocracy - if you are determined to play well in the sandbox and prove yourself, you will be granted commit access. But patience is required. Iterative code review to get the code up to the project standards is a required effort. And you must be prepared to have code rejected, and then prepared to work on an alternative. If you give up at the first encounter of these processes, then you have no chance. Anyway, it is not a 5+ year wait as you portray it. Note that all of this must be via the devel mailing list - by definition the place where developments are discussed, and the same place that the project was born all the way back in 1997.

Regards,
Edward

P. S. If your patches haven't been reviewed, then you probably haven't done it correctly and made a merge request via the SourceForge infrastructure (FGAddon obviously excluded, as that approach is different). Or you haven't posted a follow up on your merge request on the devel list if there hasn't been a response for a few weeks.

P. P. S. Where is the Boeing and Honeywell code for FlightGear that has been rejected? Is this real, or just hypotheticals?
bugman
Moderator
 
Posts: 1708
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: FlightGear Development Push

Postby Hooray » Thu Nov 26, 2015 4:54 pm

Is this for real ? I will gladly continue this discussion (I am not the slightest bit bothered by it), but as far as I have been told so far, I am allegedly putting harm to the project by discussing this openly here and now, and by posting the quotes from the archives supporting the case I am making.

Anyway, you can have a pre-screening without that having to be a multi-year process - like others have stated, too (including even Curt himself, as you can see by the quoted postings).

Keep in mind, that without James' active efforts, even Canvas would almost certainly still be a set of "topic-branches" (patches) circulating around the web, had he not actively supported the whole thing, and finally granted commit access to its developer.

On the other hand, thanks for your efforts on defending FlightGear and its current modus operandi - had you done a little more research, you would have found postings where I stated the exact same thing that you are stating now (and you could have quoted me verbatim), just a few years earlier - it seems, the average FlightGear contributor goes through different stages, where defending the project and the way its working to outsiders, is a key part of becoming part of this culture - so you are well on your way.

Then again, you will also see that long-timers expressed very much the same concerns over time, just more politely.

It is pointless to refer to sourceforge merge requests here, because sourceforge is a really a fairly recent thing, while much of this predates the gitorious/sf move. And no, this is not about any of my patches. Equally, I am not bothered by having to track different repositories/branches. The question is, and remains, if FlightGear as a project can afford the luxury of being all that selective when it comes to its core developers, given that there is 1) a shortage of active committers, 2) that among those with commit access, several have stated dissatisfaction with the state of affairs, and 3) those with commit access also stated repeatedly that patches that were put up for review, were outside their comfort zone, i.e. they didn't feel qualified to review/commit patches and take over the responsibility.

Given successful attempts at integrating complex features, like osgEarth, with the existing code base, it is pathetic to suggest that FlightGear is a carefully-structured piece of code onto which you cannot just throw a pile of new code, because that is obvious to the people who succeeded at doing that. Equally, FlightGear itself is obviously complex, but the underlying building blocks (fgcommand, SGSubsystems, properties etc) are fairly self-contained, and can be understood/modified without much effort.

The company names were indeed hypothetical, but there were/are patches from people who did have a professional interest in seeing patches merged upstream, including people working for avionics manufacturers (indeed, the MKVIII implementation was also sponsored development that almost didn't make it into FG, had FredB not done all the work to review the code, despite it being a massive, unannounced, set of patches). However, that does not apply to a handful of similar incidents, where development did indeed take place in the open (i.e. using gitorious topic branches) and was also announced on the fg forums and the devel list.

Equally, osgEarth is not the first "photo-scenery" effort that was offered for inclusion into FlightGear.

Due to the shortage of core developers, it remains to be seen if we can afford the luxury of dealing with people like this, given that these are folks who are capable of 1) using git, 2) making working modifications of SG/FG, 3) patch/rebuild FG, who have a professional interest in seeing FlightGear thrive and evolve.

As can be seen by the handful of "topic branches" discussed in the scope of this thread, we are seeing an increasing number of "topic branches" that -realistically- will never get merged back into FlightGear, at which point this is highly unfortunate for the FlightGear project, but also all the people who spent hundreds of hours modifying FlightGear source code.

As an open source project, the most disrespectful thing we can do to potential contributors, is wasting their time - at which point the most likely outcome is going to be a fork, where our influence is going to be zero, nada, nil, null.

It is only fair to be concerned about that, 3 years later, we may be facing a situation where more core related patches went down the drain, than all the combined sg/fg core development committed to the official repos in the same time frame.

Not exactly a good thing for the project or our reputation.
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: 11340
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear Development Push

Postby Lydiot » Thu Nov 26, 2015 5:22 pm

bugman wrote in Thu Nov 26, 2015 4:16 pm:Secondly, I disagree that opening the flood gates to the official repositories and granting anyone and everyone access without first performing any pre-screening is a good idea.


Just curious, but who made the above suggestion? I read Hooray's novel-length post while pooping, and I didn't see him propose that. Don't recall seeing that elsewhere in the thread either...
Lydiot
 
Posts: 987
Joined: Tue Oct 22, 2013 10:50 pm

Re: FlightGear Development Push

Postby Hooray » Thu Nov 26, 2015 5:29 pm

Lydiot wrote in Thu Nov 26, 2015 5:22 pm:
bugman wrote in Thu Nov 26, 2015 4:16 pm:Secondly, I disagree that opening the flood gates to the official repositories and granting anyone and everyone access without first performing any pre-screening is a good idea.


Just curious, but who made the above suggestion? I read Hooray's novel-length post while pooping, and I didn't see him propose that. Don't recall seeing that elsewhere in the thread either...


lol, this thread is becoming even better now - thanks for spending your precious "spare time" reading all the b/s (SCNR) - BTW: I will never forget you nickname from now on, even if posting all this should get me banned from the FlightGear forums :D

PS: By now, most of the participants in this discussion should have received a private message from one of the most senior developers, asking you to stop participating here, to ensure that this discussion will silently "die" and let me have "the final word", so I wasn't expecting this to continue at all (I have been on both sides of this, so I know it all too well).
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: 11340
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to The FlightGear project

Who is online

Users browsing this forum: No registered users and 1 guest