• Subscribe

    Subscribe to This Week In Panospace by eMail.
    Subscribe in a reader
  • License

    Creative Commons License
    This work is © 2008-2012
    by Yuval Levy
    and licensed under a
    Creative Commons License.
  • Entries

    January 2009
    M T W T F S S
    « Dec   Feb »
  • Archives

Alarm Clock

hugin-logoHere we go again. I prompted a discussion about the Hugin release cycle. And lucky me the wheels started turning. The effort took a dynamic of its own while I was going through a very busy period at work (I’ll post about it tomorrow).

It’s now half a year since Google Summer of Code 2008 finished. Three out of five projects have ripened to trunk. The new Libpano projections are usable in trunk. Bug reports are clogging the bug tracker again, and it seems that the pipeline is frozen. Deep winter?

Under the surface there is boiling excitement. We have a new and very active team member, Lukáš Jirkovský, who has upgraded the codebase to the latest vigra version and is now going through the bug tracker at a fast pace; and Andrew Mihal has developed GPU-powered stitching (powerful videocards are no longer for gamers only). And maybe in a few months Google Summer of Code 2009 is coming.

How do we unclog the pipeline? And most important, how can we prevent future clogging and keep it going indefinitely?

Triggering an ad hoc discussion to wake up the bear from winter sleep is not a good way to keep the release cycle ticking – not even in the world of Open Source. Ubuntu and others have recognized it and have moved to fixed release dates. It’s not ideal, but it’s better than a protracted never-ending and thus frustrating development cycle.

As it could be expected, the discussion, particularly on branching and tagging and the process from the repository to a release attracted many opinions. As Gerry Patterson wisely said, doesn’t everybody have ideas on how to release software?

I am OK with most of the ideas expressed… as long as ideas are followed by action, and action is followed by results. We need to keep the release process ticking, and make it independent.

The generic process which all of the expressed ideas share is the release cycle:

  • develop
  • test locally (development branches, local copies, etc.)
  • test broadly (trunk)
  • release to the general public
  • repeat

And somehow we keep getting stuck in the first three steps.

What we lack are mechanism to move things between the different stages, particularly from the broad test to the release. When is a new development ready for broad testing? when is the project ready for a release to the general public? We need some policies, a way to make such decision that makes them independent of people.

I believe that a moving target like the Hugin project should try to move code piecemeal (as opposed to one big bang), and do it as frequently as possible. We need a lean process that can be repeated frequently.

Moving the code along the first three stages is not so much the issue. Most developers agree to a simple policy: Commit to trunk as early as possible. If local, limited testing shows that no major functionality breaks, move the code to trunk. This is the only way to expose it to broader testing and peer review.

There is a more varied opinion about the release itself. It can’t be replaced by a snapshot (just tarball the latest trunk) because maintaining trunk into a releaseable status all the time requires a considerable effort and slows down the testing of new features in trunk. Moreover, snapshots are not always as polished as users expects production software to be.

One possibility would be to decouple the development cycle from the release cycle, and let the clock control the release cycle (without putting pressure on the development cycle): when the time has come, features that are in trunk and are ready for release are released, while features that are not yet ready are kept for the next release cycle.

It does not really have to be the clock. It could be the readiness of the feature. Then we’d release at every feature. Problem is: how/when to declare a feature ready? The clock would force us to have a look and see if it is ready enough for release or not.

After Google Summer of Code 2008 we had three features move into trunk in a rapid succession: James Legg’s fast preview; Marko Kuder’s PTbatcher, Tim Nugent’s Celeste. Each one of them would have warranted a release in my opinion. So we could have released 0.8.0 (0.7.0 + fast preview); 0.8.1 (0.8.0 + PTbatcher); 0.8.2 (0.8.1 + Celeste). The result would have been a release every two months.

Instead, all of these beautiful features have cumulated in trunk, accessible only to those that venture into building Hugin for themselves. And now, over Christmas, we would have had 0.8.3 (0.8.2 + the new libpano projections). Instead, once again, the commercial stitching application are catching up and will release similar features to the general public before us.

A clock driven release cycle isn’t that bad after all – or are you one of the few people that wakes up in the morning to go to work without an alarm clock?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s