Release plan/Lessons learned

This is a list of lessons learned from the previous releases, things that turned out well and should be kept for the next release as well as thing that didn't turn out so well and should be changed for future releases. Ideally, the release plan should be updated and augmented so that the lessons learned are incorporated accordingly.

General

As mentioned by Curt on previous occasions, one of the more labour intense parts of managing a release consists of the compilation of a comprehensible revision log that lists the major changes / improvements to FlightGear. I would appreciate it if somebody would give a hand in compiling such a list. — Durk Talsma (Oct 5th, 2008). [Flightgear-devel] Revision Log / Intended developments. (powered by Instant-Cquotes)

We normally highlight particularly exciting new and improved aircraft, but I have struggled to keep up with the rapid pace of development. Please let me know of any particular aircraft that you think should be included. To qualify they must be in FGDATA, and must have been introduced/improved significantly — Stuart Buchanan (Jan 18th, 2013). [Flightgear-devel] 2.10.0 Changelog - help required. (powered by Instant-Cquotes)

• I'd instead suggest that aircraft making an incompatible change add a version tag to their data files and discard data files without it. (We could also have a "delete data files on aircraft upgrade" (not core-FG upgrade, aircraft aren't required to have the same release cycle as core FG) *option*, but the aircraft developer should be able to choose whether they want it.)

• the best thing would be for aircraft to version their data files individually

• FG should save data files also when a user presses the X button in the window decoration, not just when the user goes to File > Exit > Yes

• When FG initialies itself after the version number has changed, it should either delete old data files (because new aircraft might be incompatible) or somehow migrate the data file (IIRC the issue resolves itself if the user exits via File > Exit > Yes, so possibly FG could load the aircraft, shut it down in order to save a new data file, and then reload new data)

• if an aircraft defines all possible properties in the protocol, it tries to send 14988 bytes per packet, almost 12.5 times the allowed limit! Your idea of sending properties in a round-robin fashion is good IMHO but good MP debugging tools are necessary for aircraft developers.

2016.3

• I would much prefer we solve this by generating new apt.dat offline and distributing them, rather than ending up with a large number of small apt.dat files, which is not what the maintainers of the main file expect.

• integration of the maldives scenery took an afternoon to complete. Maybe we can come up with a scripted/automated solution if this should be required again. Is there any format this could be submitted which would be easier to incorporate, or is the issue really that the sequence takes too long due to sie? I guess if there's an input format that makes life easier, we could publish it and encourage people to meet it.
• Regarding the 2016.3.1 RC I've noticed that initialiing subsystems takes a lot longer than in earlier versions of flightgear(1 minute or more compatred to 10 or 15 seconds).

• We should probably download a new catalog for each new version upon installation or first run, or at least check the date. I had an out of data catalogue and had to refresh manually.

• Are there any remaining changes required to use the new default aircraft catalog: http://mirrors.ibiblio.org/flightgear/ftp/Aircraft/catalog.xml

• The whole "navdb build thing" is proving to be the single most problematic feature added in the last couple of years affecting potentially all users, because unlike most additions, it's not an optional thing, i.e. it must be executed, and is needed for FG to work - given that, it would really make sense exploring to ship a pre-built navdb with future FlightGear releases, or at least factor out the corresponding code so that it can be provided as a standalone executable that is shipped as part of fgfs, so that it can be executed by the installer, without fgfs being affected by it inevitably - that way, troubleshooting related issues should also become much easier, in addition, this separation would facilitate having sync'ed navdbs across multiple instances (think virtual ATC, multiplayer, combat simulation, or even just a fsweekend/linuxTag-like setup). This work would also greatly facilitate turning the navdb into a HLA/IPC-enabled service one day.

• would it be possible (for the next release) to put startup defaults/properties in a startup-preferences.xml file and include it in preferences.xml. That would probably make it slightly easier to maintain and may be a start for an automatic update script which automatically generates startup-preferences.xml

2016.2

Catalogs

• We need to come up with a solution that doesn’t require me to remember to make a new symlink every time the version number changes, i.e. have a script that checks the version file in fgdata... when that file changes, the catalog symlink is created... if needed also add a new version tag to the catalog file... looking at the current version strings, we're apparently good to go until 2017... which fgdata to look at? perhaps the one that jenkins builds for the release packages? if the symlink already exists, of course do nothing...

Model Organization

We need to find a better way of organiing models for one of the following releases.

The status which prompted the change was that we had two databases for models - FGData and Scenemodels. At the same time, we had four (at least) use cases for models - static scenery models, shared scenery models, random object models and common models referenced by aircraft. And everything got mixed up somehow.

2016.1

Codenames & Standard Airports

See FlightGear Versioning Scheme based on Airports for the main article about this subject.

• https://forum.flightgear.org/viewtopic.php?p=11381#p11381
• https://forum.flightgear.org/viewtopic.php?p=244430&hilit=ksfo+default+release#p244430

part of the discussion was also that the release will be known as 'San Francisco' for the default airport. And that we will change the default airport (and the name) for subsequent releases. — Thorsten Renk (Feb 10th, 2016). Re: [Flightgear-devel] i think 2016.x.x is a bad name. (powered by Instant-Cquotes)

I feel Gatwick would be a nice place for a start. Schipol, though nice, would negatively disturb Omega's professional ATC. Maiquetia is certainly the most detailed airport in South America, in terms of detail; it is pretty nicely modeled by viveFG. Of course, I wouldn't be too happy about my airport being full of KSFO people, but then, it would be a nice showcase of what can be done in Blender and WED, as well as Gilberto's beautiful textures. For Asia, Kansai Intl promises to be very nice, but it would be better to wait till at least August, due to the Japan Festival in May. For North America... hmmm... LAX is always there; then there is JFK. The JFK terminal and layout could possibly use some updating; at least, Terminal 4 is incorrect, and I believe some newer taxiways are missing. — Jonathan Redpath (Jan 6th, 2016). Re: [Flightgear-devel] Release preparations. (powered by Instant-Cquotes)

Given the international flavour of our community, I'd suggest somewhere outside of North America for this release, but probably not Frankfurt or one of the airports that regularly hosts serious ATC services. I'm not particularly familiar with what airports have been developed, so I don't have a suggestion to make. A couple of related questions: 1) I assume we are going to include scenery for the selected airport within the release package? 2) The Cessna in-sim tutorials and the cross-country tutorial in The Manual are based around KSFO. Would we want to continue so ship some KSFO scenery with the release to avoid users having to download those areas? — Stuart Buchanan (Jan 7th, 2016). [Flightgear-devel] Airport Choice for 2016.2 (was Re: Release preparations). (powered by Instant-Cquotes)

To have enough time to prepare this, I'd like to make our first release the "San Francisco" edition. — Torsten Dreyer (Jan 6th, 2016). Re: [Flightgear-devel] Release preparations. (powered by Instant-Cquotes)

This is definitely becoming one of the most completely modeled locations in FlightGear, guess we should seriously consider making it the default startup location for the next release — Hooray (Dec 4th, 2010). Re: LOWI airport. (powered by Instant-Cquotes)

I'm just curious, any significance to using KSFO as a default airport starting or it's just chosen at random? — HJ1AN (May 26th, 2015). Reason for . (powered by Instant-Cquotes)

I proposed to rotate the default airport each major release to give other airports some exposure. Hence we could use the corresponding airport name as the release name, i.e: 2016.1 ‘Gatwick’ 2016.2 ‘Innsbruck’ 2017.1 ‘Finkenwerder’ 2017.2 ’Schiphol’ .. and so on .. I’m not suggesting to implement this change for 2016.1 of course - it needs some tooling changes to adjust the default scenery which is non-trivial. And no one really seemed that interested last time, so perhaps I am the only person who likes this idea anyway! — James Turner (Dec 19th, 2015). Re: [Flightgear-devel] Relesae 3.8. (powered by Instant-Cquotes)

I second that. Over the years FG has seen some pretty dedicated scenery builders at work. It would honor their steady effort to create these great alternatives to KSFO. — Frans de Vre (Dec 19th, 2015). Re: [Flightgear-devel] Relesae 3.8. (powered by Instant-Cquotes)

+1 on this idea. It nicely addresses several issues. — Gary Neely (Dec 19th, 2015). Re: [Flightgear-devel] Relesae 3.8. (powered by Instant-Cquotes)

do like the idea of rotating the default airport and the code naming the release with that airport name. That's pretty clever and cool I think. — Curtis Olson (Dec 19th, 2015). Re: [Flightgear-devel] Relesae 3.8. (powered by Instant-Cquotes)

It is a cool idea and I think more than a few people liked it last time - the stumbling blocks I remember were the fact that the manual (TM) specifically assumes that you're at KSFO and would have to be re-written - and that it was close to impossible to agree on an airport for us :-) — Thorsten Renk (Dec 19th, 2015). Re: [Flightgear-devel] Release 3.8. (powered by Instant-Cquotes)

Yes, that is a neat idea. I suggest to make a 2016.1.1 'San Franciso' in January and start a poll for the location of 2016.2.1. One little detail question: What's the number of the first version in a year? Do we count geek-style/ero-based or natural/one-based (2016.0.1 or 2016.1.1)? I have a tiny tendency towards one-based to start with 2016.1.1 for the release and make current 'next' v2016.0.0. — Torsten Dreyer (Dec 21st, 2015). Re: [Flightgear-devel] Release 3.8. (powered by Instant-Cquotes)

3.6

ChangeLog automation

There are two manual steps that I usually perform: 1) Generating the latest version of the manual 2) Writing the release note Frankly, updates to the Manual are currently limited to checking that all the menu items are described and incrementing the version number. The latter could be automated by Jenkins I suspect. Writing the release note isn't a massive amount of work, and given that there will be 3 months of logs to check rather than 6, should be a bit less work per-release. — Stuart Buchanan (Nov 19th, 2015). Re: [Flightgear-devel] Some thoughts about the release process. (powered by Instant-Cquotes)

For the release notes - well, we could prepare some prettyfied git-log if that helps. — Torsten Dreyer (Nov 20th, 2015). Re: [Flightgear-devel] Some thoughts about the release process. (powered by Instant-Cquotes)

Jenkins (build server)

Could we have Jenkins continue to build from the release branch after the release is made and copy those to SourceForge as well? That would allow us to easily deliver critical fixes found in a release. — Stuart Buchanan (Nov 19th, 2015). Re: [Flightgear-devel] Some thoughts about the release process. (powered by Instant-Cquotes)

Jenkins will do the release-number handling anyway. Probably we can just include the version file into the latex compile process? — Torsten Dreyer (Nov 20th, 2015). Re: [Flightgear-devel] Some thoughts about the release process. (powered by Instant-Cquotes)

Review & optimize the release plan ?

You're basically advocating offloading much of the testing to the broad public. In the short term, I agree this is likely to increases the total manpower behind the project. However, it's equally clear that it will decrease release quality - short term at least. — Markus Wanner (Nov 19th, 2015). Re: [Flightgear-devel] Some thoughts about the release process. (powered by Instant-Cquotes)

My personal experience with relaxed release processes is rather negative. And I don't think release-early-release-often means one shouldn't differentiate between releases of different quality (i.e. beta, RCs, stable). But then again, I'm a Debian Developer. I'm clearly biased. — Markus Wanner (Nov 19th, 2015). Re: [Flightgear-devel] Some thoughts about the release process. (powered by Instant-Cquotes)

I can barely keep up packaging two releases per year for Debian. I certainly can't do four. So I'd have to decide which ones to pick.[...]I'd appreciate fewer releases with higher quality, rather than the opposite. — Markus Wanner (Nov 19th, 2015). Re: [Flightgear-devel] Some thoughts about the release process. (powered by Instant-Cquotes)

When we started the release plan, I had much time during summer/winter holidays. If I had to do it again, I would have avoided thoses seasons. — Torsten Dreyer (Nov 19th, 2015). Re: [Flightgear-devel] Some thoughts about the release process. (powered by Instant-Cquotes)

"Release early, release often" is result of other peoples experience and so is the idea behind "Agile" development where you create something potentially deliverable every 2 weeks. To be honest, I was even thinking about having monthly releases. Given the relative low number of contributors at the moment, I just expected that we'd create subsequent releases with no change but the version number. — Torsten Dreyer (Nov 19th, 2015). Re: [Flightgear-devel] Some thoughts about the release process. (powered by Instant-Cquotes)

The major flaws I've perceived in the release processes I have witnessed are a) release candidates came out too late, giving barely a week of testing and feedback, not enough time to do fixing b) users not adopting and testing the release candidate with the argument that they'd 'wait for the stable version' c) real life of many people (especially during summer holidays) interfering with the ability to deal with bug reports — Thorsten Renk (Nov 19th, 2015). Re: [Flightgear-devel] Some thoughts about the release process. (powered by Instant-Cquotes)

one of the things we've encountered in past release cycles is that it seems like it takes some extra effort (James?) to configure Jenkins to do release candidate builds, and because of that we often haven't had release candidates until very late (i.e. days before the official release, sometimes after.) But if Jenkins can automatically build release candidates, that would be wonderful. — Curtis Olson (Nov 17th, 2015). Re: [Flightgear-devel] Some thoughts about the release process. (powered by Instant-Cquotes)

Today, thanks to James, Clement and Gene, we have Jenkins that basically creates a complete release after every commit in our source repository. Because of this and because human resources have become more precious than ever, I'd like to discuss a new release plan for FlightGear here. — Torsten Dreyer (Nov 17th, 2015). [Flightgear-devel] Some thoughts about the release process. (powered by Instant-Cquotes)

The steps required to release a software product are usually quite intense and take a -lot- of time. There were also Northern hemisphere holiday related delays. The release process is ongoing, but patience is required — bugman (Sep 8th, 2015). Re: FlightGear 3.4/5/6/7 - please help me understand. (powered by Instant-Cquotes)

Because creating a release requires that certain people do certain things and that the last show-stopper bugs (e.g. is the Mac build ok now? The Windows build?) have been solved. All by a small number of people (some quite non-interchangeable due to limited access to certain resources) working on their spare time. — AndersG (Sep 8th, 2015). Re: FlightGear 3.4/5/6/7 - please help me understand. (powered by Instant-Cquotes)

there is currently no defined status of 3.6 due to lack of (human) resources. Some of us have thought about refactoring the release schedule due to the fact that a freee around christmas and a release during summer holidays is very unfortunate. So far, there are no clear results from these thoughts available. The entire process is somewhat volatile at the moment. Sorry for any inconvenience that may cause. — Torsten Dreyer (Nov 9th, 2015). Re: [Flightgear-devel] Status of Release 3.6. (powered by Instant-Cquotes)

I just know from other conversations that quite a few people are on holiday. I guess we'll just have to wait. Maybe trying to do a summer release is a bit awkward in the first place and we should reconsider the idea? — Renk, Thorsten (Aug 25th, 2015). Re: [Flightgear-devel] FGAddon freeze for 3.6?. (powered by Instant-Cquotes)

In general, I see there being two fundamental approaches for the approach to the release. First, time based. Target a date and taint that date with a realistic set of hoped for features, what is ready is what is ready. What is not, slips to the next release. Second, feature based. Target a set of features, allowing it to be tainted with a reasonably realistic date. When the features are complete, the release is made. Which is preferred approach for those on the list? Can I suggest a wiki page to provide a focus for burning down issues prior to the release? — Matthew Tippett (Oct 13th, 2008). [Flightgear-devel] Towards a release - Re: Revision Log / Intended developments. (powered by Instant-Cquotes)

Code names instead of version numbers?

What happened to the idea of naming releases after an airport/a scenery? I rather liked that — Thorsten Renk (Jan 6th, 2016). Re: [Flightgear-devel] Release preparations. (powered by Instant-Cquotes)

Just a cray random thought, perhaps, like many other software we could add a codename for each release. It could be a just-for-fun thing, or you could think of it as a way to divert the attention away from the version number, just in case you don't like the number. — Pigeon (Nov 30th, 2007). Re: [Flightgear-devel] Informal version number poll. (powered by Instant-Cquotes)

People also seem to assign expectations to a product based on the way it's version number looks. Commercial companies realie this and try to leverage it to a competitive advantage (my version number is higher or better than your version number!) FlightGear doesn't compete commercially so we don't have to play dumb psychological games with consumers -- we could, we just don't have to if we don't want to. — curt (Feb 27th, 2013). Re: the way each version is numbered is confusing. (powered by Instant-Cquotes)

the accomplishment of switching from 1.x to 2.x and to 3.x still does mean something to many people, not just FG "outsiders" (or new users), but also long-term contributors, as was mentioned by Torsten on the devel list: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38888.html — Hooray (Feb 27th, 2013). Re: the way each version is numbered is confusing. (powered by Instant-Cquotes)

why not call it flightgear 2013.... and flightgear 2014 ? — Bomber (Jul 7th, 2013). Re: Clouds. (powered by Instant-Cquotes)

the whole major/minor concept is clearly irritating to people not familiar with software development and labeling schemes, which is why software is often versioned using code names or simply years: FlightGear 2013-1 or FlightGear 2013-2, FlightGear 2013-ALPHA or FlightGear 2013-BRAVO — Hooray (Feb 27th, 2013). Re: the way each version is numbered is confusing. (powered by Instant-Cquotes)

Ultimately, it probably isn't worth the hassle - and we should identify the whole scheme as a bottleneck and come up with something less prone to interpretation and subjective opinions, i.e. having releases in the form of "FlightGear 2013/1" or "FlightGear 2013/2" - or even just code names. — Hooray (Jun 23rd, 2013). to put things into perspective .... (powered by Instant-Cquotes)

"first impressions" would be hugely different if we were to start an orchestrated effort to bundle our most-developed features (aircraft, scenery, addons) together, instead of offering an infinite number of more or less developed options to our end-users. We have some extremely well-developed aircraft and scenery, such as the Seneca, the 777 - France, LOWI. It would just be a matter of packaging these as "positive examples" for a release - even if that would just be a downstripped "preview" release, it would go a long way to demonstrate what FG is capable of: Help needed - market research for FG post on the forum — Hooray (Jan 24th, 2013). Re: Help needed - market research for FG. (powered by Instant-Cquotes)

in terms of making some of our more advanced aircraft/airports more prominent. I think I read about this on the wiki: For instance, we are currently having two releases per year. But we've been using KSFO/c172p as the standard startup settings for many years. Personally, I would think that it would be a great incentive for aircraft and scenery developers if we could have polls prior to each release phase to determine which airport/aircraft is going to be the defaults for the next release. For example, just look at all the fantastic work done for LOWI - or amaing aircraft like the Seneca. I could imagine we could make such work more prominent by changing the defaults for each release accordingly. And we could then also change our release naming accordingl: FlightGear 3.2 (LOWI/Seneca) That would go a long way to demonstrate to NEW users that we really have AWESOME scenery and extremely well-developed airports. The current situation works such that only the "insiders" know about such things, and know how to download/install/configure everything. And the screen shot competitions that we've had also demonstrate that we have an active community interested in contributing to polls. So why not use polls AFTER each release to directly determine which aircraft/airport will be featured in the upcoming release? That would give us plenty of time to focus on the corresponding scenery/aircraft, and to give other contributors a chance to even improve things further. — Hooray (Nov 13th, 2012). Re: Help needed - market research for FG. (powered by Instant-Cquotes)

Scenery versioning

It is a bit of a mess, Martin had his own way of doing things and didn't really seem to care about or pay attention to the FlightGear release cycle so our numbers got out of sync. I can try to take a look at this over the weekend.... — Curtis Olson (Oct 23rd, 2015). Re: [Flightgear-devel] Scenery versioning. (powered by Instant-Cquotes)

I'm thinking with things the way they are, pages created and databases mirrored around the world it might be clever after the rebuild of the scenery that will replace the current 2.0 scenery, to go back to the version-of-FG numbers, simply because, like said the enormous work of the past and because that number will always be linked to when the scenery was/is created. I understand that simgear and flightgear are sync'd in such a maner. — Ray St. Marie (Oct 26th, 2015). Re: [Flightgear-devel] Scenery versioning. (powered by Instant-Cquotes)

unlike FG and SG which have strong dependencies (try compiling FG 3.7 against SG 2.12 and see what happens), the scenery-core dependency is much weaker - FG 3.7 will actually run fine with the scenery from 2.12 (that would be World Scenery 1.0.1 I guess). So there's no need to update the scenery version number when it really hasn't changed, and scenery versioning can reflect actual re-builds for clarity. — Thorsten Renk (Oct 26th, 2015). Re: [Flightgear-devel] Scenery versioning. (powered by Instant-Cquotes)

3.4

PUI fonts affected by features using effects/shaders (Rembrandt/ALS)

Note  Also see ticket #1730

I notice that the first item in flightgear menus is missing if I use the property sim "--prop:/sim/rendering/multi-samples=3", — Curtis (Wed Apr 01). Missing label menus if /rendering/multi-samples is enabled. (powered by Instant-Cquotes)

This is something to do with the builtin bitmapped font and shaders as it affects me when I have either rembrandt or ALS turned on; If you change the gui current style in either preferences or autosave to 0 it'll use a real font which fixes it mostly (there are still certain elements in the GUI such as MP Pilot list that use the builtin font) — Richard (Thu Apr 02). Re: Missing label menus if /rendering/multi-samples is enabl. (powered by Instant-Cquotes)

Scenery not loading

it just says "Loading Scenery" and doesnt load. — JackT44 (Mon Mar 09). Why is my Flightgear still saying Loading Scenery?. (powered by Instant-Cquotes)

Selecting Parking Positions

not able to choose under menue Select an Airport /Aircraft Position /Parking an exist Parkposition. For example, select the airport EDDF. Under Aircraft Position you choose Parking positions. Set the cursor in the yellow case and you got the announcement " Parking position not found ". — D-ABBA (Sun Mar 08). 3.4. Selecting airports...Aircraft Position.... (powered by Instant-Cquotes)

Qt5/Mac launcher debate

Related to Qt, I can say that up to now - as far as I can tell - only a simple replacement for the Mac Launcher has been introduced. This is not related to the internal user interface of FlightGear, at least for now. If, how and when the internal gui can leverage Qt is under investigation and in such an early state that those responsible preferred to not announce anything yet. If this ever happens, this will be discussed on the mailing list — Torsten (Sun Jan 11). Re: FlightGear GUI hell: PUI, Canvas GUI, Mongoose, . (powered by Instant-Cquotes)

Mid-term Project Goals?

Has FlightGear got a list of goals for 5-10 years? How about making or adding to it? — legoboyvdlp (Tue Jan 13). 5-10 Year Goals?. (powered by Instant-Cquotes)

One of my observations as an observer with just enough knowledge to understand the situation, from a distance, is that it would be extremely helpful for this project to come to some kind of a consensuses. This free-for-all is confusing and counter productive. Even if a few, or many, core developers know what is going on and are in lockstep, it is very disheartening to contemplate helping or contributing to anything "major" as you have the appearance of no consensuses. I see advertisements for needed help everywhere I look, but many are not willing to spend significant time on anything that may be in vain. — wlbragg (Thu Feb 05). Re: Aircraft center: . (powered by Instant-Cquotes)

Following on from the recent discussions about git/svn and attribution on the -devellist, and discussions about the structure and the future of the project on the forum, the group of developers who get together on a weekly Google Hangout organized by Curt realized that we would benefit from a more detailed policy document and roadmap than the high level statement available at http://www.flightgear.org/about/. There is a draft document circulating on the -devel list (http://sourceforge.net/p/flightgear/mailman/message/34183645/). If you'd like to comment and take part in the discussion, please subscriber to the -devel list — stuart (Jun 8th, 2015). FlightGear Policy and Roadmap Documents. (powered by Instant-Cquotes)

FlightGear on 32 bit Windows

The point I am getting at is we have a ton of 32 bit windows users trying to download and run FlightGear. Out of the box with the startup defaults that pretty much doesn't work right now. This is leading to a ton of bug reports, a ton of frustrated new users, and a general perception that FlightGear is a POS that isn't worth messing with. — Curtis Olson (2015-02-05). Re: [Flightgear-devel] FlightGear on low (<=4GB) memory systems. (powered by Instant-Cquotes)

FileSelection on Windows hidden by fullscreen Window

In FG 3.4 (full screen mode) I wondered what happens when I try to set e.g. the Screenshot Directory ? the new and nice designed Fileselection box is just not displayed, because it is hidden below the full screened FG main window ... — mhab (Wed Mar 04). FG 3.4 Windows: File Selection Box. (powered by Instant-Cquotes)

No LOD for aircraft previews in fgrun causing lag

Models (and liveries) take some time to load, if the model (livery,...) is very detailed, that time may be substantial. That's all there is to it. Just wait it out. (When I ask the launcher to get me a preview of the Vostok for instance, I get a 5 second freeze. Given the vertex count of the beast, I'm not surprised.) (In principle, we could load a simplified 3d model in the launcher, but I doubt it would be worth the trouble asking people to provide that). — Thorsten (Sun Dec 21). Re: Flight Gear not responding. (powered by Instant-Cquotes)

Broken FGCom cleanup triggers crashrpt during process termination

Shut off FGcom, no more need to report constantly. — clrCoda (Mon Feb 16). SOLVED: Re: FG3.2 wants to always send error report. (powered by Instant-Cquotes)

repare_ground_cache(): scenery_available returns false

A fortunate coincidence, I have just experienced this, too and was able to gather some logging. — Torsten Dreyer (2015-03-06). Re: [Flightgear-devel] prepare_ground_cache(): scenery_available returns false. (powered by Instant-Cquotes)

Crash due to corrupt NavDB

at least on my 10.7 build, I’m seeing an issue with the nav-cache not initialising. This is actually good, because it gives me a way, finally, to trace down the ‘nav-cache never initialises’ bug that some folks have reported. But it will take a little time. Since the same binary works perfectly on my 10.10 box, I assume it’s something /very/ subtle, probably uninitialised memory or some tiny change in zlib’s gzread functions (since we use the system Zlib library which hence could be different between 10.7 and 10.10). — James Turner (2015-02-18). Re: [Flightgear-devel] Release 3.4.0 is coming. (powered by Instant-Cquotes)

Is this a fresh "clean" install or are you installing it after 3.2? If after 3.2 try renaming C:\Users\USERNAME\AppData\Roaming\flightgear.org to C:\Users\USERNAME\AppData\Roaming\flightgear.BAK Then restart FG and let it rebuild all cache. You will have to setup your configuration again. — wlbragg (Thu Feb 19). Re: 3.4 . (powered by Instant-Cquotes)

there's currently a bug in FG 3.2 (under investigation) that makes the simulator crash when you upgrade from FG 3.0 to 3.2, and it seems FG 3.2 crashes even before writing to the log. — elgaton (Fri Dec 26). Re: Problems getting FG running. (powered by Instant-Cquotes)

Instant Crashes

FlightGear 3.4.0 Fails after initializing subsystems and then I received a crash report with other data. 3.4.0 RC1 and 2 also failed — matt1717don (Thu Feb 19). FlightGear 3.4.0 Fails after initializing subsystems. (powered by Instant-Cquotes)

It gets to "Loading Navigation (something)" then crashes. As opposed to, essentially, flashing up for a split second like it does with Terrasync enabled. EDIT: With the minimal startup profile -> still crashes! — Figaro (Fri Feb 27). Re: 3.4.0 instantly crashes. (powered by Instant-Cquotes)

Route Manager Crash/freezing

The only problem is that the route manager crash every time I want to open it. Thats the same problem I had with FG 3.2 — Niki (Thu Mar 05). Re: Flightgear 3.4 on Yosemite. (powered by Instant-Cquotes)

I have problems with route manager, fg just freezes every time I try to use route manager. On every aircraft — VladimirZ (Sun Mar 29).  . (powered by Instant-Cquotes)

Multithreading Issue

Looks like a multi threading issue to me. When I run FlightGear with multiple screens and multiple cameras, the highes threading mode for OpenSceneGraph that works reliable is CullDrawThreadPerContext while the CullThreadPerCameraDrawThreadPerContext quickly leads to a crash. — Torsten (Sun Dec 28). Re: Error when trying to run FlightGear with three monitors. (powered by Instant-Cquotes)

Intel GPU Support

Has any dev tried to disable their nvidia card and use their built-in intel GPU for once? — onox (Sat Sep 13). Re: 3.2rc1 Overall impression. (powered by Instant-Cquotes)

More widespread testing

We could be using our most talented, experience sim pilots to produce more of the necessary tests during release candidates rather than after release. There has to be a way to have a stable release AND a testing suite of the release candidate that co-exist in order to be the helpers we would like to be. — clrCoda (Wed Feb 11). Re: RC 3.4. (powered by Instant-Cquotes)

ideally, people doing such flights regularly would provide a corresponding "fgtape" file using a standard aircraft and get this committed to $FG_ROOT into some kind of "Tests" directory containing pre-recorded flights for doing regression testing in an automated fashion. The thing to keep in mind here is that those among us able (and willing) to troubleshoot such issues are most unlikely to ever actually use FlightGear like this, which certainly includes Zakalawe. Thorsten recently also mentioned that he'll typically just start up FlightGear a few dozen of times using a simple aircraft to test things, without really doing any "real" flying at all. So there are certainly a number of use-cases that aren't getting much attention unfortunately. Which is why it would be a good idea for people to provide flight recorder tapes covering use-cases they care about, and get those committed to fgroot (fgdata) - so that we can grow a library of useful flights to do regression testing - as long as those flights are using standard aircraft and features, they should also be useful for people entirely new to FlightGear. — Hooray (Thu Feb 26). Re: 3.4 and the pain begins .... (powered by Instant-Cquotes)

legacy GUI Z-ordering issue (PUI)

if i have the radio dialogue (F12) and the map dialogue (CTRL-M) open with one overlapping the other, when i release my left mouse button on the top dialogue in a position over a portion of the lower dialogue, the lower one will pop to the top — wkitty42 (Thu Feb 26). GUI dialog box Z-ordering. (powered by Instant-Cquotes)

Dialog z-ordering (fighting?) is my biggest annoyance with the current GUI — Johan G (Sun Mar 01). Re: GUI dialog box Z-ordering. (powered by Instant-Cquotes)

ALS impact on PUI styles for ATI/AMD cards

There are a lot topics concerning AMD graphic cards with flickering problems, but that seems not to match with the issue i have. Maybe there is someone who has or had the same problem and could solve it. — Solid (Sun Mar 08). No Text displayed when using ALS. (powered by Instant-Cquotes)

When I use either of Rembrandt or Atmospheric Light Scattering, some of the text in the menus disappear, with various bits of text disappearing then reappearing every second — Stevy (Thu Feb 20). Corrupt textures when using Rembrandt or ALS. (powered by Instant-Cquotes)

n the HUD (windows, menus), labels tend to be clipped. You can see this, on the previous image, in the rendering options window. And that's more visible when I enable the atmospheric light scattering — Saga (Tue Mar 04). Flightgear doesn't use 100% of the workload and Fonts bug. (powered by Instant-Cquotes)

I've succeed to partially circumvent the problem (not solved it). Menu, windows are displayed well unlike labels directly displayed on the screen like "Airspeed exceed vne". You must change the style of the gui in data/preferences.xml — Saga (Fri May 02). Re: Flightgear doesn't use 100% of the workload and GUI clip. (powered by Instant-Cquotes)

JUST CHANGE THE 1 to a 2 in /FGROOT/preferences.xml — cain071546 (Wed Sep 10). For people with amd graphics . (powered by Instant-Cquotes)

the fact to just change the font seems to solve the bug (just for some labels). I've spotted a font which don't provoke it (lucida.txf) — Saga (Sun Jun 15). Re: Flightgear doesn't use 100% of the workload and GUI clip. (powered by Instant-Cquotes)

Release Schedule

I cannot guarantee for this to be the case in the future, nor is it even likely to happen again. Thus, if the release cycles of Ubuntu and FlightGear stays the same, I fear the next newest FlightGear won't make it into the newest Ubuntu release. — Markus Wanner (2015-02-18). Re: [Flightgear-devel] Release 3.4.0 is coming. (powered by Instant-Cquotes)

Updating "Catalog Metadata" version, vars and data paths

Something that appears to have fallen through the cracks is the Experimental Aircraft Center Catalog creation and version update. Need to implement some automatic feature to handle these type of routine version updates.

Windows: Installer Issues

Today I installed FlightGear on a 32 bit windows laptop that had an existing v3.2 install already loaded. I ran into several issues that I would consider suboptimal and so I'm posting them here for discussion and possible improvement. — Curtis Olson (2015-02-04). [Flightgear-devel] FlightGear 3.4 RC1 (Windows) feedback. (powered by Instant-Cquotes)

The installer came up and wanted to install FlightGear-3.4.0 into FlightGear-3.2.0's folder. I had to manually switch this to FlightGear-3.4.0. I don't think it should work like this, should it? If we are going to install into FlightGear-v<anything> shouldn't we make sure it's the right number? — Curtis Olson (2015-02-04). [Flightgear-devel] FlightGear 3.4 RC1 (Windows) feedback. (powered by Instant-Cquotes)

If I don't choose any aircraft at all, the default comes up as the C172 with a 2D panel. Again is that really what we want? Is it time to deprecate the 2d panel version? Also the way the launcher window is constructed, the information saying this is a 2d panel version is off the screen so had to go to the bottom and scroll side to side to see it. I imagine a lot of first time users wouldn't think or know to do this? — Curtis Olson (2015-02-04). [Flightgear-devel] FlightGear 3.4 RC1 (Windows) feedback. (powered by Instant-Cquotes)

Again, without selecting any airport, the launcher chose 17CL for me which is some random little bitty strip I don't even know where. Wouldn't we want to start in SFO? Wasn't that always our intent? — Curtis Olson (2015-02-04). [Flightgear-devel] FlightGear 3.4 RC1 (Windows) feedback. (powered by Instant-Cquotes)

FlightGear 3.4 is essentially unusable on a 32 bit windows system outside of very remote/simple areas with no scenery. Should we consider seeing if we can just abort the installer on a 32 bit system and quit pretending like maybe it should work? It just doesn't so we could save users with 32 bit systems a whole lot of time if we just bail out of the installer. Is there any reason we shouldn't at least list a 64 bit system as a minimum requirement now for FlightGear? — Curtis Olson (2015-02-04). [Flightgear-devel] FlightGear 3.4 RC1 (Windows) feedback. (powered by Instant-Cquotes)

I seem to recall that there was some work on reducing the memory footprint of FlightGear. Did any of those changes make it into the 3.4 branch? — Curtis Olson (2015-02-04). [Flightgear-devel] FlightGear 3.4 RC1 (Windows) feedback. (powered by Instant-Cquotes)

Updating Dependencies

• Updating the SG/FG source trees for dependencies (JSBSim, OpenSceneGraph etc) should be done right at the beginning of the new release cycle, or at least be closely coordinated.

Bugfix releases

• In case a serious bug is found, there should be a process in place to create and distribute a bugfix release as soon as possible.

--Elgaton (talk) 05:31, 16 March 2015 (EDT)

3.2

• The release should not be announced only on the main web page. It should also be announced on the following places:
  • The official forum
  • The developer list
  • The newsletter

As things turned out this time around, most of our users seem unaware that a new version have been released.

—Johan G (Talk | contribs) 19:33, 18 October 2014 (UTC)

Advice users to delete residual settings from previous versions.

After upgrading to 3.2 on Windows 7, I struggled with strange rendering, misbehaving TerraSync and endless crash on load until I found out that the old 3.0 settings were still there in the Roaming folder. After simply deleting this folder ( C:\Users\USERNAME\AppData\Roaming\flightgear.org\ ), and reinstalling FlightGear, I think, there was never any more trouble and everything worked perfectly. --Jarl Arntzen (talk) 19:03, 22 November 2014 (UTC)

3.0

JSBSim Sync

One point that might be worth considering is whether we want to update JSBSim now or not. OTOH one consequence of updating is that there might be need to adjust some FDM configurations (I have no clear picture what has changed in JSBSim/CVS since the last update and therefore the size of that risk). Otherwise we leave the update to post-3.0.0. — Anders Gidenstam

I did not see this coming (feature freeze) and, yes, there are some important changes in JSBSim that should be updated. I need to merge some offline changes into JSBSim CVS first, though. — Jon S. Berndt

I Guess it's too late to integrate the latest JSBSim code now? — Erik Hofman

Merge Request Handling

Fact is, merge requests do get ignored most of the time, unless you know one of the active developers. I had a merge request pending for three months to update my own code in the tree, not touching anything else. It wasn't downright rejected, but was ignored for enough time for me to start working on something else. Hence I'm not posting any more merge requests and instead I'm keeping my own separate tree (let's not call it fork, since I'm the only user). Though I admit, sometimes it's a major pain to keep up with changes in the main tree. — Adrian Musceac

I can sympathize with the developers. I do know they have their personal agendas, limited time, and a lot to do without having to bother with external users's whining. On the other hand, I can't be expected to babysit my merge requests too much either since I'm in the same position (I do contribute to other projects as well, and have my own to contend with). I think the best way would be to asign a developer by drawing straws every month, and whoever loses gets to look at merge requests on Gitorious and make at least one comment (looks good/ugly code/don't like your nickname etc.). Having one year old merge requests without even one comment is unacceptable in my opinion, no matter which excuses can be provided. — Adrian Musceac

People get busy and miss things. If someone sits quietly for a year on a commit request, they've got nobody to blame other than themselves. I agree that some kind of scheduled review process should be put in place - things shouldn't fall through the cracks if it can be avoided. — GeneB

I agree pretty much entirely - not commenting one merge requests for such a long time is a Bad Thing, and indeed discourages contribution. I like the idea of having a rota of people responsible to at least reviewing merge requests. At present I'm discouraged from reviewing merge requests because I don't feel qualified to do so in many areas, but I could easily provide at least some useful feedback. — Stuart Buchanan

Distribution

• Seed torrents once the release is out

2.12

Release postponed:

Due to real life constraints and the low number of active core developers, we've hit a fluctuation where pretty much everyone is occupied with something else at the moment. As everybody seems to be caught in some real life trouble, we can't see a better way to get the release out than delaying it for a while. Also, it seems that it will take longer than usual to address any issues found in the RCs. Thus, we have agreed to postpone the upcoming FlightGear 2.12 release by a month, to provide sufficient time to handle release candidates and process end-user feedback.

Distribution:

• we should make sure to seed torrents once the release is out [1] [2] [3]

RCs:

• we should try to get out release candidates earlier to give testers a chance to actually run the RCs [4]

could we generate a full installation RC package for testing? It would make it easier for testers not familiar with Git to use it, and would be quite handy for people like myself who do their development on Linux, but have Windows systems available for testing but without the git infrastructure or the time to download the entire git fgdata repository. — Stuart Buchanan

Jenkins only does what it's told by the scripts (mostly in fgmeta besides the CMake files) - so we're still at the mercy of missing files in the installer description and so on - I didn't yet automate a 'smoke test'[1] on Jenkins, since that would mean keeping a clean environment to run test installs, and involve several expensive operations since we'd be launching the sim. That's all doable but requires VMs and more energy than I have. In general I've been hoping to get enough people using the nightly builds that an automated smoke-test would be unnecessary but that's probably optimistic — James Turner

MSVC has a very powerful source view level debugging, but at present this fails in some auto-generated ctor/dtor code before it reaches 'main()' so can not be used ;=((. In the Debug build 'new' is replaced with a 'new_dbg' which deliberately fills the allocation with 0xcc... so if a person does NOT initialize ALL variables simple dtor code like 'if (buf) delete buf;' crashes. — Geoff McLane

FGData:

• Stuart's PDF generator in bin/makereadmepdf.pl should be run as part of the installer creation process.
• Once again, some users were asking for a more lightweight/essential FGData distribution [5]
• Some users reported broken sound configurations for a number of aircraft due to stereo files [6]
• We still keep seeing issues due to aircraft developers contributing resources with files, file names, paths that would break support on OS with case-sensitive OS or a different locale, it would make sense to add some form of automated/scripted validation during startup to detect such issues, without requiring a manual review, possibly through Catalog metadata [7] [8] [9] [10]

Usability/GUI:

• the menubar is increasingly getting a little cluttered, especially the "debug" entry - given the inflexibility of PUI, this also means that there are usability issues, because certain menu items are only accessible with a certain minimal screen resolution, other items cannot be accessed easily. A short term suggestion made, was moving all "Reload X" items into a dedicated "reload" menu, and moving tools to a separate "tools" menu, so help reduce the size of the debug menu [11] [12]

Core:

• A few users reported issues that seemed possibly related to aggressive compiler optimizations, exposing the cmake/build flags via the property tree would seem like a good idea [13]
• Some windows users reported that TerraSync would only work for them in 32-bit compatibility mode [14]
• Providing support to new users would be greatly simplified if we could expose debug related info via the property tree, i.e. to ensure that OSG/SG/FG were not built in DEBUG mode [15]
• We should look into exposing OSG plugin information via the help/about dialog, i.e. writing the info the property tree [16]
• There we still some reports about "SQLite API abuse", presumably due to non-English characters in installation paths,maybe the installer could check paths prior to installation? [17]
• We kept seeing SQLite/NavDB Cache related bug reports [18] ticket #1227
• Like it used to be the case with detailed log files, most end users are usually very willing to help, but unable to provide backtraces - reconsider adding google breakpad support [19]
• under some circumsances, initial navcache/POI processing took up to 10 minutes, even on powerful Linux boxes with plenty of horsepower and RAM using just the default settings [20]
• the way we are incrementing version numbers in SG_SRC/FG_SRC and FGDATA seems to be causing issues ("base package check failed"), which were reported already during the last release cycles (all the way back to 2.8), even one core developer reported the issue during the 2.10 cycle (many people affected by this seem to be using brisa's download & compile script, but it doesn't appear to be Linux-specific, it also seems to happen on Windows). It seems fgdata version is 2.12 while the SG/FG source trees in next were still looking for 2.11 - could be also because of cmake caching, and the cache not being updated properly once certain files are touched in SG/FG source, still investigating... [21] [22] . The problem seems to be this .
• some rendering issues related to OSG 3.1.9 were reported [23] [24] [25] [26]
• it would probably be a good idea to explicitly check for the latest supported OSG version in our SG/FG CMakeLists.txt, to ensure that people do not build FG against OSG versions that are not yet supported, with some option to override/disable the check (for developers) [27] [28]
• while the delayed tile loading is a big improvement in the responsiveness, delayed loading of models caused issues for helicopter pilots, because they could no longer start on buildings - it might be better to make the new behavior property-configurable through a prop switch, so that helicopters could override the setting during startup in their aircraft-set.xml file [29]

Version numbering:

There was already a couple of people on IRC confused that 2.12 is different to 2.1.2 (since minor version numbers > 9 are something of a rarity in many people's perception). — James Turner

Give our release pattern is date scheduled, an Ubuntu style numbering scheme would actually make more sense, but a bit more effort to move too. — James Turner

Externally, 3.0 is going to be considered a bigger deal than 2.12.0. — Stuart Buchanan

I suggest that we zero-pad the minor release digit after 3.0.0 so we have 3.02, 3.04 etc. to reduce confusion if we reach double digits. — Stuart Buchanan

many computer systems sort file names in ascii order, many people don't seem to pay careful attention to where the decimal points are placed, etc. Once we clear past the 2.10, 2.12, etc. series, I'd like to go back to keeping things single digits in the major and minor version numbers and when we run out of a single digits bump up the major number (so 3.8.x -> 4.0.x). Number are numbers, but this one confused a lot more people than I expected it would or should so maybe it's good to be sensitive to that after we clear the 2.x series of versions. — Curtis Olson

That sounds OK to me, as it would imply a full release every 2.5 years, give a clear flag ahead of time when we're nearing a major release, and save having these discussions in the future. For reference, with the current plan there will be 4 years between 2.0.0 (Feb 2010) was and 3.0.0 (Feb 2014). — Stuart Buchanan

I've set the version files on 'next' to be 2.99, on the assumption the next release will be 3.0 as discussed. — James Turner

Backwards Compatibility:

I think I sensible step in that case is to keep 3.0 as backward compatible (in terms of Aircraft APIs) with 2.12 as possible, which mostly means my resisting the urge to clean up legacy stuff :) Obviously it's tricky to offer a 100% guarantee, but I don't have anything planned for 3.0 that will require aircraft changes - I'm sure new technologies such as state machines, knob/slider animations and tooltips will mature and gain some new features but hopefully aircraft developers will be able to work against 2.12 with confidence that things will work the same in 3.0 — James Turner

It's a bit tricky because I haven't had much feedback from aircraft developers about the new APIs (since they aren't in 2.10), but once 2.12 ships we would want to keep them compatible, so fingers crossed the current design is sensible — James Turner

2.10

!!! NOTE: None of these issues have been incorporated into the release plan yet !!!

• FlightGear Core related :
  • a number of users reported segfaults related to the new flight recorder system [30] [31]
  • the download & compile script in fgmeta should be updated for each release [32]
  • It is great news if you are able to crank out full installers right from Jenkins. That will save me a bunch of downloading and hours of uploading for every new release candidate [33].
  • But it might be a good idea to create a script that will distribute the new builds to the various mirrors. That way I'm less likely to throttle the build server to 10k/sec [34]
  • we could also automatically seed them in BitTorrent, on a Linux box and use "btmakemetafile" which I use here to generate those update packages on the tracker [35]
  • IMPROVE RELEASE PLAN: perform a sync with JSBSim sources before the feature freeze [36].
  • IMPROVE RELEASE PLAN: decide early on if/when navdata can be updated [37]
  • IMPROVE RELEASE PLAN: merge requests that didn't make it into the previous release should probably be handled early during the upcoming release cycle
  • IMPROVE RELEASE PLAN: distro-specific repositories should probably be updated, too [38]
  • IMPROVE RELEASE PLAN: the "FlightGear & friends" SuseStudio images should probably be also updated for each release cycle [39]
  • every now and then, people raise the issue of the major/minor version numbering scheme being a little confusing to people not familiar with software development, thinking that 2.8 must be newer/better/more recent than 2.11 - using code names or release dates instead was suggested [40]
  • there are usually reviews posted on blogs, forums etc after each release - we should specifically collect links to those and evaluate all opinions [41] [42]
  • IMPROVE RELEASE PLAN: the release plan should be augmented for the sub-release procedures [43]
  • there were a number of navcache/SQLite related issues reported via the issue tracker and the forum/devel list [44] [45] [46]
  • a little irritation/frustration was caused due to the conflicting review statements concerning the new radio propagation code [47] [48] [49] - some of this boiled down to coding style related issues, highlighting the fact that different core developers have different "coding styles" and requirements when reviewing merge requests, because we still lack an official "FlightGear coding style guide" [50]
  • according to Windows users, the installer created by jenkins could use some optimizations [51]
  • a number of Windows7/Windows8 users reported issues that needed a "force 32/64 bit" workaround during startup [52] [53] [54]
  • IMPROVE RELEASE PLAN: new GUI widgets, new fgcommands and new Nasal APIs should ideally be documented prior the release, at least through updated README files, preferably also through the wiki

• Better bug reports and troubleshooting:
  • show HLA/OpenRTI availability Fixed since 2.11+ [55]
  • add a string property with list of startup arguments used by the user, for use in the about dialog
  • add a property specifying if the binary is 32/64 bit for use in the about dialog (to check if segfaults are related to 32bit RAM limits)
  • add a property specifying the CMAKE_BUILD_TYPE variable used during compilation, for use in the about dialog (debug, release, RelWithDbgInfo) [56]
  • show the threading mode in use in the about dialog
  • show average frame rate and frame spacing in about dialog
  • add a property specifying how much physical RAM is detected (to see if people are running out of RAM) [57]
  • is there a portable ARB/WGL extension to determine the amount of dedicated VRAM available ?
  • try to detect Intel GPUs and Mesa drivers ? (some of the more common issues were related to Intel/Mesa)

• Changelog / Release Announcement:
  • Walking through the list of "lessons learned" as part of the "Upcoming release" announcement was useful [58]
  • IMPROVE RELEASE PLAN: Probably it would be even better to directly process all "lessons learned" items and improve the release plan after each release accordingly
  • To get to the 3.0 goal sometime in the near future, it's probably a good idea to create a backlog of open items in the wiki and link the release plan document to that. As usual, we don't have to be perfect for a new major release number. But the new features being the reason for the new major number should work reasonably correct. [59] (also see Category:Developer Plans)
  • Posting the link to the changelog for the upcoming release helped writing the changelog early, this should also be done for the Hardware Recommendations and Notebooks known to run FlightGear pages probably?
  • The changelog can be easily written by using "git log", searching the issue tracker and by going through the last 6 newsletters published since the previous release. It might make sense to explicitly add a "ChangeLog" message to important commits, so that the Changelog can be compiled more easily ?
  • Alternatively, request developers to add major changes also to $FG_SRC/ChangeLog again (last updated in 2001)?
  • IMPROVE RELEASE PLAN: for the web-based release announcement, it would be helpful to have screen shots or even youtube videos to demonstrate new features - get the community involved EARLY
  • IMPROVE RELEASE PLAN: it may make sense to also allow artwork contributors to contribute new splash screen images for use in the upcoming release. The screen shot contest should provide plenty of options [60] .
  • IMPROVE RELEASE PLAN: a screenshot/banner contest should be held early on, so that we can use the images for our promo work-NOT after the release [61]
  • IMPROVE RELEASE PLAN: for the changelog we should early on invite volunteers to help translate it, useful for the release promotion
  • IMPROVE RELEASE PLAN: having dedicated promo videos sounds like a good idea , see [62] Howto:Creating FlightGear Promo Videos
  • The RC announcement should also contain links to 1) the issue tracker and 2) the RC subforum [63]
  • Using wiki tagging, we could ensure that we can also tag our wiki documentation after each release, so that we can provide older versions of our docs for old FG versions [64]
  • various files in $FG_ROOT haven't been updated in YEARS, either update them in the future, or just get rid of them: THANKS, NEWS, ChangeLog etc

• Shaders:
  • the ATI viewport hack didn't seem enabled in the RCs, as reported by a number of users on the forum [65]
  • the ATI viewport hack should only be enabled by default if ATI/AMD hardware is detected [66] [67] https://gitorious.org/fg/fgdata?p=fg:fgdata.git;a=commit;h=refs/merge-requests/190]
  • we should probably try to detect if software emulated OpenGL is in use (i.e. using Mesa) and show a corresponding warning [68]
  • texture compression should be disabled by default [69] [70] [71] [72] [73]
  • lowering the default shader level to 1 improved compatibility for older/underpowered systems [74]
  • but there were still many users reporting issues like crashes/segfaults during startup, that seemed affected by changing graphics settings [75]
  • we should make sure that the default shader level (and related shaders!) works for all common setups, including ATI/AMD cards (Mac!) and Intel GPUs
  • IMPROVE RELEASE PLAN: GLSL shaders and effects should be treated like core code, and should be tested on different platforms before being enabled by default (i.e. signed-off by people using NVIDIA, ATI/AMD, Intel) [76]
  • IMPROVE RELEASE PLAN: modified shaders should be tested with other shader-related features to prevent breakage [77] (there might be a way to automate this a litle by catching GLSL compiler errors?)
  • to address all the intel GPU related issues, we may want to show an info dialog on computers where /sim/rendering/gl-vendor contains "intel" as a substring and provide an option to disable all shaders [78]
  • we probably need a separate article detailing GLSL coding requirements to ensure that portable constructs are used [79] so that problematic shaders are not just identified at the end of the release cycle

• Installer:
  • The installer should be updated to show a warning regarding TerraSync update time [80]
  • When Flightgear releases a new version, can the staff create a way for the average computer users to install a new version without doing anything to the old version but still use the terrain files from the older version? [81]
  • I believe Fred intentionally chose to use the same registry key from one version to the next. Thus if you install a new version over the top of an existing version it will end up in the same path under C:\<PF> [82]

• FGData related (Base Package):
  • accessibility of README files in $FG_ROOT/Docs should be improved for our Win/Mac users [83] Fixed since 2.11+ (by Stuart)
  • aircraft included in the base package should not require DDS support [84]
  • a bunch of Intel GPU related issues were tracked down to be related to texture dimensions beyond 512x512 not being supported, suggested workarounds are mentioned at [85]
  • "Funny how the 172P doesn't have it (crash detection via limits.nas). It is something like a default aircraft for the sim, isn't it? Which aircraft are considered the most "finished"?" [86]
  • " I'm a bit confused by all the aircraft models in various stages of completion. Even the install package comes with some below-par and alpha stage models. Is there a compiled list of aircraft that are considered "well done"?" [87]
  • The default set of airplanes in FG should be the absolute best of the best, simply because that's what a new user is going to be exposed to for their first time. [88]
  • Language files should be synced between English and other languages, so translators can work on them before the release ;-)
  • the nasal_api_doc.py script in $FG_SRC/scripts/python should be run as part of the release process, to create an updated doc file for $FG_ROOT/Docs and ship it with each release [89]
  • IMPROVE RELEASE PLAN: New/updated Nasal scripts contributed to the base package should be checked to properly support important features like simulator reset, this also applies to Nasal scripts used by aircraft, Nasal scripts that fail these criteria, end up breaking existing features! [90] (also see Release:Aircraft Selection Criteria)
  • regarding aircraft included in the release: "I must stress usefulness of the Autostart feature, present in most aircraft not running at startup. It keeps frustration away from those who just want to enjoy the flight . (Please note that I actually agree with aircraft being shut down at startup, as long as autostart is present, or the starting procedure is trivially doable by just trying what you see in the cockpit.) " [91] (also see Release:Aircraft Selection Criteria)
  • also, it would apparently make sense to provide tutorials for the default aircraft: "At first startup, I noticed the "Need help? use help->tutorials" message, and because I had no idea how to start up the plane (it would be just plain try and fail, than try something else), I did just that and started some basic tutorials. I wouldn't say going through the tutorials was frustrating, but they were quite boring and I was eager to get in the air as soon as possible." [92] (also see Release:Aircraft Selection Criteria)
  • "I discovered however, that there can be some problems on Linux about the planes (eg. some versions of the L39 Albatros undergoing several improvements lately). The problems can be caused by Linux being case sensitive about file paths (Windows is not), and I suspect, more models could suffer from some developers not knowing that. It's easy to fix if you know about the problem, but it would better be done on the developer side, as you never know if the smoke is just not implemented or missing due to this. Not to mention how lengthy it would be to go through more aircraft..." [93]
  • Docs: Relevant FlightGear paths should ideally not be "hard-coded" in the manual, but rather also configured via the build system, i.e. using cmake, so that the FG/SG cmake configuration can be shared, to automatically update the correct paths without requiring manual maintenance [94]

• Usability:
  • the huge number of ads placed on the official website, and the non-intuitive layout of the website caused quite some irritation, not only among new users, but also among seasoned long-time contributors - flightgear.org has been repeatedly described as leaving the impression of even being a "scam" [95] [96]
  • A little downside is how the FGcom is done as a standalone program just cooperating with FG itself. It took me some fiddling with the settings for about two hours to get it working, but again installation was simply done from repos (FGcom and than FGcomGui as well). [97] (this is planned [98]) Fixed since 2.99+
  • Most likely because of the Intel graphics, I suffered for a long time from a problem with aircraft models (and some ground textures too) being black or missing some parts (see my post in an older thread complaining about similar problem). I solved it by adding a command line option turning off texture compression. [99] (also see Release:Aircraft Selection Criteria)
  • We should probably add a new menu to the menubar for our online resources (wiki, forum, issue tracker, FAQ) so that people more easily find important resources just by selecting them from a menu.

• Release Candidates:
  • a number of users reported crashes, for better debugging support, consider linking in Google BreakPad (cross platform stack traces) [100]
  • Release Candidates should probably have a higher default logging level while writing everything to a log file that can be easily shared via the issue tracker/forums, so that end users can provide better bug reports.
  • some users reported "OpenGL out of memory" and "out of space" errors when testing the RCs, we may want to link in a leak detector library or simply add BoehmGC - which is used by Mozilla to track leaking subsystems (a runtime log is created and dumped at process termination), that way non-developers could provide better leak reports. [101] [102] [103]
  • How about having a test run a week or two in advance, just to make sure we can indeed produce release installers for Win+Mac - and then release the first RC on December 17th/18th or 19th [104]
  • We've already got a fairly extensive lead-in time for the release. More testers on more platforms would seem to be the answer. Perhaps we should advertize for testers of those platforms that aren't adequately covered by developers running git? Making a complete package available, not just the binaries would help, as testers wouldn't need to be git-aware. [105]
  • IMPROVE RELEASE PLAN: The main area to improve is to distribute release candidates for all platforms earlier - preferably starting immediately after the freeze. That would already give us more time for testing - without extending the actual freeze period. [106]
  • IMPROVE RELEASE PLAN: aircraft packages should be prepared prior to the official release date: "For the 2.8 release I didn't start making aircraft download packages (or uploading them to the ftp servers) until after the official release date which was a mistake" [107]
  • IMPROVE RELEASE PLAN: RC's should probably be built with Built-in Profiler support enabled [108] .
  • IMPROVE RELEASE PLAN: When releasing RC's do not limit them to Win/Mac binaries, but also create source snapshots so that distros can already work on the next package versions.
  • IMPROVE RELEASE PLAN: For RC's it might make sense to distribute binaries with debugging symbols included and profiling support enabled, so that people can more easily provide useful bug reports, or even backtraces.
  • Also, many end users still prefer using the forum for making bug reports and don't use the issue tracker - it might help to add a link (button) to the issue tracker to the about dialog or maybe even directly to the help menu ("Report an issue") (same for wiki/troubleshooting/faq ?)
  • IMPROVE RELEASE PLAN: it might make sense to give wider exposure to our RCs, i.e. via the newsletter - possibly by adjusting the release schedule
  • actually, it would even seem better to use our Release promotion checklist to send out an "Upcoming Release" announcement 4-6 weeks prior to the actual release, so that all the flightsim websites can notify their users to participate in RC beta testing.
  • a number of forum users reported that the RC/release mirrors were a real bottleneck, and that downloading the 800MB RC installer would often take 2-3 hours (using torrents instead was suggested)
  • it also seemed that a number of users had issues related to their browser corrupting the huge image download [109] (website should suggest to use a download manager instead!)
  • so reducing the size of the installer (i.e. base package) would seem like another good idea to give our RCs wider exposure, for example by focusing only on 2-3 aircraft
  • certain reported issues were really tricky to reproduce, we may want to provide an option to export crucial runtime settings to an XML file that can be easily shared with other testers/developers, or even extend the new flight recorder/replay tape system accordingly [110]
  • it might be good if the forum release-candidates announcement mentions that tests and bug-reports should be done with a clean install of the release-candidate, with no third-party data used in tests.

• Build related:
• A normal Linux user has practically no chance to get last stable on his box running if it isn't in his distro - a normal Windows user gets everything nice and streamlined. [111]
• According to the issue tracker there were 3-5 different contributors who provided C++ patches that didn't end up reviewed/merged, which caused some irritation.

2.8

• Lack of stress-testing: A number of users reported severe memory growth issues (with fgfs consuming as much as 14gb of RAM), many directly related to new features, such as random buildings: [112] [113] [114] [115] These could have probably been identified earlier by running FG for extended periods of time, and testing the shipped aircraft with the default KSFO scenery, and new features such as random buildings enabled.
• Lack of graceful feature scaling: Several users with old graphics cards reported not being able to run FG 2.8 without crashing during startup, because the FG defaults didn't scale for old hardware [116]
• According to noaa.gov it seems that the NOAA metar source got phased out in 04/2012 and moved to a new URL[117], some users reported issues related to this [118] . However, the metar URL is currently hard-coded in the fgfs/metar source code - in addition, the default format is no longer a plain text dump [119]. It would make sense to make the URL a string property that can be put into preferences.xml and then use a Nasal listener to parse the resulting XML/HTML and set a plain text property instead, that can be processed by the existing metar code.
• Broken OSX downloads
• the OSX 10.8 release and code signing caused some irritation
• After the 2.8 release a number of users on the forums reported seeing GLSL related errors, because some of the 2.8 shaders used GLSL features only supported by more recent GLSL compilers/drivers - it would probably make sense to test all shader settings on all 3 platforms and check if they cause any errors (and "backport" shaders as necessary). Apple/Mac OSX seems to be more problematic
• Microsoft Redistributables were apparently not shipped with the Windows installer ?
• The changelog should be written as early as possible
• The code freeze could probably be lifted for patches that are not normally enabled/used by any default code paths (or shipped aircraft) in a FlightGear release. This probably involves Nasal extension functions, fgcommands, telnet commands, but also custom hard coded instruments or instrumentation-related APIs (think Canvas). Basically, whenever there's no chance to break a release by committing a certain patch, because the code path will not be executed by default without explicitly enabling it. For 2.8, this also meant that the Nasal Canvas API could not be included due to the code freeze, which however wasn't used by any systems or aircraft - so that there would have been zero chance for breakage [120] [121] .
• The wiki contains a number of resources to help new users with hardware decisions, such as Hardware Recommendations Notebooks known to run FlightGear and Supported Video Cards - these should probably be updated for each release several weeks in advance.

2.6

• feature freeze in general

  helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.

• feature freeze for aircraft

  Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.

• switching to a new version of supporting libraries like OSG.

  The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.

• manual creation of release candidates and the release binaries

  It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.

• release date/time frame

  It took several days to release all the subparts. Might be better to upload all files and pages to hidden folders and publish them all at once (or at least within a couple of hours). That'll have several advantages:

  • no big difference between releases for the various OS.
  • the website will switch to the new release state quickly. With 2.6.0, the aircraft page was published before the setup. The release announcement was published even later.

References