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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
