• 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 2010
    M T W T F S S
    « Sep   Nov »
     123
    45678910
    11121314151617
    18192021222324
    25262728293031
  • Archives

Hugin 2010.2.0 is out


Hugin 2010.2.0 has been released more than a week ago.  I was traveling when Bruno made the announcement officially sanctioning the second release candidate, moving new features such as mosaic mode and masking one step closer to the user.  But this is not the last step.

As usual it is a source-code only release.  Contributors will build binaries out of it that will eventually trickle down the official distribution channels in the coming weeks and months.  As usual the beggars are faster than the contributors.

While the project strives to make user’s life easy with binaries, the only way to release source code and binaries for all platforms at the same time would be to introduce an artificial delay in the release process, which in my opinion is a very bad idea trying to creep in from the world of proprietary software.

There is a natural sequence of events before a new feature hits the user’s desktop:  first there is source code, then it is compiled, then it is tested.  When the tests are conclusive the source code is packaged and distributed to builders who compile user-friendly installers for distribution.  It does not happen overnight.  The source code is naturally ready before any binary.

Marketing controls the release process in the world of proprietary software.  Everything is done in secret.  The effort of keeping everything under the radar screen until a big-bang launch is justified by the resulting publicity and boost in sales.  Everything is delayed until the launch campaign is ready, the product is ready, the distribution channels are ready.  The release announcement is made with the sole purpose of motivating consumers to buy.

It is the opposite dynamics in Open Source.  Delaying the source code release until all installers for all platforms are ready to ship only hinders progress.  It is better to let the developers move on with further improvements rather than freeze them while waiting for a synchronized release.  Since we don’t sell the software, there is little benefit to such synchronization.  Builders and distributors will take care of the details of producing binary installers for the end-user asynchronously in due time.

Open Source development is a continuum.  Strictly speaking, every time a developer pushes a changeset into the repository he is making a “release”.  He is releasing his newly add code to the general public.  There is even an RSS Feed of such releases.  It’s interesting to developers and others that are threading on the bleeding edge, but to the average user this is mostly boring overload.

The purpose of a release cycle is to motivate contributors to polish up their contribution – whether they are code, translations, manuals, tutorials, installers.  The release announcement is the point where the focus of the release cycle shift from code/bugfixes to preparations for distribution.  Stay tuned for binary distribution to start as soon as possible.

6 Responses

  1. Um, let me see. You don’t like people asking for binary builds after source code is released, yet you dislike simultaneous release of source code and binaries that de facto protects you from “beggars”. Fancy that!

    Delaying the source code release until all installers for all platforms are ready to ship only hinders progress. It is better to let the developers move on with further improvements rather than freeze them while waiting for a synchronized release.

    As if you never branched a stable release to continue working on trunk.

  2. @Alexandre: I did not state that I do not like people asking nicely for binary builds after source code is released.

    What I dislike about the beggar is that he did not even try to help himself to satisfy his need, demanding instead that the developers who just released source code spoon-feed him.

    If he had a little bit of respect for contributors he could have helped himself in the list’s archive. No need to dig hard. During this release cycle there have been more binaries for his platform than for any other supported platform, and probably one of them was an RC2, equivalent to final.

    Sure, I introduced to the Hugin project the notion of branching out a stable release to continue working on trunk. Asynchronous development benefits everybody, setting resources free to work on what they care for, not what is demanded by others.

    Sometimes synchronization is necessary and inevitable (e.g. the dependency of Hugin 2010.2.0 on Libpano13-2.9.17 being released). In every other case I rather go asynchronous for Hugin, letting developers focus on development and builders/distributors focus on polishing the release and bringing binaries to the masses.

    Synchronization with the binaries releases is IMHO neither necessary nor inevitable and its cost far outweigh the benefit. Binary builders do announce their releases. It’s a different channel, even if it is using the same mailing list. Those are different dynamics (e.g. the package managers of Debian and Red Hat Linux, the source code ports of FreeBSD and Gentoo Linux, the unmanaged stand alone downloads of OSX and Windows); different contributors (almost all contributors to the binaries builds are not contributing to the code development. Nor are they expected to.); different timings. No need to introduce artificial dependencies. Release early, release frequently.

  3. I did not state that I do not like people asking nicely for binary builds after source code is released.

    Well, I have to admit that I didn’t follow the link, but “beggars” definition bears a certain negative connotation :)

    Sometimes synchronization is necessary and inevitable…

    In my experience syncing source and binary releases saves a lot of embarrassment, when it’s about large projects like Inkscape.

  4. @Alexandre: Yes, “beggars” bear a negative connotation and I was alluding to exactly this connotation when referring to the specific post on the Hugin-PTX mailing list.

    I see your point about embarrassment and if avoiding embarrassment is important to you, then the benefit justifies the extra effort. Good for Inkscape if this works for you. To me, in a context where I am not guaranteeing anything to anybody, embarrassment is unimportant.

    I take this opportunity to state that I am thankful to you and the Inkscape community for a great tool that I am using more and more frequently. I love Inkscape. It definitely has more mainstream appeal than Hugin (i.e. there are sure more people who do an occasional sketch than people who do an occasional stitch).

    From the little I know about the Inkscape project, you seem to have been long ago where Hugin is now, and maybe we can learn a lesson from you in the future.

    Your code now lives in Bazaar on Launchpad but you were using Subversion on Sourceforge until a few years ago where you probably even used CVS in the past? Hugin just moved from Subversion to Mercurial only a few months ago.

    You now use Launchpad for bug tracking, but maybe you have used SourceForge in the past? The SourceForge bug tracker is utterly inadequate from my perspective and I have it on my todo list to look for alternatives and suggest them to the Hugin project. Launchpad is on my short list.

    From quickly browsing your old repository I guess that you had a static website managed in Subversion, like Hugin still has; but you now have a fully fledged CMS? Hugin does not have the resources to maintain this.

    If you have the resources to maintain complex websites, you may as well have the resources to maintain and synchronize multiple build systems. We don’t. We depend on these resources being provided by the users communities for each platform, and most of these contributions are still too volatile to be added as a mandatory dependency in the release process.

    The original idea behind http://wiki.panotools.org/Development_of_Open_Source_tools was to develop such resources, but as long as these resources are not reliably available over a long period of time, making a single synchronized release of binaries + source code is IMHO counter productive because it raises expectations and sets dependencies that may be difficult to fulfill later down the road.

    The above mentioned wiki page developed pretty well for some platforms, and not so well for others. Personally, I try to make sure that the information for the platform I use is up to date.

  5. To me, in a context where I am not guaranteeing anything to anybody, embarrassment is unimportant.

    Well, different strokes, as you very well know :)

    I take this opportunity to state that I am thankful to you and the Inkscape community for a great tool that I am using more and more frequently. I love Inkscape.

    Always welcome :)

    i.e. there are sure more people who do an occasional sketch than people who do an occasional stitch

    Oh, I’m pretty sure there are a lots of surgeons around who do occasional stitches :) However, to escalate things just a little bit, Inkscape is nowhere close to popularity of GIMP. Check Google Trends if you are curious :)

    Your code now lives in Bazaar on Launchpad but you were using Subversion on Sourceforge until a few years ago where you probably even used CVS in the past?

    I don’t think we ever used CVS, but I could be wrong. Sodipodi (from which Inkscape was forked) did use CVS.

    You now use Launchpad for bug tracking, but maybe you have used SourceForge in the past?

    Yes indeed, and it was one of the reasons for moving to Launchpad. BTW, when you move projects from SF to LP, you get automagical importing of repositories *and* bug tracker issues. It’s rather important.

    From quickly browsing your old repository I guess that you had a static website managed in Subversion, like Hugin still has; but you now have a fully fledged CMS?

    It’s a custom and somewhat ugly in its way PHP based solution which noone takes the nerve to ditch in favor of Drupal. There is a proposal to do that, we are just waiting for the guys to finish whatever they are currently busy with and get on with actual work on both design and CMS.

    If you have the resources to maintain complex websites, you may as well have the resources to maintain and synchronize multiple build systems.

    Historically it’s one of our weak sides actually, just as with “complex websites”. We still don’t have centralized infrastructure for storing nightly builds. They are scattered across servers (win32 and mac in one place, ubuntu repo in a different place and not really working, iirc).

    The original idea behind http://wiki.panotools.org/Development_of_Open_Source_tools was to develop such resources, but as long as these resources are not reliably available over a long period of time, making a single synchronized release of binaries + source code is IMHO counter productive because it raises expectations and sets dependencies that may be difficult to fulfill later down the road.

    IMHO what it really boils down is having a team with expertize in building for various platforms and instant presence on-line. The more complicated a tool is (both amount of lines of code and technologies used), the more dependencies it requires and the more platforms it supports, the more difficult it is to find contributors. Did you know we still don’t have Inkscape build for Mac using native Quartz port of GTK+?

  6. @Alexandre:

    when you move projects from SF to LP, you get automagical importing of repositories *and* bug tracker issues. It’s rather important.

    Why is the automagical importing of repositories *and* bug so important to you?

    I see the relationship between the two linking between code revisions, log entries, and bug reports. A URL reference from one tool to the other is IMHO enough. Further integration comes at a cost of lesser flexibility. I rather retain the flexibility than being bound to a specific combination of repository and tracker.

    Repositories and bug trackers are, in this order, the critical infrastructure to a project. A project may or may not want to bundle them with a specific tools combination and/or with the same provider.

    What is more important from my perspective is control (or lack thereof) and flexibility, as well as redundancy/backups. Think of it as: I want to encourage forks.

    From that perspective I am happy with SourceForge. The repository is easy to clone and move to other tools and providers,, especially since we moved to a distributed SCM of the last generation. Dumping the trackers in an XML format that can be imported, for example into Launchpad, is as easy as pulling a URL:

    https://sourceforge.net/export/xml_export2.php?group_id=77506&show_projectsummary=0&show_projectresources=0&show_projectnews=0&show_filereleases=0&show_forums=0&show_trackers=1&show_tasks=0&show_projectadmin=0

    SourceForge’s limitation from my perspective is a very cumbersome bug tracker, and that’s the only thing I am looking to replace at the moment.

    If it comes in a bundle with a change of SCM, it may not be worth the effort.

    IMO Launchpad has a better bug tracker than SourceForge. But it also comes with an (understandable) bias toward Ubuntu and a rather inflexible choice of SCM (Bazaar). I understand and respect the rationale for Launchpad’s choices. They may or may not be compatible with Hugin.

    At the moment I still know too little about Launchpad to judge. An export functionality for the bug tracker; and the ability to run the bug tracker only without repo; are my two judging criteria.

    I don’t worry so much about the objections mentioned in the comments to http://blogs.gnome.org/jamesh/2007/11/28/inkscape-migrated-to-launchpad/ – the Free vs. free debate is always poisonous; and there will always be personal preferences in favor or against specific tools.

    IMHO what it really boils down is having a team with expertize in building for various platforms and instant presence on-line.

    Agree. It can be broken down further into: enough people with access to resources/infrastructure and expertise/knowledge. I can’tinfluence resources/infrastructure (i.e. buy enough Windows and OSX licenses and offer them to willing contributors), so the “instant presence on-line” is subject to the law of big numbers and Hugin is getting there slowly but surely as the project grows. Did you notice that we had more experimental Windows builds during the current release cycle than ever before? and there were more than for OSX and all Linux variations together?

    I can help with the expertise/knowledge and this is what the wiki is about. The instructions are simple enough to help a person with basic typographical and reading skills to get on the learning curve in a few hours.

    I always welcome improvements. At the moment I don’t see how this could be improved. So we keep the tarball releases as our pace-makers, and not binary releases.

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