Re: [Flightgear-devel] June / LinuxTag release
Peter Morgan wrote: > Would the future also contain the MP protocol+player enviroment, ATC, MP > mapping ? I doubt that these are affected by the release process. > and also all the aircraft independant in hangars Aircraft are available here: http://www.flightgear.org/Downloads/aircraft-2.0.0/ > and is fgrun included To my knowledge the recent Windows packages were having 'fgrun' included. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] June / LinuxTag release
Would the future also contain the MP protocol+player enviroment, ATC, MP mapping ? a monthly release would be nice with hot fixes.. and also all the aircraft independant in hangars and is fgrun included pete On Tue, Jun 15, 2010 at 9:58 PM, Durk Talsma wrote: > Hi James, > > On Friday 07 May 2010 06:06:32 pm James Turner wrote: > > > Anyway, the key thing - what are the steps to make a release happen. I'm > > > seeking to capture the actual steps (and ideally script them), so even if > > > Curt & Durk both get hit by the proverbial bus tomorrow, we can still > make > > > a Flightgear release ever again. But also, I'm seeking to remove the > human > > > factors from the release process, and especially not feel that we're > > > overloading people just because a release needs to happen - eg, around > > > LinuxTag Durk is often quite busy organising things :) > > > > > Well, I already gave you the outline over breakfast in Berlin, but > nevertheless, I feel that it doesn't hurt to give a quick summary of our > generic release procedure. I'll start by our historical cvs based procedure, > and will later on give some indication as to how we can fit in our new git > repository. > > When I first started coordinating the releases, my first and foremost aim > was to regularize the release cycle by making sure we did at least one > release a year. More or less coincidentally, this happened around Christmas > / end of the year. Typically preparations for the release started sometime > in September / October by sending out a couple of emails to the developers > list. These emails concerned matters such as our base package aircraft > selection and the request to set a date for a feature freeze. Typically, > October through late November were filled with bug fixing. Once we > determined that the could was reasonably stable, I would update the version > numbers for simgear, flightgear, and data, and run a make dist command on > all three. Then, I would tag the CVS repositories and place the tar files > resulting from the make dist commands somewhere on an ftp / web server. > Usually this was my home PC, which was connected to the Internet through a > rather slow wireless lan and ADSL upload link. I'd announce the presence of > these packages to Curt, Fred, and Tatsuhiro, who would make the sources > available for public download and build the windows and mac binary > distributions respectively. Eventually, all files would be sent to Curt for > placement on the flightgear.org website. This procedure would start with > one release candidate and repeated if necessary. > > While we were approaching the final stages of the release cycle, I would > start browsing the commit logs, in order to write a comprehensive summary of > all the major changes that had happened during that year. In more recent > years, this also included generating some screen shots for promotional > purposes and writing a release announcement. > > Starting with the maintenance release 1.9.1, we began using Tim Moore's git > repository. The obvious advantage was that Tim was able to only push bug > fixes from CVS into the git repository, so that development of new features > could continue without the risk of breaking the stable code base. > > FlightGear 2.0 was entirely -as in source code- released from git, while > the data tree was still downloaded from CVS. For this release, we changed > our policy slightly, because we weren't too thrilled about having to push a > 250+ MB base package through my slow ADSL upload. So, instead, we tagged the > base package and asked Curt, Fred, and Tatsuhiro, to check and build the > base package themselves. > > The release process of FlightGear 2.0 clearly marked a transition. Although > the procedure worked reasonably well, we did encounter a few glitches. The > most striking one was that it was seemingly impossible for me to remotely > tag the base package, so I had to request that Curt finishes this job. In > the midst of this, I wasn't able to build FlightGear on a clean system, so I > missed the fact that a few files were not included in the data tar file, as > well as running into a few other miscellaneous problems. > > With git allowing much finer grained control over revision changes, I don't > think that we should encounter such trouble in the near future. With your > automatic build system in place, we should in fact be able to automatize > much of the process. The only two things that I can think of are 1) the fact > that non-technical side of the release process (writing a ChangeLog summary; > generating promotional materials) as well as pushing the result onto a > central ftp server still requires some manual intervention. The question is > how we could streamline that. > > Cheers, > > Durk > > > -- > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky paren
Re: [Flightgear-devel] June / LinuxTag release
Hi James, On Friday 07 May 2010 06:06:32 pm James Turner wrote: > Anyway, the key thing - what are the steps to make a release happen. I'm > seeking to capture the actual steps (and ideally script them), so even if > Curt & Durk both get hit by the proverbial bus tomorrow, we can still make > a Flightgear release ever again. But also, I'm seeking to remove the human > factors from the release process, and especially not feel that we're > overloading people just because a release needs to happen - eg, around > LinuxTag Durk is often quite busy organising things :) > Well, I already gave you the outline over breakfast in Berlin, but nevertheless, I feel that it doesn't hurt to give a quick summary of our generic release procedure. I'll start by our historical cvs based procedure, and will later on give some indication as to how we can fit in our new git repository. When I first started coordinating the releases, my first and foremost aim was to regularize the release cycle by making sure we did at least one release a year. More or less coincidentally, this happened around Christmas / end of the year. Typically preparations for the release started sometime in September / October by sending out a couple of emails to the developers list. These emails concerned matters such as our base package aircraft selection and the request to set a date for a feature freeze. Typically, October through late November were filled with bug fixing. Once we determined that the could was reasonably stable, I would update the version numbers for simgear, flightgear, and data, and run a make dist command on all three. Then, I would tag the CVS repositories and place the tar files resulting from the make dist commands somewhere on an ftp / web server. Usually this was my home PC, which was connected to the Internet through a rather slow wireless lan and ADSL upload link. I'd announce the presence of these packages to Curt, Fred, and Tatsuhiro, who would make the sources available for public download and build the windows and mac binary distributions respectively. Eventually, all files would be sent to Curt for placement on the flightgear.org website. This procedure would start with one release candidate and repeated if necessary. While we were approaching the final stages of the release cycle, I would start browsing the commit logs, in order to write a comprehensive summary of all the major changes that had happened during that year. In more recent years, this also included generating some screen shots for promotional purposes and writing a release announcement. Starting with the maintenance release 1.9.1, we began using Tim Moore's git repository. The obvious advantage was that Tim was able to only push bug fixes from CVS into the git repository, so that development of new features could continue without the risk of breaking the stable code base. FlightGear 2.0 was entirely -as in source code- released from git, while the data tree was still downloaded from CVS. For this release, we changed our policy slightly, because we weren't too thrilled about having to push a 250+ MB base package through my slow ADSL upload. So, instead, we tagged the base package and asked Curt, Fred, and Tatsuhiro, to check and build the base package themselves. The release process of FlightGear 2.0 clearly marked a transition. Although the procedure worked reasonably well, we did encounter a few glitches. The most striking one was that it was seemingly impossible for me to remotely tag the base package, so I had to request that Curt finishes this job. In the midst of this, I wasn't able to build FlightGear on a clean system, so I missed the fact that a few files were not included in the data tar file, as well as running into a few other miscellaneous problems. With git allowing much finer grained control over revision changes, I don't think that we should encounter such trouble in the near future. With your automatic build system in place, we should in fact be able to automatize much of the process. The only two things that I can think of are 1) the fact that non-technical side of the release process (writing a ChangeLog summary; generating promotional materials) as well as pushing the result onto a central ftp server still requires some manual intervention. The question is how we could streamline that. Cheers, Durk -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] June / LinuxTag release
James, We do not have a Windows build setup yet but are looking into developing with FlightGear sometime over the next couple months. I offered as I thought you might be able to help us setup a build environment. In return for the assistance I was willing to offer some of our company bandwidth for the FG community. Cheers! Christian FreedomWorks Inc. US: 609-858-2290 Canada: 905-228-0285 Fax: 347-296-3666 Email: christ...@freedomworks.ca www.FreedomWorks.ca From: James Turner [mailto:zakal...@mac.com] Sent: Monday, May 10, 2010 5:46 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] June / LinuxTag release On 10 May 2010, at 13:55, Christian Menge wrote: Did you get this ping? Apologies, yes, but it's been a busy few days. For various reasons, I'd like to have a reliable Windows build locally, before I waste other people's time (unless you have time and energy to burn yourself). I have the mingw build kind-of working now, though I need to test the resulting executables, and then I'll be happier to add other build configurations (I want to look at cross-compiling from Linux too). If you already have Flightgear building from source on suitable Windows box, I can summarise the approximate steps to automate things, but I'm learning as I go, hence my comments about wasting people's time :) James === Email scanned by PC Tools - No viruses or spyware found. (Email Guard: 7.0.0.18, Virus/Spyware Database: 6.14960) http://www.pctools.com <http://www.pctools.com/?cclick=EmailFooterClean_51> === -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] June / LinuxTag release
On 10 May 2010, at 13:55, Christian Menge wrote: > Did you get this ping? > Apologies, yes, but it's been a busy few days. For various reasons, I'd like to have a reliable Windows build locally, before I waste other people's time (unless you have time and energy to burn yourself). I have the mingw build kind-of working now, though I need to test the resulting executables, and then I'll be happier to add other build configurations (I want to look at cross-compiling from Linux too). If you already have Flightgear building from source on suitable Windows box, I can summarise the approximate steps to automate things, but I'm learning as I go, hence my comments about wasting people's time :) James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] June / LinuxTag release
Peter Morgan wrote: > So we need a working version on the tuesday before .. > > The following tuesday, U will be taking that to Linux tag.. on a chip ? "Traditionally" (since 2007) the setup for LinuxTag has been prepared and test-run by Matthias Boerner, Mathias Froehlich - and myself. LinuxTag 2006 had seen a mix from various participants (including one FreeBSD machine :-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] June / LinuxTag release
James, Did you get this ping? Christian FreedomWorks Inc. US: 609-858-2290 Canada: 905-228-0285 Fax: 347-296-3666 Email: christ...@freedomworks.ca www.FreedomWorks.ca From: Christian Menge [mailto:cme...@gmail.com] Sent: Saturday, May 08, 2010 10:33 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] June / LinuxTag release James, We might be interested in helping out with the Windows build. We have access to a linux shared server and several Windows 7 machines with Visual Studio 2008 / 2010. Let me know if this works for you? Christian Menge FreedomWorks Inc. US: 609-858-2290 Canada: 905-228-0285 Fax: 347-296-3666 christ...@freedomworks.ca www.freedomworks.ca On reFri, May 7, 2010 at 12:06 PM, James Turner wrote: I want to make a 2.1 FG release, at the end of this month, or the very start of June. As far as I can see, the current code is pretty good - many bugs have been fixed since 2.0, and while I'm sure some new ones have crept in, I don't have many code quality concerns - if we were to cut tarballs from the source code today, we'd definitely be in a better place than 2.0 in terms of bugs. (If people know of regressions from 2.0, or regressions in 2.0 from 1.9.x, I hope they would mention them here, or even in the bugtracker) Anyway, the key thing - what are the steps to make a release happen. I'm seeking to capture the actual steps (and ideally script them), so even if Curt & Durk both get hit by the proverbial bus tomorrow, we can still make a Flightgear release ever again. But also, I'm seeking to remove the human factors from the release process, and especially not feel that we're overloading people just because a release needs to happen - eg, around LinuxTag Durk is often quite busy organising things :) My build system ( http://zakalawe.ath.cx:8080/ ) is working well for Mac and Linux - MinGW is giving me some pain, I will look into cross-compiling mingw this weekend. If anyone wants to volunteer some time, a Windows box with Visual Studio, some disk space, and bandwidth, I am happy to work with them to get an automated VS build going. Adding more automated steps, even ones which only happen for 'special' builds (eg, a release candidate) is extremely trivial. Regards, James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] June / LinuxTag release
James, We might be interested in helping out with the Windows build. We have access to a linux shared server and several Windows 7 machines with Visual Studio 2008 / 2010. Let me know if this works for you? Christian Menge FreedomWorks Inc. US: 609-858-2290 Canada: 905-228-0285 Fax: 347-296-3666 christ...@freedomworks.ca www.freedomworks.ca On reFri, May 7, 2010 at 12:06 PM, James Turner wrote: > I want to make a 2.1 FG release, at the end of this month, or the very > start of June. > > As far as I can see, the current code is pretty good - many bugs have been > fixed since 2.0, and while I'm sure some new ones have crept in, I don't > have many code quality concerns - if we were to cut tarballs from the source > code today, we'd definitely be in a better place than 2.0 in terms of bugs. > > (If people know of regressions from 2.0, or regressions in 2.0 from 1.9.x, > I hope they would mention them here, or even in the bugtracker) > > Anyway, the key thing - what are the steps to make a release happen. I'm > seeking to capture the actual steps (and ideally script them), so even if > Curt & Durk both get hit by the proverbial bus tomorrow, we can still make a > Flightgear release ever again. But also, I'm seeking to remove the human > factors from the release process, and especially not feel that we're > overloading people just because a release needs to happen - eg, around > LinuxTag Durk is often quite busy organising things :) > > My build system ( http://zakalawe.ath.cx:8080/ ) is working well for Mac > and Linux - MinGW is giving me some pain, I will look into cross-compiling > mingw this weekend. If anyone wants to volunteer some time, a Windows box > with Visual Studio, some disk space, and bandwidth, I am happy to work with > them to get an automated VS build going. Adding more automated steps, even > ones which only happen for 'special' builds (eg, a release candidate) is > extremely trivial. > > Regards, > James > > > > -- > > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] June / LinuxTag release
The Android stuff doesn't need patches in the FGFS source code, but does affect the aircraft files (obviously) as well as SimGear and OSG. Please check with me before building in case the associated patches haven't been integrated into upstream yet. On Fri, May 7, 2010 at 9:06 AM, James Turner wrote: > I want to make a 2.1 FG release, at the end of this month, or the very start > of June. > > As far as I can see, the current code is pretty good - many bugs have been > fixed since 2.0, and while I'm sure some new ones have crept in, I don't have > many code quality concerns - if we were to cut tarballs from the source code > today, we'd definitely be in a better place than 2.0 in terms of bugs. > > (If people know of regressions from 2.0, or regressions in 2.0 from 1.9.x, I > hope they would mention them here, or even in the bugtracker) > > Anyway, the key thing - what are the steps to make a release happen. I'm > seeking to capture the actual steps (and ideally script them), so even if > Curt & Durk both get hit by the proverbial bus tomorrow, we can still make a > Flightgear release ever again. But also, I'm seeking to remove the human > factors from the release process, and especially not feel that we're > overloading people just because a release needs to happen - eg, around > LinuxTag Durk is often quite busy organising things :) > > My build system ( http://zakalawe.ath.cx:8080/ ) is working well for Mac and > Linux - MinGW is giving me some pain, I will look into cross-compiling mingw > this weekend. If anyone wants to volunteer some time, a Windows box with > Visual Studio, some disk space, and bandwidth, I am happy to work with them > to get an automated VS build going. Adding more automated steps, even ones > which only happen for 'special' builds (eg, a release candidate) is extremely > trivial. > > Regards, > James > > > -- > > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] June / LinuxTag release
http://calendar.freeflightsim.org/ So we need a working version on the tuesday before .. The following tuesday, U will be taking that to Linux tag.. on a chip ? pete -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] June / LinuxTag release
Shall I put this in the calendar.. so we can all get in sequence together ? pete On Fri, May 7, 2010 at 5:06 PM, James Turner wrote: > I want to make a 2.1 FG release, at the end of this month, or the very > start of June. > > As far as I can see, the current code is pretty good - many bugs have been > fixed since 2.0, and while I'm sure some new ones have crept in, I don't > have many code quality concerns - if we were to cut tarballs from the source > code today, we'd definitely be in a better place than 2.0 in terms of bugs. > > (If people know of regressions from 2.0, or regressions in 2.0 from 1.9.x, > I hope they would mention them here, or even in the bugtracker) > > Anyway, the key thing - what are the steps to make a release happen. I'm > seeking to capture the actual steps (and ideally script them), so even if > Curt & Durk both get hit by the proverbial bus tomorrow, we can still make a > Flightgear release ever again. But also, I'm seeking to remove the human > factors from the release process, and especially not feel that we're > overloading people just because a release needs to happen - eg, around > LinuxTag Durk is often quite busy organising things :) > > My build system ( http://zakalawe.ath.cx:8080/ ) is working well for Mac > and Linux - MinGW is giving me some pain, I will look into cross-compiling > mingw this weekend. If anyone wants to volunteer some time, a Windows box > with Visual Studio, some disk space, and bandwidth, I am happy to work with > them to get an automated VS build going. Adding more automated steps, even > ones which only happen for 'special' builds (eg, a release candidate) is > extremely trivial. > > Regards, > James > > > > -- > > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] June / LinuxTag release
I want to make a 2.1 FG release, at the end of this month, or the very start of June. As far as I can see, the current code is pretty good - many bugs have been fixed since 2.0, and while I'm sure some new ones have crept in, I don't have many code quality concerns - if we were to cut tarballs from the source code today, we'd definitely be in a better place than 2.0 in terms of bugs. (If people know of regressions from 2.0, or regressions in 2.0 from 1.9.x, I hope they would mention them here, or even in the bugtracker) Anyway, the key thing - what are the steps to make a release happen. I'm seeking to capture the actual steps (and ideally script them), so even if Curt & Durk both get hit by the proverbial bus tomorrow, we can still make a Flightgear release ever again. But also, I'm seeking to remove the human factors from the release process, and especially not feel that we're overloading people just because a release needs to happen - eg, around LinuxTag Durk is often quite busy organising things :) My build system ( http://zakalawe.ath.cx:8080/ ) is working well for Mac and Linux - MinGW is giving me some pain, I will look into cross-compiling mingw this weekend. If anyone wants to volunteer some time, a Windows box with Visual Studio, some disk space, and bandwidth, I am happy to work with them to get an automated VS build going. Adding more automated steps, even ones which only happen for 'special' builds (eg, a release candidate) is extremely trivial. Regards, James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
