From: Durk T. <d.t...@xs...> - 2010-06-15 20:58:02
|
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 |