Contributed by johan on from the stories-from-the-factory-floor dept.
With every new release more and more new users are attracted to Puffy and invariably there are questions regarding the OpenBSD release cycle and process. Although this is already well documented in the FAQ, let's take a look at what it takes to bring a new release to life.
Please read on for the rest of Mitja's story:
The development cycle starts immediately after the last release (actually even a bit earlier, as we'll see). The main storage of all the development work is the project's central source code repository, CVS. The developers commit their work for safekeeping and distribution to the CVS repository and the resulting code is referred to as OpenBSD-current. It is here that all the development work is done, -current is the bleeding edge. It is also a moving target, with an average of 40 commits per day, and the changes committed can range from fairly trivial to very complex and widespread. Nevertheless, the development source tree is never intentionally broken; if a committed change breaks the compilation, it is immediately fixed or reverted to a working state. Why? The reason is simple: on majority of supported platforms the entire system gets through a mock release process every few days to make sure everything builds correctly. The results of these test builds are called snapshots and are an important part of the overall testing process. Snapshots are also a great way of following the development without getting your hands too dirty - by doing a simple binary upgrade from snapshot to snapshot you can get a preview of what the next release will contain and through bug reports help developers with their work.
OpenBSD has two releases per year, May and November 1st - the four months following a release are dedicated to development and the final two months in each cycle allow for the stabilization of the code and the actual build of the release. Typically the bulk of the major changes happen early in the release cycle, often during a hackathon, so there is enough time for the addition of new features and various improvements. Around mid-cycle the work turns towards less glamorous bug fixing, cleanup and general stabilization the code, until some 10 weeks before the release date the softlock goes in effect. This is a time for finishing touches on the soon-to-be-finalized code, the commits are carefully scrutinized and slowing down to a trickle until the full lock of the tree is reached - nothing more goes in. At that point, the code is frozen and the releases for all the architectures are built and verified. Finally, the release files are sent to the CD manufacturing plant a good month before the release. The source tree is at this point unlocked again and the developers eagerly start a new cycle of committing - by the time of the actual release, -current and the associated snapshots are already well ahead running at full steam.
As the release day approaches, the fanout FTP mirrors receive the full release builds and the CD sets arrive from the manufacturing plant to the main OpenBSD distributors. The CD sets are often early, so they are shipped ahead of the release date to those that have placed preorders - what better way to reward those who by preordering help cover the cost of making the CD sets?
At last, the release day comes with the traditional announcement on the mailing lists, unveiling of the new release's folder on the FTP mirrors and official publishing of the CD sets. It does not end here though - in CVS, a new branch named -stable is created and for the next 12 months all the security and reliability fixes from -current will be backported to the -stable version of the just released code.
At the moment of this writing we are nearing the OpenBSD 4.4 release date and the preorders are already open. So if you want to help funding this release and the work for future ones, place your preorder now (international, europe)!
(Comments are closed)