• 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

    March 2009
    M T W T F S S
    « Feb   Apr »
  • Archives


A discussion on plagiarism is raging amongst Google Summer of Code mentors. The trigger was a student who copy & pasted his project proposal from the web, “stealing” bits of Wikipedia and other sources without attribution. Despite being very busy, I could not resist the interesting discussion across cultures and values when a mentor stated that he “totally fails to believe there is *any* culture in the world where copying someone else’s work is considered a valid method for demonstrating “expertise”. That doesn’t really have anything to do with values etc. — it’s just plain common sense.

Plagiarism is a natural survival strategy that has proven itself throughout evolution. find one animal species that does *not* copy superior behavior (when they can, of course).

Drive a car? pay royalties to the inventor of the safe tires: the worm from whom scientists have copied the structure resistant to wear and tear when rubbing with earth.

On the other hand, our western view of intellectual property is very recent (slightly more than a century old). Over a short time span it has proven to have some desirable qualities, but also some blatant defects.

Protecting artists and inventors fosters innovation. Granting years-long state-sanctioned monopolies to patent-holder prevents spreading innovation. A balance need to be stroke. This calls for cultural norms.

In some cultures the inventor is just considered as being the lucky one who has discovered the invention first. other than that, no protection is granted to them.

Open Source also has a culture, in which plagiarism as lack of attribution is considered very bad. On the other hand, plagiarism as code reuse with attribution is considered very good. Quite different from mainstream western culture where attribution is not enough – greedy patent trolls and media giants want your money.

What is right and what is wrong? There is no absolute. There is a here and there is there with different values that need to be bridged if we want people from there to come here.

Mike Melanson posted a link to this hilarious movie:

And Nicolas Robidoux summed it up: Plagiarism is bad. Reinventing the wheel is stupid.

Last Minute

Groundhog protecting his holeStudent life is busy life like every life. It happens often that students become interested in the Google Summer of Code very late. Most of our students in the past three years contacted us for the first time during the application period despite all our attempts to reach out and engage them early through a network of academic contacts. The reality of life is that few people have Eisenhower’s discipline to manage their time. Only when an important issue becomes also urgent we see it on our radar screen and deal with it in a rush against the deadline and the chronic lack of sleep.

“Most things which are urgent are not important, and most things which are important are not urgent”. Dwight D Eisenhower, 34th President of the United States

Eisenhower's Priorities

Now it is not the time to plan participating in GSoC, it’s the time to do it. Time is short, and if you are like the many who started thinking about Summer of Code now, you will need to go full speed.

  1. Introduce yourself to the community. Join our mailing list and tell your story. Tell us who you are, that you intend to participate in th Google Summer of Code with us. Share your interests and passion. Motivate us to invest an effort in your application. Our time is limited too and you are competing for it.
  2. Register on the Google Summer of Code site. Important: note your LinkID.
  3. Get your tools ready. The instructions for Windows, Mac, Ubuntu and other platforms are in our wiki.
  4. Hack the code. Show that you can read it and make changes to it. Submit a patch to the mailing list. I wrote about this yesterday.
  5. Have a look at our project ideas page. Is any idea appealing to you? You’ll need to make a choice quickly and develop it fast. Google for it. Read. Talk about your wishes and doubts and seek guidance on the mailing list. Chances are that if you are engaging enough, the community, and more particularly the idea originator(s) and potential mentors will react and help you. The sooner the better.
  6. If you have ideas of your own, discuss them on the mailing list. Some of the most brilliant projects came up as suggestion from the student, not as an idea from our list. Don’t be shy, shine!
  7. File a proposal before the deadline. If you’re really pressed, don’t worry if it is incomplete, just make sure you can complete it in the following days or it will be ignored. To file a proposal with us, point your web browser to http://socghop.appspot.com/student_proposal/apply/google/gsoc2009/<your LinkID>?organization=hugin
  8. Last but not least: don’t just do the talk, do the walk! It’s time for you to take the initiative.

And if time is a crunch and you can not make it this year, stay tuned. Maybe next year there’s another opportunity, and maybe by then you will have set aside time early enough.

Hugin-0.8.0-beta3 released

hugin-logoBruno just released a tarball of the third beta in this release cycle.

A Patch, The First Milestone

hugin-logoBefore considering students for the Google Summer of Code, we ask that they provide a patch against the current codebase. Admission to the program is competitive, and some candidates may perceive the patch as part of the competition. It is not. The competition is at the proposal level, but you need a patch for your proposal to be considered. Why do we ask for a patch?

Think of it this way: when you take a taxi ride from the hotel to the airport, you trust somebody you don’t know. However it’s not blind trust: some simple and implicit observations give you good reasons to trust the driver: if he can knock at your door, he must have the vehicle to get there and the skills to drive it. Furthermore, while he’s loading your luggage into the trunk, you get a chance to observe his vehicle and his behavior. By the time you start the journey with him there are still no guarantees that he won’t get lost or have an accident, but at least you know that he has the basic tools (the car) and the basic skills (he drove it up to your door). You have done your due diligence.

Similarly, you need to quickly build the same level of trust with our community. Do you have the tools it takes to hack into the code? and do you know how to use them? When a contributor uploads a patch to our mailing list or to our tracker (preferred, but to make sure you get noticed please post a link on the mailing list too) he builds instantaneously the same level of trust that the unknown cab driver builds with every new customer: he implicitly shows that he has the tools (hardware, operating system, internet connection, coding environment, repository access) and that he can use them for basic operations.

This is just the beginning of the journey, not the destination. It is a task designed to show basic proficiency. We will not choose our student based on this task. We will choose her based on her proposal. But we won’t consider her proposal if this task is not done, because what use is a driver who promises to get us to the airport if he can’t pull up around the corner and park in front of our door?

My recommendations for the patch, at this point:

  • Get yourself the right tools. Ubuntu, Windows, OS X, almost any platform will get you there. Some are easier than others. When in doubt, ask on the mailing list.
  • No inspiration? Check Bruno’s suggestions.
  • Get it done and out of your way quickly, so that you can focus on your proposal in the little time left before the deadline.

What you should not try to do is something like this patch by 2008 student Tim (likely 2009 mentor). It is very nice, but it was done after a Summer of Code, not before. Those who started early like Lukáš have had plenty of time to establish a deeper relationship with the community, and produce some big patches. If you are starting just now, you need to focus. The deadline is April 3. You can impress us between the moment you get the patch done and the application deadline, April 3. And if you need help, ask. We’re here to help you. Good Luck.

Bliss… and a lot of work coming up

MascotteGoing from boots on snow to barefoot on the beach in less than six hours is bliss. Logging into the hotel’s wireless network and finding out that Hugin/Panotools is on the list of accepted Google Summer of Code mentoring organizations, priceless! Best of them all: my son enjoyed his first flight ever and is charming his grandparents who made the other half of the trip, over the Atlantic.

Thank you, Google Open Source Program Office, for accepting us into the program once again. You have been a source of fuel and motivation for us and you are helping us grow a strong and active developers community!

Next week I will post more detailed information as the activity for the next few weeks is shaping up.

  1. Recruiting students. If you are a student interested to work on 3D vision and make a little money this summer, we want you! And if you know students, please tell them. This year the Hugin/Panotools GSoC mentoring team has grown with the addition of Sébastien Roy and his 3D Vision Lab at Université de Montréal. They have a lot of interesting research projects going on there, so if you would like to use half a dozen projectors to create a really immersive display, or use the Nintendo Wiimote to control panoramas or other objects in 3D space, stay tuned for more information. Nicolas Robidoux of Laurentian University in Sudbury is offering students access to infrastructure there. Combine travel and coding in this beautiful part of Canada. Last but not least, join us at Libre Graphics Meeting.
  2. Complete the infrastructure for an exhibition of Ultra Wide Views at LGM. The transactional part of the site is currently not active yet, I hope to get it done next week.

First things first. It’s family time until the weekend.

The Dos and Don’ts of Subversion Control System

Groundhog protecting his holeThe Hugin community is a warm and welcoming place. From our community’s charter: We often encourage users to become contributors by proactively offering them SVN write access. Such access to Subversion (SVN) can be intimidating. Fear not, version control systems are the tool to avoid irreversible unintentional damage. When a potential contributor asked the question again I did not find an answer on the web, so I set out to write this article.

Repository Areas and Policy

The best-practice SVN repositories are divided in three areas: trunk, branches and tags, each of them with different purpose.

That’s enough for Hugin. Combined with the intrinsic characteristics of version control it makes our repository a safe place to experiment. So far we did not need repository policies, just use good old common sense.

Larger projects may have written policies about repository status. Some depend critically on areas of their repository building at all the time and at every revision. Before committing to such repositories, changes must undergo all sorts of tests, often specified in written documents as well.


Trunk is the famous bleeding edge. Most developers will be active on trunk, fixing bugs and adding features incrementally. Mistake happens where people work. No blame. Bugs can be often identified by stepping back a few revisions and comparing to HEAD (the latest revision).


Branches are copies, mostly of trunk, that started at a specific revision. From that point on, the branch differs from the original. They can have many purposes, and the specific dos and don’ts depend on that purpose.

  • If a branch is meant for release do fix bugs and don’t add new feature.
  • If it was started by a developer to develop a new feature, ask him first before fiddling with his work.
  • When in doubt, start your own branch. Branches are cheap in Subversion. Most Google Summer of Code projects start their life as a separate branch.

Development branches eventually merge into trunk and become obsolete. Release branches are superseded by later release branches. On occasions parallel branches make sense and are maintained either over a transition period or indefinitely, and sometimes a branch takes a completely different meaning and becomes a fork.


Tags are moments in time that have particular meaning. As a general rule, don’t touch existing tags. Create new ones.

Repository Status and Release Lifecycle

Some projects have different repository status during the release life cycle. A temporary freeze on new features might apply to allow for the polishing of code toward release, in which case do commit translations and bug fixes but don’t commit new features. If you are unsure of the current lifecycle status of the project you contribute to, just ask. On Hugin we are currently in a freeze, working toward 0.8.0. But we tend to be tolerant and won’t refuse other contributions. We might adopt a more formal process in the future, branching out the feature-frozen code for release, but at the moment we lack the resources and don’t feel the need to maintain separate release and development branches.

The Dos and Dont’s



  • Check out the latest revision before start working, and check your changes back in as soon as possible.
  • Don’t use svn locks. Commits in subversion are transactional and locks are almost always unnecessary.
  • Commit often, one change at a time. Easier to read and debug.
  • Don’t include multiple changes in a single large commit.
  • Look at the diff before committing, make sure you can answer the question: what are you changing? You’ll need the answer for the next point.
  • Don’t tidy up the code while making changes. If tidying up is necessary, do it in a separate commit (see Bruno’s comment).
  • Document changes in the commit message, use the -m switch in the command line or the entry field provided by TortoiseSVN or other SVN-GUIs.
  • Don’t leave the message field empty. If the change requires more than a few lines of explanations, consider breaking it down into multiple commits.
  • Reference tracker tickets in the comment when applicable.
  • Don’t fill the message field with prose. If the nature of the change requires a lot of explanations (e.g. new API), provide documentation in separate file(s) and refer to it.
  • Use svn:externals or scripts to fetch and unpack external dependencies.
  • Don’t commit external dependencies (e.g. “SDK”) to the repository.
  • Discuss conflicting choices and seek consensus on the hugin-ptx mailing list. Consider adding alternative functionality rather than replacing existing one.
  • Don’t override other committers code just because you disagree with their solution.
  • Consider branching when the development work you initiate will take more than a day or two to complete.
  • Don’t regret the code lost because you did not commit it right away.
  • Test your changes locally before committing. If you must leave unfinished or untested work, wrap it in an always false condition so that it won’t affect other users.
  • Don’t commit changes without having them tested locally.
  • Keep in mind that the code is for multiple platforms. Ask users of other platforms to check if your changes affect their platforms adversely.
  • Don’t ignore other platforms and silently break the code for them.
  • Ask on the hugin-ptx mailing list for advice. If you are unsure whether you should commit, provide a patch that other users can apply and test.
  • Don’t be shy. Your contribution is always welcome. If it breaks something, we’ll work together to fix it.
  • Give credit where credit is due. If adding to SVN code from a third party patch, mention the third party as originator of the code. If making a change on user feedback, mention the user.
  • Don’t commit third party changes without testing and understanding what they do first.
  • Keep files that do not require version control in appropriate resources such as Flickr, Vimeo, or webspace that is donated to the community.
  • Don’t clutter the repository with files that do not require version control and use a lot of space/bandwidth, such as podcasts and presentations.

Last but not least: do use your common sense and don’t be shy to question the current way of doing things. You might have a point, and neither you nor we will know it unless you bring it to our attention. If you feel something important is missing in the above list, you are invited to comment.

Hugin-0.8.0_beta2 installer

hugin-logoAllard Katan has released an installer of the latest Hugin beta.