Project Infrastructure Enhancements

From wiki.flightgear.org

Jump to: navigation, search

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 [1].


Contents

Contributor Recruitment & Support

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

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 [17]), 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

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 [18], 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

    • Also, this might help facilitate providing Aircraft maintainers themselves with commit privileges for their aircraft [20], which would also decrease the workload of core developers. In addition, it is foreseeable that as FlightGear matures and stabilizes, increasing amounts of future significant contributions are going to take place in the base package department by means of middleware contents enabled through technologies such as the Nasal scripting system.
  • Set up and maintain a central git/cvs mirror (gateway) of FlightGear OSG/HEAD to enable contributors to more easily do decentralized development without requiring CVS privileges.
    • We're maintaining a regular read-only GIT mirror of the most prominent FlightGear CVS trees (plus some forks as well) which we advertize as a common foundation for further local development trees - and maybe for a future switchover from CVS to GIT as primary 'official' repository. Please visit the site here: http://mapserver.flightgear.org/git/gitweb.pl. (now featuring support for the git protocol as well) This might help facilitate implementing the following suggestion:
  • Consider setting up a subversion/git server, DONE, see above so that we can stop using CVS- svn/git can both easily import an entire CVS repository, preserving all revision history etc (NOTE: git is currently not yet particularly well supported on non-nix platforms[22], however: git comes with daemons/gateways such as git-cvsserver that can fully emulate a CVS server while still writing directly to a git repository on the server-side, thus it is quite possible to simply keep using other clients (CVS or SVN) to work with a git-based repository, as long as a corresponding git/cvs gateway has been set up). (see [23] for a discussion of CVS/SVN vs. git) Resources WRT running git on Win32
  • Encourage liberal use of SCM branches to get new community members more easily, faster and more directly involved in the FlightGear project to implement new features, providing the gratification that their new experimental code is directly contributed back to the project, while at the same time ensuring integrity of the main/HEAD branch so that HEAD stability is not affected. This might also be an opportunity to get to know new community members in a controlled environment where they may nonetheless directly contribute to the project without necessarily requiring reviewers to monitor every single step while working on a specifically created branch, simultaneously providing new contributors with a good way to get to know the project, the community and the source base. (This is already a summary of the original discussion, however it should be mentioned that an alternative might be to provide a git-based mirror of CVS/HEAD with "mob" access enabled (anoymous write access to a specific public -writable- branch for highly experimental user-contributed code[24] )Note: there's apparently a launchpad mirror of FlightGear CVS/HEAD at [25] so that people can easily create development branches (though, bzr only)
  • consider providing RSS feeds for the FlightGear CVS repositories so that changes can be more easily tracked (NOTE: this can be emulated using the sourceforge archives for "flightgear cvslogs":http://sourceforge.net/export/rss2_project.php?group_id=583)

Documentation/Collaboration related

  • 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 Note: apparently, this exists already - in a discussion at sourceforge about three months ago [26], someone posted a link to http://docpit.nonlogic.org/dox/d8/d59/tiny__xdr_8cxx.html
  • 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://www.flightgear.org/forums/viewtopic.php?t=938 DONE: http://www.flightgear.org/forums/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 [27]
  • 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 [28] (also see Source code control systems from 09/2009) and a discussion from 10/2009 [29]

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
  • determine necessary steps to allow for a more regular release cycle [30]
  • 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 [31]
  • 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: [32]) might be an interesting option to easily create Win32 installers in a scripted/automated fashion, even under *nix

Organization 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 [33]. 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 [34] [35]

[36] [37] [38]

Code Quality related

Quote [40]: 

 > 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

  • import the complete DAFIF data into an SQL database, including Robin Peel's database, this would offer the possibility to provide a web based interface to the corresponding data, i.e. in order to allow users to easily provide corrections or augmentations for existing data. Eventually, this could probably also be useful for the landcover DB anyway?--82.83.154.229 09:31, 18 June 2006 (EDT) [note: this has already been done as a part of the FGMap effort)
    • 2008-03-02: Integration of the airfield layouts into the Landcover-DB is already being worked on.
  • 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.
Retrieved from "http://wiki.flightgear.org/index.php/Project_Infrastructure_Enhancements"