wlbragg wrote in Fri Feb 06, 2015 5:30 am:
Besides the XML catalog is not specific to the Aircraft Center at all
Can you expand on this. All I know about it is that it is a part of the Aircraft Center.
"Catalog Metadata" is based mainly based on a discussion dating back a few years:
http://wiki.flightgear.org/Simplifying_ ... Deployment
The implementation is basically based on the approach used for "meta info":
http://wiki.flightgear.org/Aircraft_rating_system
In general, there's an increasing trend to encode "meta information" in PropertyList-encoded XML files (think aircraft-set.xml)
On the one hand, people want to provide support for better filtering (i.e. searching think web based front-ends for downloading aircraft)
On the other hand, it's also about online deployment/live (i.e. run-time downloading/installation), as well as providing a holistic/integrated means for management of installed resources, without having to touch fgdata (which is supposed to be considered read-only).
This is in line with similar trends like scenery being deployed via TerraSync, or even osgEarth downloading data "on the fly", without touching $FG_ROOT.
Equally, most applications these days can be augmented through custom "modules" (addons, plugins etc) - imagine Firefox or Chrome, which can be easily customized using various themes, modules, plugins and addons. During the last couple of years, this trend could be increasingly seen on the FlightGear side too - especially by exposing HTTP bindings to scripting space.
So over time, it is likely that FlightGear will evolve analogous to most applications having online connectivity, i.e. by allowing optional modules to be downloaded/installed and managed using a built-in front-end - no matter if that's using Torsten's GUI work, James' recent Qt5 prototype or the Canvas GUI/Aircraft Center. The GUI really is just the front-end, the underlying "service layer" (e.g. fgcommands and/or scripting space extension functions) are likely to be identical either way (hopefully).
So, the whole "catalog metdata" thing pre-dates the Aircraft Center/Canvas GUI by several years actually.
But it's thanks to Canvas/the Canvas GUI that these things are getting exposed to users now, i.e. via the Aircraft Center.
Which is why TheTom prototyped the whole thing using the Canvas GUI, which was generally an accepted trend back then.
Meanwhile, the "Phi" and Qt5 developments illustrate that some developers believe in a non-Canvas based route - for understandable reasons.
For FlightGear, it isn't feasible to keep re-inventing the wheel, no matter if that means in terms of scripting languages, GUI toolkits or XML dialects.
And basically, either of these two approaches (Qt5 and/or Phi) could have easily made the whole Canvas GUI debate obsolete.
But we had roughly 30-50 different GUI debates over the years - until recently, the Canvas GUI effort was the only effort that provided tangible results (except for PUI obviously).
Recently, this has changed thanks to Torsten's and James' work - but back in 2012/2013, none of those efforts were considered, let alone discussed/announced.
Which is symptomatic of the way FlightGear development often just "happens" by having contributors willing, interested and able to explore certain paths, without necessarily believing in more standard ways.
however, consensus is a difficult thing to establish/enforce in a volunteer-driven project
I see that and even though the lack of it at time can be extremely frustrating it also has its benefits. We are all free to develop where we want and what we want. If our work product is exceptional and its benefits irrefutable, then consensus will follow.
Well, I don't know - we only need to look at how things really are (which is going to be controversial along some).
Ideally that would be the case admittedly - but we've seen a number of incidents, where even popular contributions would not be accepted upstream i.e. in terms of lacking a discussion/review and ultimately committing such work, because a few core developers didn't believe in pursuing a certain route/approach. Sometimes, it unfortunately takes a little time for those efforts to make it into FlightGear, and increasingly, contributors are getting fed up with the lack of response/feedback and action, so that they give up "too early" (latencies being measured in months and sometimes years).
However, there are counter-examples for this, such as the local/advanced weather system, which is much more compelling than the basic weather system, and which ended up being committed, without any formal code/peer review at all - in fact, it was even committed by a senior core developer who never committed, let alone developed, any scripting space features at all - so as long as people can convince/impress more senior contributors, there still is a chance to get stuff committed, despite significant opposition from other developers.
Likewise, had Zakalawe (James) not been around in early 2012 and actively supported TheTom and his efforts on providing a 2D rendering API back then, Canvas would very likely still be an external "patch", analogous to how osgEarth has been lacking broad acceptance and support from core developers so far. And we have many other examples of contributions, and contributions, of exceptionally high quality that never made it into FG so far, despite their entirely optional nature (e.g. consider the Bombable code).
I guess I feel like as long as the core developers hold the reins to the project then it is their responsibility to steward it in the most proficient and professional manner possible. Accordingly, they should be transparent in intent and I think they need to constantly communicate the projects direction regularly. The infrastructure for this is already available by way of the monthly news letter. But I guess were back to who is willing to take the time to summarize all the pertinent discussions over the course of the last evolution.
I'd say there are several factors involved here, spare time definitely being among them - but also experience/expertise and willingness to speak in an authoritative fashion on to actually present ongoing development trends. Just think about it - we keep seeing discussions about a "long-term roadmap" - the most recent example being this: 5-10 Year Goals?
So, basically people (including contributors) are very much interested in learning more about the direction in which the project is headed.
But there are very few people who want to commit to anything, in terms of concrete roadmaps and plans.
The only thing that has kind worked pretty well so far is actually individual developers presenting/maintaining their own roadmaps.
Equally, the priority of items on such "roadmaps" can be measured in terms of past, and especially, current FG involvement.
And honestly, there really isn't much else that counts beyond actual involvement, especially the degree of spare time "donated" to FlightGear.
Time has proven over and over again that the amount of spare time available is even more important than just "skils" and "expertise".
There are some enormously experienced contributors subscribed to the devel list, some of whom having exceptional credentials, including some holding multiple PhDs, some having made sizable contributions to the project at some point, but many/most of those have meanwhile primarily become "lurkers".
In contrast, there are some relatively uneducated, but really clever, individuals involved who have one major benefit: a lot of time on their hands. This usually applies to very young contributors, e.g. those just attending highschool or about to go to college. We've seen some of these people literally "graduate" into major FlightGear contributors over time.
Meanwhile, you could say that some of the most senior contributors also had their most active phase back when those criteria applied to them as well, i.e. being young, having plenty of time on their hands and not much in terms of obligations going on.
The fact is, FlightGear core developers generally acknowledge that the number of active core developers is far too low to properly maintain FlightGear. Some of the most senior core developers have either opted to manage other projects/infrastructure meanwhilee (think website, forum, wiki etc) or are busy with other aspects of their lives.
So FlightGear has kinda failed recognizing that a rejuvenation project is long overdue, and that it's indeed young contributors, those with a ton of time and motivation/dedication, that can realistically shoulder the project, while the older ones should resort to mentoring every now and then. This is something that Curt also touched on in one of his recent interviews about the FlightGear project: mentoring is an important part of managing a project, while still getting to delegate and direct ongoing development, without necessarily having to be as involved anymore:
http://www.flightsim.com/vbfs/content.p ... FlightGear
So far, FlightGear hs unfortunately failed at dealing with these challenges, i.e. more and more of the senior contributors having to take a backseat, while more and more younger developers are feeling left out of the loop, because their contributions aren't even considered for inclusion, equally they are not considered for getting commit access either.
Likewise, FlightGear as an OSS project has generally failed at recognizing the potential of attracting professional contributors, i,e. those doing contract work, or those using FlightGear professionally - i.e. those making a living using FlightGear on a daily basis, or even just temporarily. For example, this includes people like poweroftwo who were once contracted to implement osgEarth support in FlightGear, and who is obviously enormously experienced and qualified, while also willing to help integrate and maintain his work - yet, it's taken over two years meanwhile for his work to be recognized as what it really is.
There are, and used to be, other people who eventually became core developers/committers through contributions that wouldn't require the skills and background that the osgEarth integration took, yet, we're seeing skilled contributors not being accepted into the inner circle of core committers, despite a handful being definitely available - and even willing to help younger contributors, i.e. those with plenty time on their hands.
In other words, while core development is very much a recognized "bottleneck", there's very little if anything being done about it. Aspiring core developers are feeling left out of the loop, no matter if their motivation is due to a corresponding professional or hobby/private background. And even former core developers are referring to the devel list as an "unfriendly place" these days given the atmosphere there.
Given the current situation, there really is very little that you can do about this, e.g.:
implement all the features yourself
asking others to do it for you
helping others interested related features implement those via pointers
1:1 mentoring
documenting how to develop certain features
providing infrastructure/APIs and frameworks to establish best practices
establishing rules/roadmaps and actually committing to handle recurring chores/duties (think release plan, reviewing merge requests/patches, maintaining infrastructure like the wiki, forum, issue tracker)
Overall, this is much more about project dynamics and social dynamics than about conscious project management.
We have many type-B personalities involved in the project, and a few type-A personalities who are easy to identify.
Obviously, many type-B personalities are seeking guidance and direction, and type-A personalities will gladly provide exactly that, without others necessarily agreeing.
Equally, some Type-A personalities will gladly do anything in order not to get contributors involved who appear to be standing in conflict with their own agendas, i.e. exerting "control" by not welcoming certain contributions and contributors, despite those deserving a place in the FG eco system under different circumstances.
Creating documentation and frameworks/platforms still is a fairly sure way to still "mentor" people without necessarily having to be "appreciated" or even without having to be actively involved/around at all, as could be seen by a number of recent developments that were kick-started by contributors who never made it into the inner circle of core developers.
So FlightGear as a project is still working, but without many people realizing why that is so, and how to use those dynamics to their advantage.
We have people interested in getting involved in FlightGear core development that have credentials and professional backgrounds that are hardly matched by the few remaining/active developers - so have even provided patches/merge requests or topic branches where no active contributor felt sufficiently qualified to review/merge and commit such work, which is another unfortunate and unnecessary common trend.
Back in the early days of the FlightGear project, back when CVS was still used, granting commit access would be considered based on someone's contributions, and if someone contributed patches to an unmaintained area, that someone would be considered a potential new maintainer - these days, a patch targeting an unmaintained component, renders the whole contribution useless, and the aspiring developer is no longer considered a potential future maintainer/FG core developer.
Thus, the underlying problem is not just lack of core developers, but lack of gitorious admins willing to regularly review the current situation and nominate new contributors to become core developers.
This isn't unlike having wiki/forum admins/moderators - and it isn't unlike the release plan: all of these are basically "additions" to the existing infrastructure, where people would commit to handle certain chores/duties semi-regularly, no matter if that means helping moderate the forum/wiki or helping preparing release candidates twice a year.
Those were major additions to FlightGear, as can be seen by comparing the predominant situation in the "pre-release plan" time when a single person would handle such duties.
Equally, the monthly newsletter works pretty well for something that people don't want to commit to.
So what is needed to tackle the current core developer shortage is adding a new policy to officially nominate core developer candidates 2-3 times per year, based on contributions made by non-core developers, especially in terms of active involvement. Unfortunately, nothing like this is in place - so that there's ton of potential core development manpower going wasted.
Obviously, unmaintained core components/areas should get higher priority than those having an active maintainer involved.
Maintaining contributor-specific roadmaps/todo lists also seems to work exceptionally well to help present the direction of the project based on developer involvement, i.e. traditionally heavily involved core developers like Zakalawe and TheTom tend to commit to roadmaps that actually present where the project is headed, while others much less involved primarily state ideas and features requests, without committing to working on those.
FlightGear, and especially core development, could be in a much better shape than it really is if we could establish a formal way to conduct core developer polls bi-annually, while also establishing a way to actually mentor new developers in terms of what to work on and how to proceed with certain developments. Equally, not leveraging all those "young" and "professional" contributors is a huge waste of potential developer manpower, with very little to be gained - especially by those simply opting to just "veto" developments, without themselves being as involved in FlightGear as some newcomers obviously are. Particularly, if those developments are actually features popular among community members (think osgEarth, better Nasal GC scheme etc)
You only need to look at the history of the project, its major contributors over time and their backgrounds to realize that .... "it's no country for old men" 
A FlightGear fork dealing with these challenges by lowering the barrier to entry and getting those involved with plenty of time on their hands or those with professional stakes, possibly via github, could easily become much more relevant than FlightGear is meanwhile - especially if kick-started with contributions and contributors who are currently de-facto rejected by the "core" of remaining core developers who more often tend to veto or criticially discuss patches/merge requests, despite not having any visible track records of providing the same quality of contributions they're now asking others to provide.
Statistics: Posted by Hooray — Sun Feb 08, 2015 5:38 pm