Release plan: Difference between revisions

Jump to navigation Jump to search

Release plan (view source)

Revision as of 22:44, 30 January 2013

19 bytes added ,  30 January 2013
→‎2.10
Line 194: Line 194:
==== 2.10 ====
==== 2.10 ====
* {{Thumbs up}} Walking through the list of "lessons learned" as part of the "Upcoming release" announcement was useful [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38749.html]
* {{Thumbs up}} Walking through the list of "lessons learned" as part of the "Upcoming release" announcement was useful [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38749.html]
* perform a sync with JSBSim sources before the feature freeze.
* {{Thumbs up}} 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?
* {{Thumbs up}} 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?
* {{Thumbs up}} lowering the default shader level to 1 improved compatibility for older/underpowered systems [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39189.html]
** {{Thumbs up}} 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 ?
* perform a sync with JSBSim sources before the feature freeze.
** Alternatively, request developers to add major changes also to $FG_SRC/ChangeLog again (last updated in 2001)?
* {{Thumbs up}} 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 ?
** for the web-based release announcement, it would be helpful to have screen shots or even youtube videos to demonstrate new features
* Alternatively, request developers to add major changes also to $FG_SRC/ChangeLog again (last updated in 2001)?
** 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 [http://www.flightgear.org/forums/viewtopic.php?f=28&t=16795].
* for the web-based release announcement, it would be helpful to have screen shots or even youtube videos to demonstrate new features
 
* 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) [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39120.html]
* Shaders
** {{Thumbs up}} lowering the default shader level to 1 improved compatibility for older/underpowered systems [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39189.html]
** 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) [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39120.html]
* 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! [https://code.google.com/p/flightgear-bugs/issues/detail?id=956] (also see [[Release:Aircraft Selection Criteria]])
* 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! [https://code.google.com/p/flightgear-bugs/issues/detail?id=956] (also see [[Release:Aircraft Selection Criteria]])
* there were a number of navcache/SQLite related issues reported via the issue tracker and the forum/devel list [https://code.google.com/p/flightgear-bugs/issues/detail?id=894]
* there were a number of navcache/SQLite related issues reported via the issue tracker and the forum/devel list [https://code.google.com/p/flightgear-bugs/issues/detail?id=894]
* a little irritation/frustration was caused due to the conflicting review statements concerning the new radio propagation code [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38905.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38825.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg33692.html] - 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" [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38958.html]
* a little irritation/frustration was caused due to the conflicting review statements concerning the new radio propagation code [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38905.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38825.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg33692.html] - 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" [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38958.html]
* the [https://gitorious.org/fg/flightgear/blobs/next/scripts/python/nasal_api_doc.py 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 [http://flightgear.org/forums/viewtopic.php?f=30&t=15133]
* the [https://gitorious.org/fg/flightgear/blobs/next/scripts/python/nasal_api_doc.py 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 [http://flightgear.org/forums/viewtopic.php?f=30&t=15133]
* 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. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38764.html]
* 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.[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38765.html]
* 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 [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38765.html]
* 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 [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38765.html]
** 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. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38764.html]
** 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.[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38765.html]
** 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" [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39227.html]
** 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" [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39227.html]
** RC's should probably be built with [[Built-in Profiler]] support enabled [http://flightgear.org/forums/viewtopic.php?f=68&t=18839&p=175689#p175689].
** RC's should probably be built with [[Built-in Profiler]] support enabled [http://flightgear.org/forums/viewtopic.php?f=68&t=18839&p=175689#p175689].
Line 216: Line 219:
* 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. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38817.html]
* 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. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38817.html]
* 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.
* 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.
* 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 [http://www.flightgear.org/forums/viewtopic.php?f=28&t=16795].
* {{Thumbs up}} 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.) " [http://flightgear.org/forums/viewtopic.php?f=3&t=18240&p=175117#p175117] (also see [[Release:Aircraft Selection Criteria]])
* {{Thumbs up}} 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.) " [http://flightgear.org/forums/viewtopic.php?f=3&t=18240&p=175117#p175117] (also see [[Release:Aircraft Selection Criteria]])
* {{Thumbs up}} 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." [http://www.flightgear.org/forums/viewtopic.php?f=28&t=16795] (also see [[Release:Aircraft Selection Criteria]])
* {{Thumbs up}} 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." [http://www.flightgear.org/forums/viewtopic.php?f=28&t=16795] (also see [[Release:Aircraft Selection Criteria]])
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/57535"

Navigation menu