vigra 1.6.0 patch

16 views
Skip to first unread message

Lukáš Jirkovský

unread,
Jan 24, 2009, 7:49:56 AM1/24/09
to hugi...@googlegroups.com
Hello,
I'm back again with another patch. This time it's patch which makes
hugin using new vigra 1.6.0.

While I've been working on the second most annoying bug [1], I've
found that there is new version of vigra. Unfortunately it doesn't fix
my problem, but it has impressive list of changes [2].
I've ported all hugin-specific changes like EXR support to the new
vigra code and it seems working. The patch is quite big (uncompressed
it's 1.5MB).

I've already tried to make small panorama with patched hugin and I
don't see any change between hugin from trunk (vigra 1.5.0) and hugin
with vigra 1.6.0.

But I think it will need more testing before even thinking about
moving it to the trunk, because of extensive usage of vigra in hugin
so any small regression could cause big problems.
I'm calling for anyone to test it.

Patch is attached.

[1] https://sourceforge.net/tracker2/index.php?func=detail&aid=2033756&group_id=77506&atid=550441
[2] http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/doc/vigra/CreditsChangelog.html

vigra_1.6.0.diff.gz

Yuval Levy

unread,
Jan 24, 2009, 2:24:14 PM1/24/09
to hugi...@googlegroups.com
Thanks, Lukáš!

Lukáš Jirkovský wrote:
> But I think it will need more testing before even thinking about
> moving it to the trunk, because of extensive usage of vigra in hugin
> so any small regression could cause big problems.
> I'm calling for anyone to test it.

For those who want to test it in Ubuntu, this is what I did:

I followed the instructions at
<http://wiki.panotools.org/Hugin_Compiling_Ubuntu>

after checking Hugin from SVN and before building it:
- downloaded the patch to the same folder as hugin's source
- gunziped it with: gunzip vigra_1.6.0.diff.gz
- patched it with: patch -p1 < vigra_1.6.0.diff
- continued building according to the wiki's instructions.

While this is not much work, still work it is that can be spared. I
think the right thing to do is to put it in a repository branch. The
question to the team is: which branch?

Should we branch out a new "vigra1.6" branch and keep trunk for the
stable releases? or should we branch out a 0.8 branch and use trunk for
the bleeding edge?

Practically, both solutions are equivalent. The only difference is that
trunk is a branch with a policy meaning as it is the natural branch on
which most work is focused.

The choice will give a policy signal.

I would be inclined to branch out 0.8 for those who do not want to take
risks and stick with the past, while including Lukáš's patch in trunk.
After all, trunk is meant to be the bleeding edge and a newer, better
vigra is just that.

If trunks proves to have regressions or other instabilities, we can tag
and release 0.8.0 from the 0.8 branch. If the tests are positive, we can
close the 0.8 branch.

In both cases there will be a little bit of maintenance work at keeping
changes such as bug fixes in sync. It is more efficient to do it once
in SVN and make life easy for everybody else who will just "svn up";
than having everybody maitaining their own patched local install.

so the question is: trunk, or new branch?

Yuv

Dale Beams

unread,
Jan 24, 2009, 2:35:31 PM1/24/09
to Hugin Group

trunk, i'd like to test it this afternoon

> Date: Sat, 24 Jan 2009 14:24:14 -0500
> From: goo...@levy.ch
> To: hugi...@googlegroups.com
> Subject: [hugin-ptx] Re: vigra 1.6.0 patch

Lukáš Jirkovský

unread,
Jan 25, 2009, 4:22:48 AM1/25/09
to hugi...@googlegroups.com
2009/1/24 Dale Beams <drb...@hotmail.com>:
I think both options are equivalent and depends only on which one you prefer.
Personally I prefer making 0.8 branch and putting this to trunk,
because I'm lazy to patch the sources.

Bruno Postle

unread,
Jan 25, 2009, 6:58:28 AM1/25/09
to Hugin ptx
On Sat 24-Jan-2009 at 14:24 -0500, Yuval Levy wrote:
>
>so the question is: trunk, or new branch?

The recent pattern (summer of code projects and nona-gpu) has been
to work on the new major features in a branch then merge with the
trunk once the work has been done.

--
Bruno

Lukáš Jirkovský

unread,
Jan 25, 2009, 7:14:29 AM1/25/09
to hugi...@googlegroups.com
2009/1/25 Bruno Postle <br...@postle.net>:
On the other hand GSoC and nona-gpu had to be "written from scratch".
This is already working (I hope) code with all needed changes.

Yuval Levy

unread,
Jan 25, 2009, 1:16:42 PM1/25/09
to hugi...@googlegroups.com


Indeed, and from my perspective it's not a break of the recent pattern.

At some point, the new major feature flows back into trunk, and this is
where Lukáš's patch stands IMO.

The process as I see it: Branch out. Make changes. Test that they work
for you and do not break anything big. Submit for quick review on a few
alternative platforms. If that review is positive, merge into trunk for
a broader and thorough review. Branch out again for release.

By submitting his patch, Lukáš asked for a review. I confirm on both
Ubuntu and Windows. Does not break anything. I vote to put it in trunk.

When you mentioned nona-gpu was ready for trunk, I ran it through the
same review as I did with Lukáš's patch. It built and worked on my Linux
notebook. I failed on Windows.

From my perspective, the vigra patch is closer to trunk than the
nona-gpu branch. But the problem with my Windows build may lay between
the chair and the keyboard ;-)

Yuv

Bruno Postle

unread,
Jan 25, 2009, 4:48:33 PM1/25/09
to Hugin ptx
On Sun 25-Jan-2009 at 13:16 -0500, Yuval Levy wrote:
>
>By submitting his patch, Lukáš asked for a review. I confirm on both
>Ubuntu and Windows. Does not break anything. I vote to put it in trunk.

Yes put it in the trunk, it isn't going to get extensive testing any
other way.

--
Bruno

Yuval Levy

unread,
Jan 26, 2009, 1:14:43 PM1/26/09
to hugi...@googlegroups.com


The recent discussion about merging patches or branches into trunk got
me thinking.

Branching out does not always have to be in the public repository. Every
checkout is potentially a branch.

I'd like to propose the following way of working, which is mostly a
formalization of what has been done so far.

Let's work with three types of branches:
- development branches
- release branches
- trunk


DEVELOPMENT BRANCHES

Development branches can be either public (in SVN) or local, if a
developer is more comfortable working on his own local copy.

The more the merrier. We should facilitate users and developers toying
with the code. They should know that what is under "branches" in the
repository can be highly interesting. We should provide them with
hacking howto's like

<http://ultrawide.wordpress.com/2008/11/16/hacking-hugin-part-1/>
<http://panospace.wordpress.com/2008/12/30/vedutismo>

to guide them into the depth of the code without fear. Once they will
discover the joys of hacking, they are more likely to become contributors.

In terms of management, I'd set a policy of keeping the branches
relevant by cleaning up / closing dev branches when the code flows back
to trunk or when the branch is abandoned / becomes obsolete.

The definition of abandoned branch for me would be if it has not seen
any write activity for six months. Before closing it I would ask
publicly (here) if somebody still intends to work on it, and as a
closure I would move it to a separate folder called abandoned-branches.

A branch becomes obsolete when the feature for which it was started has
either been integrated in trunk or the branch has been superseded by the
development and it is easier to implement that feature starting from
scratch. In those cases I would delete the branch, to avoid users
wasting time on them. This would apply to branches in both branches and
abandoned-branches folder (as it does not make sense to pick up an
abandoned and obsolete branch).

The goal is to keep the branches folder clean so that when an outsider
hits it instead of trunk he is not wasting time.


TRUNK

Trunk is the main experimental branch. the policies I suggest adopting
for trunk:
* it should build for most supported platforms most of the time, but the
occasional break is acceptable.
* the passage of code from a dev branch to trunk should be fast and
uncomplicated. I'd rather see a feature first in trunk and then bugfixed
than the other way around.

I propose a simple test to decide if code can move from a dev branch to
trunk:
* the owner of the dev branch declares his work finished - meaning that
it works for him
* at least one reviewer test it on a different platform and finds that
nothing major is broken
* the code is not harmful, i.e. it does not break existing functionality

Once in trunk, the code will be exposed to broader testing and review,
which will reveal bugs and minor functionality break.

Occasionally there will be snapshot releases from trunk. All other
releases will come from the release branches.


RELEASE BRANCHES

I'd be very strict about changes to release branches. No new features,
just bug fixes to the features that were present at the moment it was
branched out from trunk.

This is the place to add missing translations and support for not yet
supported platforms.

It is from these branches that the actual releases will be tagged,
tarballs will be created. This includes alphas, betas, release
candidates, final releases, bugfix releases.

Alpha: really just a tentative and not much better than a snapshot. Must
not yet support all languages and platforms and is highly experimental.
Old functionality should work as expected, but new functionality is in
alpha stage.

Beta: supports main languages and main platforms. Most functionality
should work, but there still are bugs.

Release Candidate: reproducible bugs scheduled to be fixed for the
release are gone. Difficult to reproduce and exotic bugs can still
exist. This is the time to polish things up. All translations should be
in at this time.

Final Release: supports all languages and all platforms.

Bugfix Release: in case important bugs are fixed in trunk later and are
backported. Not very likely, since we don't have much resources and it
is anyway better to move to the next release cycle.


PRACTICAL IMPLICATIONS

In that sense, I would suggest branching out now 0.8. This would freeze
the features of 0.8 (i.e. no nona-gpu and no vigra 1.6) and its strings.
There is enough food on the plate with PTbatcher, fast-preview, Celeste.
And for the next release the main dish will be nona-gpu + vigra 1.6.

This should enable focussing on the polishing, clean-up, bugfixes for a
release on the release-0.8 branch until we can tag a release-0.8.0.

At the same time, the bleeding edge can keep evolving in trunk with the
addition of vigra1.6 and soon nona-gpu.

there is only one complication to this, which is that from the moment we
branch out 0.8 bugfixes will need to be applied to both branches - 0.8
and trunk. The alternative would be to freeze trunk for the time it
takes to fix those bugs deemed critical for the 0.8 release and delay
broader testing of vigra1.6 and nona-gpu. Both ways are OK for me.


In practice, I'd clean up the branches folder by:

1. closing the following branches:
- before_gsoc2007/ (obsolete)
- dangelo (last change 5 years ago)
- gsoc2008_batch_processing/ (successfully integrated in trunk)
- gsoc2008_integration (superseded by trunk)
- gsoc2008_opengl_preview (successfully integrated in trunk)
- gsoc2008_sky_identification (successfully integrated in trunk)
- stable (obsolete)
- vigra140-branch (obsolete)

2. opening a release-0.8 branch when we are ready, from which eventually
0.8.0 will be tagged

3. keep on working on the work in progress development branches with the
goal of integrating them in trunk
- gsoc2008_feature_matching
- gsoc2008_masking
- nona-gpu

4. to be really anally retentive, I'd clean up branches into:
-branches/dev/
-branches/releases/
-branches/abandoned/

moving the three branches mentioned in 3. to branches/dev; and moving
release-0.7.0 branch in branches/releases/

5. in tags, I would add a tag to hugin-0.7.0 (tagging the exact SVN
revision used for that tarball), and in the future I would tag each
tarball before releasing it - tagging against a release branch, not
against trunk.

Yuv


Bruno Postle

unread,
Jan 26, 2009, 2:03:03 PM1/26/09
to Hugin ptx
On Mon 26-Jan-2009 at 13:14 -0500, Yuval Levy wrote:
>
>In that sense, I would suggest branching out now 0.8. This would freeze
>the features of 0.8 (i.e. no nona-gpu and no vigra 1.6) and its strings.
>There is enough food on the plate with PTbatcher, fast-preview, Celeste.
>And for the next release the main dish will be nona-gpu + vigra 1.6.

Except Andrew says nona-gpu is ready for merging and he isn't
generally reckless about this sort of thing. Though it obviously
breaks a couple of things (Windows build, old preview), these
shouldn't be too hard to fix, and sitting complete in a branch it
isn't getting any better.

>there is only one complication to this, which is that from the moment we
>branch out 0.8 bugfixes will need to be applied to both branches - 0.8
>and trunk. The alternative would be to freeze trunk for the time it
>takes to fix those bugs deemed critical for the 0.8 release and delay
>broader testing of vigra1.6 and nona-gpu. Both ways are OK for me.

I prefer the alternative: the trunk becomes the release and if
anyone desperately wants to work on new features in the next month
or so then this can happen in a branch.

--
Bruno

David J. Wallace

unread,
Jan 26, 2009, 2:56:58 PM1/26/09
to hugi...@googlegroups.com
On Saturday 24 Jan 2009, Lukáš Jirkovský wrote:
> Hello,
> I'm back again with another patch. This time it's patch which makes
> hugin using new vigra 1.6.0.
>

> I'm calling for anyone to test it.
>

Hi,

Works fine here. No issues after a couple of days use - as far as I can see.
Testing against svn trunk 3585 on linux x86.

Thanks for the patch.

Regards,

David

Yuval Levy

unread,
Jan 26, 2009, 3:47:10 PM1/26/09
to hugi...@googlegroups.com
Bruno Postle wrote:
> Except Andrew says nona-gpu is ready for merging and he isn't
> generally reckless about this sort of thing. Though it obviously
> breaks a couple of things (Windows build, old preview), these
> shouldn't be too hard to fix, and sitting complete in a branch it
> isn't getting any better.

have I missed it? I have not read anywhere that nona-gpu is ready for
merging?

I agree that if it is complete work for merging should start. The couple
of things it breaks are major, though. I would not want to see trunk
lingering for months in a broken status, and I see it as the
responsibility of whoever adds the feature from a dev branch to trunk to
make sure that some basic things don't break.


>> there is only one complication to this, which is that from the moment we
>> branch out 0.8 bugfixes will need to be applied to both branches - 0.8
>> and trunk. The alternative would be to freeze trunk for the time it
>> takes to fix those bugs deemed critical for the 0.8 release and delay
>> broader testing of vigra1.6 and nona-gpu. Both ways are OK for me.
>
> I prefer the alternative: the trunk becomes the release and if
> anyone desperately wants to work on new features in the next month
> or so then this can happen in a branch.

Then let it be with the alternative. Should we freeze trunk? There will
be pressure to unfreeze it again, i.e. to release faster.

Also: one of the reasons why I want to release withouth vigra1.6 and
without nona-gpu is because I have the impression that we have not
learned from the extended 0.7 release cycle: keep adding feature and
postpone releases is the best way to demotivate people. Actually we
should have released 0.8.0 as 0.7.0+fast preview; 0.8.1 as
0.8.0+PTbatcher; 0.8.2 as 0.8.1+Celeste and then continue with 0.8.3 as
0.8.2+vigra1.6 and 0.8.4 as 0.8.3+nona-gpu

This would have given us roughly a release every two months. We'd be
somehow at the same stage as we are now (the three GSoC project released
and the two other new features ready for trunk integration) with much
less pent up work and a better PR and take-up.

Yuv


Bruno Postle

unread,
Jan 26, 2009, 6:15:38 PM1/26/09
to Hugin ptx
On Mon 26-Jan-2009 at 15:47 -0500, Yuval Levy wrote:
>Bruno Postle wrote:
>> Except Andrew says nona-gpu is ready for merging and he isn't
>> generally reckless about this sort of thing.

>have I missed it? I have not read anywhere that nona-gpu is ready for
>merging?

Sorry, Andrew asked Pablo to do the merge and Cc'd me. I'm guessing
that Pablo is too busy to deal with this at the moment (and/or
struggling with the amount of mail).

>I agree that if it is complete work for merging should start. The couple
>of things it breaks are major, though. I would not want to see trunk
>lingering for months in a broken status, and I see it as the
>responsibility of whoever adds the feature from a dev branch to trunk to
>make sure that some basic things don't break.

>Also: one of the reasons why I want to release withouth vigra1.6 and

>without nona-gpu is because I have the impression that we have not
>learned from the extended 0.7 release cycle: keep adding feature and
>postpone releases is the best way to demotivate people.

You are right, we really need a release sooner. We don't need
vigra-1.6 now, but it is a long term goal to get the modifications
upstream and remove the vigra code from hugin altogether and staying
up-to-date is a step in that direction.

--
Bruno

Gerry Patterson

unread,
Jan 26, 2009, 9:58:49 PM1/26/09
to hugi...@googlegroups.com
Hello,

Yuval, have you taken a look at git?  Much of the workflow you suggest lends itself to a DVCS model (Distributed Version Control).   I use git along with 'tailor' to hack on Hugin.  When I was working on bugs, I would create a branch for each issue.  Then, as I worked on the feature, I could keep up to date with the trunk, merging as necessary.  Once the fix was ready, I would diff against the current truck, create a patch and commit it to a pristine SVN checkout.  When one starts considering branching and merging, dvcs systems like git and darcs really come into their own.

As for ideas on how to release software I have a few (doesn't everybody!)

  • keep development in trunk
  • develop large features in a separate branch and merge in when they work well enough for testing
  • We are not in a release cycle, bug fixes can be applied directly to trunk
  • When enough features are in place for a new release create a branch
    • release builds of this branch frequently (aids in getting testers)
    • no new features added
    • merge bug fixes back to trunk as required (changes in development may discount the need)
    • once all bugs are deemed fixed or postponed then string freeze
    • release
  • Development continues on in trunk/feature branches while the release branch is finalizing
I don't have much experience with branching in SVN, but I had a lot with CVS.  It was hell.  Perhaps SVN is better at merging than CVS...

- Gerry

Yuval Levy

unread,
Jan 30, 2009, 11:26:12 PM1/30/09
to hugi...@googlegroups.com
hi Gerry,

Gerry Patterson wrote:
> As for ideas on how to release software I have a few (doesn't everybody!)

I'm OK with most ideas expressed here, and I'm happy to see that the
wheels are moving again toward a release.

I'm still pleading for a clock-driven release cycle (not to be confused
with the development cycle which takes the time it needs to take):

<http://panospace.wordpress.com/2009/01/31/alarm-clock/>

have a good weekend

Yuv

Reply all
Reply to author
Forward
0 new messages