• 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 2020
    M T W T F S S
    « Dec    
  • Archives

Low Hanging Fruits vs. Seeding a Tree

Low hanging fruits are a tenet of Open Source:  work smarter rather than harder; reuse as much code as possible;  release early and often.  This way spare-time contributions bear fruits quickly.  And yet there are situations when the fruits are not low hanging.  Actually, the fruits do not exist yet.  Somebody has to plant the initial seed and help a tree grow for it to bear fruits.

Seeding and growing takes time.  A Google Summer of Code project is an opportunity for such a seed.  Technically it is a 480 hours project all in one chunk, compared with the average spare-time contributor that puts in 2-4 hours per week and would take 2-4 years to clock that same quantity of hours (not considering the losses due to the pauses between the chunks of work).

So while in most cases the tenet of focusing the effort on the low hanging fruit still holds, it is important not to miss unique opportunities to add new seeds to a project.

Hugin Participates in Google Summer of Code 2011

Congratulations to Habi for spearheading the effort.  A list of all 175 accepted mentoring organizations is here.  If you know of a university student who would like to get paid to write code this summer, let them know about the Google Summer of Code: the student is free to work on a project idea of is liking, including his own original ideas, within the context of a mentoring organization like ours, and gets T-shirt and a neat stipend from Google.

Next step for would-be student participants that wants to do work on the Hugin/Enblend/Panotools codebase is to join the mailing list, introduce themselves and make their intention of participating in the Summer of Code as students known, and work on their applications.  The earlier you start, the better.  The application deadline is April 8 19:00 UTC.

For advice to would-be student participants, look at the Google Summer of Code category in this blog.  Good luck everybody!

Hugin-2011.0_beta 1 released

I just kicked off a new release cycle with the release of Hugin-2011.0_beta1.

It’s only two months since our last release, and yet the project has made another leap forward.  Pablo improved CPFind (Hugin’s own patent-free control point detector) to the next level.  Darko integrated his Google Summer of Code 2010 project, making the fast preview even more interactive.  Thomas added a gray point picking tool for white balance control.  Vladimir Nadvornik added functionality to register stereo images.  And as usual there are lot of small improvement and bugfixes.

From a process perspective, this is the first time that we run a release with a formal schedule.  During the previous cycle I announced my intentions and mostly stuck to them; and when setting up Hugin on Launchpad I did reflect the previous cycles and releases in the project’s history.  But now dates are being put foward.  No panic, oh Open Source purists!  The dates are purely indicative and the principle still stands:  a release happens when it is ready, not when it is due.

From an infrastructure perspective, this is our first release since SourceForge was attacked.  For the first time I am actively seeking redundancy,  using both project hosting infrastructures available to us:  SourceForge and Launchpad.  The tarball can be downloaded here and here.  Nobody likes SPOFs.

To continue what I hope will become a tradition started with the 2010.4.0 release, this release will be dedicated to Claudius Ptolemaeus and Marinus of Tyre.  Details in the ‘about’ menu of the app.

And to start a new tradition, this release will feature artwork from a Hugin user in the splash screen.  There are a few candidates for it and you, the user, get a chance to choose which one will be adopted.  The cutoff date for the voting will be a few days before the first release candidate.

Enjoy the best Hugin ever!

Hugin 2010.4.0 Officially Released

Today I declared the Hugin build released a few days ago final. It is dedicated to Milko K. Amorth, a pioneer of the full spherical panoramic photography that we have lost last year under tragic circumstances.  He will be missed.

This release of Hugins brings a load of new features.  The two most notable are the result of two Google Summer of Code (GSoC) 2010 projects:

The built in control point generator cpfind was the is the GSoC project of Antoine Deleforge, built on top of more than three years of contributions made by too many people to list here.  For the first time Hugin is “feature complete”.  This does not mean that there are no new features coming.  It only means that it is now possible to run the typical stitching workflow end-to-end without relying on third party non-Free packages.

The new underlying controller, Makefilelib, the GSoC project of Florian Achleitner.  Users of the GUI won’t notice, but it enables a more robust stitching process, distribution on multiple stitching nodes, finer grained control and extension of the process through other third party tools controlled by the same Makefile.

More information in the release notes.

Another first: the user-community around Hugin is growing and the user-contributed binaries are already available or will be available shortly after the source code release.  Many Thanks to everybody who has contributed to this great release cycle, particularly to Matthew Petroff for the Windows builds and to Harry van der Wolf for the OSX builds.

Moved 2: From Subversion to Mercurial. Part 1, Setting the Stage

It’s less than four weeks since I drove that 26′ U-Haul truck full of stuff and I’ve had enough of moving for a while.  So why move again?  This is a different kind of move: a move to more efficient infrastructure.  To a decentralized source code repository.  Thank you Subversion, you’ve served us well over the past years.  Welcome Mercurial, a distributed revision control system (RCS) of the next generation.  In this series of three articles I describe how I moved Hugin from Subversion (SVN) to Mercurial (Hg).  In the first part I’ll describe how to kick off the process in the community and set the technical stage on your machine.  The second part deals with the technical code conversion.  The third part with the conversion aftermath and the actual switch.  Once the road is mapped out, the process is a relatively straight forward one.  I made some mistakes while mapping the road and I hope that if you find yourself in the same situation, these articles will help you prevent such mistakes.

Why Mercurial and why Now?

It could have been git, or Bazaar.  They are all equally good.  But I found Mercurial to be the one with the more mature client support, particularly GUI clients on disparate operating systems; and it is well supported at SourceForge where Hugin is currently hosted.  Our project needs to accommodate contributors using Linux, Windows, OSX, BSD and we do not want to leave anybody behind.  To get all stakeholders buy into the process I started a public discussion.

Spring was the right time for repository cleaning.  With a tight integration schedule the team merged most outstanding development branches into the main code line.  Migrating before branching out again for a new set of Google Summer of Code projects will avoid extra complexity.

For more than two years Hugin has been humming along on an asynchronous development and release process that has helped increase the capacity of the project to absorb changes.  Despite a diligent, disciplined and careful team we seem to have hit a scalability ceiling.  It may be lack of resources (except for the Google Summer of Code students during their three months on Google’s payroll, we’re all here in our spare-time) but I suspect that it is also the infrastructure and I expect Mercurial will further increase the capacity of the project to absorb changes.


One of the first questions to arise from the community was the scope of the change.  If already changing RCS, how about reviewing all infrastructure?  Hugin has been at SourceForge since inception.  A lot has happened in the project hosting arena since.  Sites like GoogleCode, Launchpad, BerliOS, GIThub offer a panoply of services – RCS; bug tracking; mailing lists; web and download hosting.  Often different implementations of the same Open Source tools.  Mostly “free” (as in beer, but beware of the alcohol)  for Open Source projects like Hugin.

The RCS, while central to the project, is just part of a project’s infrastructure.  Migrating the whole infrastructure is beyond the scope of this project.  And beyond the available resources too.   Just moving the nearly 200 open bug reports (many of which are stale or duplicate – the bug tracker needs a good spring cleaning too) to a new bug tracking system can keep a spare-timer busy for months.  SourceForge may not be the most fashionable choice, but it works for us.

Server and Client

On the one side is an existing SVN repository on the SourceForge server.  On the other side is a new Hg repository on the SourceForge server.  How do I move the code from one side to the other?  The first mistake I made was to work on the SourceForge server itself.  This slowed me down and ate their precious bandwidth.  I should have known better: SVN runs on the server sitting in my office closet.  Even that was too much overhead.  The most efficient way to go about the task is to mirror the SVN repository to a local client and work from there.

These are the steps for a K/X/Ubuntu distribution:

sudo apt-get install mercurial subversion python-subversion
svnadmin create hugin-mirror
cd hugin-mirror
echo '#!/bin/sh' > hooks/pre-revprop-change
echo 'exit 0' >> hooks/pre-revprop-change
chmod +x hooks/pre-revprop-change
export FROMREPO=https://hugin.svn.sourceforge.net/svnroot/hugin/
export TOREPO=file://`pwd`
svnsync init ${TOREPO} ${FROMREPO}
svnsync --non-interactive sync ${TOREPO}

The initial sync can take hours or more.  This is a good time to take a break.  If the sync is aborted, you may need to reset the lock state and restart the conversion:

svn propdelete svn:sync-lock --revprop -r 0  ${TOREPO}
svnsync --non-interactive sync ${TOREPO}

It’s a good idea to repeat the above two commands in a cron job or a startup job to keep in sync with the repository over time.

Your local machine is set for the job.  Keep the discussion in your community going, to get all relevant stakeholders to buy into the process. On the next installment we’ll look at how to map the road.

Hugin 2010.0 Released

Last week Bruno released Hugin 2010.0. It was almost immediately followed by binaries for MacOSX (Harry), Debian/Ubuntu (Andreas), Fedora (Terry). The step from release candidate to release had been longer than usual because of the lack of feedback from Windows builders/users whose interest seems to have shifted to the development version, which has already a few new cool features such as a masking tool.

Trunk still has a few rough edges, but overall is ready for the next cycle. Consensus is forming on moving the codebase to Mercurial and potential new Google Summer of Code projects are being discussed on the mailing list.

Hugin Participates in Google Summer of Code 2010

Congratulations to Bruno, James, and Tim, for doing all the legwork and getting accepted for a fourth participation to this Google initiative that helps attract new talent to Open Source projects.

Hugin will be accepting candidates, and it is never too early to join. You can read some advice on how to apply in past posts to this blog tagged Google Summer of Code.

I won’t be part of the mentoring organization this year. Our family is currently in transition and I don’t have any spare time. I look forward to post a panorama of our new home, roughly 1000 Km further West, but our schedule is slippery as well.