20,741
edits
Release plan: Difference between revisions
→2.10
(→2.10) |
(→2.10) |
||
| Line 213: | Line 213: | ||
** 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 [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39782.html] | ** 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 [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39782.html] | ||
** 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 [http://mxchange.org:23456/ the tracker] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39783.html] | ** 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 [http://mxchange.org:23456/ the tracker] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39783.html] | ||
** perform a sync with JSBSim sources before the feature freeze [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40179.html]. | ** {{Improve Release Plan|perform a sync with JSBSim sources before the feature freeze}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40179.html]. | ||
** decide early on if/when navdata can be updated [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39280.html] | ** {{Improve Release Plan|decide early on if/when navdata can be updated}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39280.html] | ||
** merge requests that didn't make it into the previous release should probably be handled early during the upcoming release cycle | ** {{Improve Release Plan|merge requests that didn't make it into the previous release should probably be handled early during the upcoming release cycle}} | ||
** distro-specific repositories should probably be updated, too [http://flightgear.org/forums/viewtopic.php?f=42&t=18852&p=174943] | ** {{Improve Release Plan|distro-specific repositories should probably be updated, too}} [http://flightgear.org/forums/viewtopic.php?f=42&t=18852&p=174943] | ||
** the "FlightGear & friends" SuseStudio images should probably be also updated for each release cycle [http://susestudio.com/a/sBTdmU/flightgear-friends--2] | ** {{Improve Release Plan|the "FlightGear & friends" SuseStudio images should probably be also updated for each release cycle }}[http://susestudio.com/a/sBTdmU/flightgear-friends--2] | ||
** 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 [http://flightgear.org/forums/viewtopic.php?f=42&t=19255] | ** 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 [http://flightgear.org/forums/viewtopic.php?f=42&t=19255] | ||
** there are usually reviews posted on blogs, forums etc after each release - we should specifically collect links to those and evaluate all opinions [http://forum.avsim.net/topic/400897-my-experience-with-flightgear-210/] [http://forum.avsim.net/topic/399809-fg-210-most-certainly-a-new-era-of-fg/] | ** there are usually reviews posted on blogs, forums etc after each release - we should specifically collect links to those and evaluate all opinions [http://forum.avsim.net/topic/400897-my-experience-with-flightgear-210/] [http://forum.avsim.net/topic/399809-fg-210-most-certainly-a-new-era-of-fg/] | ||
** the release plan should be augmented for the sub-release procedures [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39710.html] | ** {{Improve Release Plan|the release plan should be augmented for the sub-release procedures }}[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39710.html] | ||
** 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] [http://flightgear.org/forums/viewtopic.php?f=68&p=175690#p175690] [http://code.google.com/p/flightgear-bugs/issues/detail?id=1055] | ** 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] [http://flightgear.org/forums/viewtopic.php?f=68&p=175690#p175690] [http://code.google.com/p/flightgear-bugs/issues/detail?id=1055] | ||
** 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] | ||
| Line 264: | Line 264: | ||
** but there were still '''many''' users reporting issues like crashes/segfaults during startup, that seemed affected by changing graphics settings [http://flightgear.org/forums/viewtopic.php?f=17&t=19670&p=181035#p181033] | ** but there were still '''many''' users reporting issues like crashes/segfaults during startup, that seemed affected by changing graphics settings [http://flightgear.org/forums/viewtopic.php?f=17&t=19670&p=181035#p181033] | ||
** 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 | ** 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 | ||
** 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] | ** {{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)}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39120.html] | ||
** modified shaders should be tested with other shader-related features to prevent breakage [http://flightgear.org/forums/viewtopic.php?f=68&t=18924#p175583] (there might be a way to automate this a litle by catching GLSL compiler errors?) | ** {{Improve Release Plan|modified shaders should be tested with other shader-related features to prevent breakage }}[http://flightgear.org/forums/viewtopic.php?f=68&t=18924#p175583] (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 [http://flightgear.org/forums/viewtopic.php?f=37&t=18050&p=175774#p175774] | ** 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 [http://flightgear.org/forums/viewtopic.php?f=37&t=18050&p=175774#p175774] | ||
** we probably need a separate article detailing GLSL coding requirements to ensure that portable constructs are used [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39278.html] so that problematic shaders are not just identified at the end of the release cycle | ** we probably need a separate article detailing GLSL coding requirements to ensure that portable constructs are used [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39278.html] so that problematic shaders are not just identified at the end of the release cycle | ||