Looking toward the Indigo finish line

This week, the Eclipse and Equinox projects released 3.7RC3.  For the past month, we have been in end game mode.  This means that make release candidates available about once a week, each with progressively stringent requirements to release a fix. All code changes require approval as follows

RC1 - Another committer must +1 your bug before you can submit a change.
RC2 - Two committers must +1
RC3 - Two committers and a component lead must approve.
RC4 - Two component leads must +1 your bug. A component lead can veto your change. Steve Northover coined the term intergalactic approval for a bug fix at this stage of the game.

Image © lrargerich, http://www.flickr.com/photos/lrargerich/4999906554/ licensed under Creative Commons by-nc-sa 2.0 

During this entire period, documentation changes can go in without approval.   During RC3 and later, all code changes must be announced to our project's release engineering mailing list to communicate to the other committers that you intend make a change.

There are some interesting parallels between the Eclipse end game and long distance running.  This weekend, 40,000 runners and 100,000 spectators will participate in Otttawa's Race weekend.   The week before their race, athletes participating in the longer distances will taper their runs.  In other words, their training mileage drops significantly so that they're well rested for race day.

Image © Gamma-Ray Productions, http://www.flickr.com/photos/29143375@N05/3574211684/ under Creative Commons by-nc-sa 2.0 


At Eclipse, the process is similar.  We taper our bug fixes as we approach release day. Eclipse is known for it's stable and predictable releases. At lunch yesterday,  my committer colleagues remarked that some of their dependencies (not Eclipse projects) just release at regular intervals and and don't have a ramp down process.  Other projects release occasionally and then don't have a release for several years.  No predictable release schedule.  At Eclipse, we are predictable and stable.  Some may call that boring, but it allows other projects and products who depend us to consume us at regular intervals.  Eclipse 3.7 is especially stable this year given that many committers have been busy releasing innovative new features to Orion and Eclipse 4.1.

We also have weekly test days where the committers and community test the builds and ensure that there aren't any regressions that were recently introduced.  For example, here is the PDE team's test plan. 

In addition to reducing the amount of changes we release to the build,  to ensure the stability of the code base, this tapering of bug fixes and the associated approval process also ensures that other committers have a chance to evaluate our patches.  This sanity check ensures that the fixes are both significant enough to warrant releasing to the build at this time and technically correct.  I can't speak for other committers, but at this stage of the Eclipse release, we are all a bit tired.  So it's good to have several sets of eyes looking at your patch.

Committer after Indigo release

Image © kaibara,http://www.flickr.com/photos/kaibara/4068996309/ licensed under Creative Commons by-nc-sa 2.0 

At this stage of the game, only serious bugs are fixed.  It's not worth causing ripples within the code to fix a minor bug only to find out after the release is available that this fix had intended consequences.

Image © Marc Dezemery, http://www.flickr.com/photos/mdezemery/295687769/ licensed under Creative Commons by-nc-sa 2.0

What process does your project use to ensure that your code base is ready for release?

Further Reading
Eclipse 3.7 Endgame plan