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.
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:
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.
> 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:
> 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.
>> 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:
>> 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
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.
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.
> 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
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.
Bruno Postle wrote: > 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
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 ;-)
Bruno Postle wrote: > 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.
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
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.
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 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.
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.
Yuval, have you taken a look at git <http://git-scm.com/>? Much of the
workflow you suggest lends itself to a DVCS model (Distributed Version
Control). I use git along with 'tailor<http://progetti.arstecnica.it/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...
On Mon, Jan 26, 2009 at 12:14 PM, Yuval Levy <goo...@levy.ch> wrote:
> Bruno Postle wrote:
> > 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.
> 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
> 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.
|
