Project Infrastructure Enhancements

From FlightGear wiki
Jump to: navigation, search
This article or section contains out-of-date information

Please help improve this article by updating it. There may be additional information on the talk page.

This article has been nominated for deletion. To discuss it, please visit the talk page.

Do not remove this tag until the discussion is closed.



This page is meant to provide a dedicated place for feature requests, suggestions and ideas concerning enhancements of the FlightGear project's infrastructure and logistics.

Most of these items have so far been pretty widely spread over many different places in the wiki or various mailing list discussions. Some items are still being kept on the main page's discussion page Talk:Main Page.


Contributor Recruitment & Support

Announcement of TerraGear fork[10] [11] [12] [13][14] [15]

Release Versioning related

It has already been suggested several times in various discussions to turn away from version numbers for FlightGear releases, and instead use "codenames" for each major release (see for example [16]), this might help address concerns about varying expectations for any given version number among community members.

In addition, the FlightGear project is now experiencing really sizable contributions from its user community, including scenery, aircraft and AI traffic networks (think Piper PA34-200T Seneca II and KLSV or EHAM).

Given that these contributions are more often than not much more compelling than the legacy FlightGear defaults (KSFO & c172p), it might be worthwhile to consider the merits of modifying the default startup scenario for (some) major releases in order to give these community contributions much more -well deserved- exposure. In fact, doing so might even support a codename-based release tagging scheme, because FlightGear versions might be tagged according to their default startup scenario (e.g. "FlightGear Nellis Airforce Base"). This would probably increase motivation for community members to keep contributing their work and would make these contributions much more prominent. Polls about possible startup scenario candidates (scenery & aircraft, and possibly scenarios) could later on be conducted on the forums or mailing list. It can be assumed that following such a release policy would revigorate the FlightGear community.

SCM related

Moving section to dedicated wiki article: Source Code Management Issues

Commit related

As it is becoming more and more challenging with each new release to keep track of all the modifications made and new features added in between releases [17], it might make sense to consider the possible merits of settling for a common tagging scheme for commits, so that the commit log could later on be used to automatically create a changelog for each new release, such a scheme could for example follow a convention of TYPE:WHO:COMPONENT:DESCRIPTION, so that it can be easily processed using regex-in detail:

  • TYPE: "BUGFIX", "NEW_FEATURE", "ENHANCEMENT"
  • WHO: author/contributor
  • COMPONENT: SUBSYSTEM/AIRCRAFT
  • DESCRIPTION: detailed description for commit

So that future commits may have the following form:

ENHANCEMENT, John Doe, A320, Added a new livery for United Airlines
NEW_FEATURE: John Doe, Nasal, Added support for named function parameters
BUGFIX: John Doe, A320, fixed the gear animation

By encouraging CVS committers to follow such a scheme to formalize and describe their commits, it would become very easy to just have a script create a changelog file automatically. To further simplify this process, there could be another script that interactively asks for this information.

Misc

  • flightgear.org website TLC [18]

Documentation/Collaboration related

  • mediawiki extension to implement a knowledgebase: mw:Extension:Knowledgebase
  • Set up a wiki at FlightGear.org DONE , so that regular backups can be easily done. Also, the wiki could possibly write/export its pages directly into the CVS directory of $FG_ROOT/Docs
  • set up a full set of automatically created DoxyGen documentation at FlightGear.org, possibly using a monthly/weekly update cycle for the CVS version, this would require approx. 500MB of webspace, could be done using a cron job (here's an extension available that integrates DoxyGen with mediawiki:mw:Extension:DoxyWiki)
  • more specific categorization of mailing lists: as the FlightGear community continues to grow, it is getting clear that the current separation of topics into devel/user, fdm- related topics may not be sufficient to adequatley address the needs of middleware contributors anymore, who are neither exclusively users, nor necessarily really core-developers. In fact, most newcomers -with a non-programming background- wishing to contribute to FlightGear would probably be interested in a mailing list dedicated to base package related contributions, which would cover all related resources (i.e. aircraft, 3d modeling, scripting). This would also help separate discussion of different topics, so that the devel mailing list would be mainly specific to core code, while a corresponding middleware mailing list would mainly address base package related contributions.
  • consider providing RSS feeds for the FlightGear forums [http://forum.flightgear.org/viewtopic.php?t=938 DONE: http://forum.flightgear.org/rss.php, as well as for FlightGear's wikimedia setup in order to provide straightforward means to allow RSS-based tracking
    • If you go to Recent Changes there are RSS and ATOM feed links in the toolbox.
  • consider using separate mailing lists dedicated to collecting and archiving patches sent by contributors, it might even be worthwhile to consider differentiating between base package patches and core/C++ patches.
  • Consider providing a MAINTAINERS file for the source tarball and the base package to enable community members to more easily determine component authors/maintainers [19]
  • the structure of the current code base could be more intuitive by providing each folder with additional plain text files, which could also be used to automatically build documentation for each source code folder, such files would preferably describe:
    • FILES/PURPOSE
    • MAINTAINERS
    • TODO/PLANS/ROADMAP
    • ChangeLog
  • consider setting up a dedicated tracker like bugzilla for bugs and feature requests/ideas [20] (also see Source code control systems from 09/2009) and a discussion from 10/2009 [21] [22]

Build/Release related

  • Set up a cross compiler version of gcc at flightgear.org to automatically create binary packages (releases) of FlightGear for platforms such as Win32 or MacOS. Please note, there's now a list of Free Shell Providers so that people can evaluate this list in order to find services suitable to be used for efforts such as setting up automated cross-compilers.
  • evaluate the benefits of setting up a compile server, so that source code may be build automatically, i.e. for regression-testing purposes, but possibly also for pre-releases or even releases (Note: Since April/2010, there is talk ongoing about setting up a hudson based CI server for automating builds [23] [24]) The gcc project provides compile farm (SSH) access to open source projects: [25]
  • determine necessary steps to allow for a more regular release cycle [26] [27]
  • determine possible advantages of migrating the current autotools-based build system to cmake, which would still make use of autotools on *nix platform, but would also directly provide support for other platform-specific build systems (such as for MSVC++ Express)-that way, project files for ALL supported platforms could be generally and easily maintained (automatically created on each platform) via one source, while being used for arbitrary platforms and backends.

Distribution related

  • consider distributing the FlightGear CD/DVD as a linux boot cd/dvd (i.e. knoppix), so that users can optionally try to easily boot easily into linux in order to start FG
  • given that shortly after a releases, flightgear binaries are often not easily available because of hosting bandwidth, consider possible advantages of using torrents to distribute FlightGear binaries more easily, faster and more reliably [28]
  • At http://freshmeat.net/projects/installbase/ or more specifically at http://installbase.sourceforge.net/main.shtml there's an open source cross platform GUI installer available that may be an interesting option for creating binary FlightGear installers. The whole thing is based on TK and works with statically precompiled interpreters that serve as stub for an ASCII config file that contains all relevant information for cross platform setups,including a tarball of installation specific files for each platform. The installbase installer is very convenient and works entirely with a very powerful GUI frontend that allows you to set up, test and export installer packages. Given that the final config file is ASCII, it would probably be quite possible to simply put all this into some sort of Makefile, so that the whole package creation could be handled automatically, i.e. by doing something like "make win32-package" or "make macos-package". The screenshots look very convincing. That way, all FlightGear binaries could easily use an identical installer and configuration wizard.
  • NSIS (details: [29]) might be an interesting option to easily create Win32 installers in a scripted/automated fashion, even under *nix

Organization/Funding related

  • nlnet provides open source projects with easy access to free funding (in the range of 0-35000 USD) in order to help sponsor promising open source projects and efforts, details are available at their website, the next deadline for applications is on dec the 1st 2008 [30]. Applications can be sent here, you can help prepare a template for applying: Funding Application
  • consider setting up a non-profit organization for FlightGear, so that donations may become tax-deductible [31] [32]

[33] [34] [35] [36]

  • determine what's necessary to allow flightgear to accept donations from its community [37]

Code Quality related

Quote [39]:

 > Some projects with which I've been involved use a system of time-boxed
 > releases. For example, every 2 months a branch is made from the main
 > source tree and becomes a release, ready or not. Automatic testing helps
 > with this strategy -- of course it helps in general. One could write
 > automatic tests for FlightGear using the scripting and scenario support.
     This might be something worth considering.  In the past we have tried to get
     all our ducks in a row first, then get binaries lined up, get the whole
     windows setup thing ironed out (that's 95% of our user base so it's
     important to do) and finally push it all out.  It's a large amount of
     effort, easily consuming a 40-60 hour work week.  It has always become
     deathly quiet when I've floated the idea of someone else taking over release
     duties. :-)  I have gotten good help though when I've asked for it.

Misc

  • Continue putting an increased emphasis on middleware development by extending existing, and establishing new hooks into the core engine using the integrated Nasal scripting interpreter, so that more and more non-critical (performance-wise) features can be implemented using high level interfaces to FlightGear, this would not only help non-developers to easily make exciting new contributions, but it would also help reducing the size of the core source tree, which would eventually make it become more maintainable as well.