• 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

    October 2009
    M T W T F S S
    « Sep   Nov »
     1234
    567891011
    12131415161718
    19202122232425
    262728293031  
  • Archives

Here We Go Again


hugin-logoHugin 2009.2.0 is still warm and fresh out of the oven and I have started the next release cycle. Hugin 2009.4.0 is coming soon to a download server in your neighborhood. The beauty of parallel development without trunk freeze and the discipline of managing the integration queue are starting to pay off: while I was managing the 2009.2.0 release, Tim added lens calibration to trunk and Thomas added a tool to clean outlaying control points by statistical method.

Three simple criteria and three increasing levels of maturity reduced the bottleneck that has plagued Hugin in the past three years as it had to learn to absorb more change than ever.

The three levels of maturity are:

  • “works for me”
  • integration in trunk
  • release to the general public

And the three tests are

  • functionality
  • multi-platform build
  • regression

Works for me

Developers are no longer hindered by trunk freezes. They can work on their ideas any time, simply by branching out a development codeline either locally or in the central subversion repository (I know distributed revision control systems. Andrew implemented Mercurial for Enblend and I love it. Right now Hugin is undergoing enough change. In a quiet moment we’ll open a discussion about the revision control system).

When the implementation is ready to move to the next level, it is checked against the three criteria. A development codeline – whether under revision control or presented as a patch against trunk – is considered mature when:

  • the functionality it is intended to implement works on the developer’s machine (“works for me” condition)
  • it has been tested to build on the major supported platforms (“does not leave them behind” condition) by at least one contributor for each: Windows, OSX, Linux
  • it does not unintentionally break existing functionality (“no regression” condition)

When a development codeline reaches maturity, it enters the integration queue.

Integration Queue

The integration queue is the ordered list of new features / development codelines waiting to be integrated in trunk. The prioritization is a collective decision by consensus of the developers. Silence = consent. The discussion, and the latest version of the list, are on the mailing list.

The integration queue is not set in stone: a change in the maturity status of a feature in waiting is good reason to review/change the ordered list. In any case it is reviewed after every release branching.

The integration queue is all about coordination. The code matures further. Ideally developers talk and there should not be conflicts. In the real world changes in trunk may affect the new functionalities or the other way around. This is the the time to solve this kind of conflicts, and to test the code on a (slightly) broader basis.

A feature from the integration queue is ready to be merged into trunk when

  • the functionality it is intended to implement works on the machines of the testers who bothered to play with the codeline (“works for them” condition)
  • it has been tested that a merge with trunk builds on the major supported platforms (“does not break trunk” condition) by at least one contributor for each: Windows, OSX, Linux
  • it does not unintentionally break existing functionality (“no regression” condition)

This limits the time during which trunk is unavailable. Integration of the features that have gone into 2009.2.0 and will go into 2009.4.0 was almost seamless. And the clean up from the 2009.2 release cycle has benefited trunk so mcuh that the 2009.4 release cycle is expected to be even faster.

If trunk has absorbed a feature from the integration queue and we’re not yet ready for a new release (e.g. because the current release cycle is still on), integration of the next mature feature from the integration queue starts.

Release

Developers are polled once a month whether trunk warrants a release. If there are enough new features and/or bug fixes compared to the last release somebody starts a release cycle. Instead of releasing from trunk, forcing a freeze, we now branch out a release codeline. That release codeline absorbs all the change control that was slowing down development in trunk to a halt. And the polishing changes that it get benefits trunk at the same time.

Again, a release branch is declared matured and released to the public when

  • the functionality it is intended to implement works for a larger number of testers (“works for the public” condition)
  • it has been tested to build on the major supported platforms (lives up to Hugin’s ideal of being “truly cross-platform”)
  • it does not unintentionally break existing functionality (“no regression” condition)

Resources

All of this would not be possible without human resources: developers, translators, builders, documenters. A big thank you goes to all of them for making this new, more dynamic pace of development possible. The recipe is relatively simple: every resource is self-directed. The least control is exercised on it, the more likely it is to contribute to the project. So the only controls are the maturity tests – and they can be self-administered. Self-responsibility and empowerment reign.

To me resources are like water. They will flow to an attractive codeline like a stream flows into a riverbed. Barrages (such as a trunk freeze) only impede the flow. Water finds alternative ways, and so do potential contributors. My only task left is to remove bottlenecks. Let them flow!

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s