[Flightgear-devel] Roadmap / development focus (was Independent view windows)

[James T. <ja...@fl...>]

> But insofar as it might look like i'm moving quickly, that's actually a
> good thing. It's much more efficient to get things done quickly in a
> few weeks or months, than have them drag on for years. And the
> potential benefits we get with an improved viewing system will be
> really significant.
> 
> With free software one has to rely on developer enthusiasm for getting
> things done, and this doesn't always last forever and doesn't always
> match up with roadmaps.

With apologies to Jules, he touched a bit of a nerve with this, which I wanted to elaborate on: 

While it is certainly good for developer enthusiasm to work solidly on a new feature, it doesn’t always help end-users much. Or rather, the things that help end-uses most, are typically not very fun to work on, which is a problem.

Personally I spend 80% (or some weeks, 100%) of my FG development time doing merging, reviews, build management, checking translations, and looking at bug reports or feature requests. I’d love to only spend 50% or 30% of my time doing that : since personally I would be very enthusiastic about working on VSG support (being on macOS, I also have the most to lose / gain from it). But I don’t think I can stop doing bug-fixes, releases, or merge requests, or code-reviews. And all those things have someone asking, or nagging, to get their thing added / fixed / unblocked. (And filling up my Inbox…)

So it’s lovely to be able to rapidly spike a feature to the point where it’s somewhat working :  that is a nice way for a developer to work. But it doesn’t service ’the project’ in a helpful way, while that is happening. So only some % of development effort can look like that: there also has to be a certain amount of doing the boring stuff that needs to be done to keep the project alive and stop end-users getting frustrated.

Right now, we’re trying to stabilise the 2020.2 branch, and there are 200+ tickets against that branch (or older ones that might still apply), which should at least be checked, ideally investigated in detail, and optimally fixed. It’s hard for me to draw a line to say ‘when there’s less than 99 bugs, I’ll stop looking at them and switch to doing something I am enthusiastic about': but even if we could, new bugs and feature requests and data updates and merge requests keep coming :)

We could try to make a rule like, for each new feature you add, you have to investigate & close 25 bug reports … but, well, that’s kind of arbitrary … and not great for people’s enthusiasm either.

> 
> [
> Speaking of which, where is the long-term roadmap?
> 
> The only things i can find are both 4 years old -
> http://wiki.flightgear.org/FlightGear_Roadmap <http://wiki.flightgear.org/FlightGear_Roadmap> which was last modified
> 13 May 2016‎, and
> https://www.flightgear.org/flightgear-policy-document/ <https://www.flightgear.org/flightgear-policy-document/> which says 'This
> is the road map for the 2016.X releases’.
> ]

In one sense, there’s no long-term roadmap, because it’s driven by what people actually have enthusiasm+time for, which often does not correspond to a previous plan. We often discuss longer-term directions at FSWeekend, although it depends how much beer has been consumed :)

The wiki has historically not been a great place for tracking such things, due to, uh, 'creative’ edits. This means the signal/noise ratio tends to vary rather drastically.

In terms of the practical roadmap, the big items I would say are:

	1) WS 3.0, using VBP and the new pipeline Scott and others are working on

	2) removing legacy OpenGL code (PUI, HUD, 2d panels, porting Canvas away form ShivaVG), so we can switch to Vulkan/VSG at some point (ideally at some point before Apple turn off OpenGL support…)

		I’m working (exceptionally slowly!) on the PUI part, and Henning will look at the HUD part later in the year. I think Gaetan is very kindly looking at the WIP branch I shared on the 2D panel front, and I have co-erced a colleague of mine at work into using some of our ‘education time’ work allowance to check out NanoVG and other rendering options for Canvas. 

	BTW, all of these are examples of ’not very enthusiastic’ things: I don’t think /any/ of us *want* to be working on these features particularly, but they need to be done before anyone can have fun with VSG or Vulkan. Sometimes that’s just how it goes. Equally they will all benefit the project ultimately, but the payoff both for the individual and the project is very drawn out. 

	3) I think Richard has a cunning plan to overhaul MP at some point but I’ll let him speak about that if he wishes.

Kind regards,
James