Alant wrote in Sun Jan 10, 2016 11:43 pm:I would be surprised if fgplot's author was not more than a bit pissed off by the actions of the core developers involved in this process. It was not far short of being disgraceful..
frankly, I don't think he particularly cared about it being committed - he did put up 2-3 merge requests according to the archives, but at some point simply moved on apparently.
Also, in all fairness, pure fgdata related commits don't have much to do with core committers necessarily - i.e. they can be reviewed/merged and committed by any fgdata committer.
i think it's more an unfortunate turn of events and different priorities/schedules.
Just look at the number of other merge requests that might have made it if the corresponding people had been a little more proactive, especially with regard to the release plan and deadlines (feature freeze).
So this does not have to do much with core developers being generally "overstretched" in terms of their responsibilities, but it's more about none of the fgdata committers generally feeling confident to help review merge requests that are unrelated to their own aircraft.
Obviously, that's just my 2cents ...
It is however true that there is an increasing number of optional sg/fg and fgdata patches that never make it into any of the upstream repositories, and I think this has more to do with a general lack of manpower (and project guidelines) than with any particular group of contributors.
I really have no reason to sugar-coat any facts here or to misrepresent the state of things.
Like I recently mentioned in the
FlightGear Development Push thread, you cannot real blame any fgdata or core committers for such incidents.
What is really needed are updated guidelines to deal with new contributions,
and contributors - and that has more to do with having a sufficient number of active project administrators who are able, and willing, to add new contributors, with commit privileges, to the sourceforge project - to help ensure that there will be a steady supply of fresh blood, and features.
Otherwise, we are probably going to see more and more features put up for review that simply add to the workload of those few remaining contributors who are willing to help peer-review new additions, which inevitably means that the project needs to make concessions elsewhere.
And quite frankly, I also don't remember if I offered any help to get the corresponding Nasal/Canvas code reviewed - despite being probably in a pretty good position to help doing so, unlike most others (including most active core/fgdata developers).
So it is far too easy to yell at others who didn't respond to such merge requests, while ignoring that all of us can help and do our share to get things discussed ,reviewed and committed - which is far easier for fgdata level additions than core patches obviously.
It is however unfortunate that we are seeing so many features that don't make it back into the project, despite many representing dozens, if not even hundreds, of hours of work.
And I would hope that we as a community can find a way to address such challenges sooner or later - or people may get the impression that we don't particularly care about their contributions and will just move on, for good.
And that would be a pity for the FlightGear project, not so much for the people ...
But as far as I remember, fgplot not getting committed was more due to it being put up for review during the feature freeze, and some of it getting lost during the subsequent sourceforge transition.
So I reckon, that other contributors are more likely to be irritated by the whole "review process" than the fgplot developer.