Hugin-2009.2.0-beta2 released - process detail
Yuval Levy
In a nutshell: the conditions to declare a release final are:
* the code builds on the major supported platforms (Ubuntu, Fedora, OSX,
Windows)
* there is no (known) regression, unless intentional. This means: what
worked with the previous release should work with the current one.
The goal of the new release process is to decouple the development
process from the other processes, avoiding artificial slow downs (trunk
freezes).
The processes (development, translation, distribution, support) in detail:
DEVELOPMENT:
* if you have a development branch, nothing changes. you can keep
working on it
* if you are working on trunk there is an *improvement*: no trunk freeze
* you're encouraged to continue with your usual pace of bug fixing and
development.
* to do things perfectly: commit all your changes to trunk; and those
that are bugfixes also to the release codeline.
* if you forget about it and commit only to one codeline, do not worry.
I take responsibility for the 2009.2 codeline and will port fixes from
trunk to 2009.2 or the other way around as the need arises.
* try not to add new features to the release codeline
TRANSLATION:
* same as development
* please do not run extract-messages.sh until after release
DISTRIBUTION:
* *unchanged*: the Hugin project releases source code that is tested to
build on the main supported platforms: Fedora, Ubuntu, Windows, OSX. It
works on the developers machines. YMMV.
* Building and distributing binaries is left to the users communities.
Once there are binaries of appropriate quality level for platforms that
do not have a package manager (Windows and OSX) we add them as a
courtesy to the SF archive - as usual "WITHOUT ANY WARRANTY; without
even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE." See the GNU General Public License for more details.
more details on <http://wiki.panotools.org/Development_of_Open_Source_tools>
Yuv
Tduell
On Sep 3, 12:24 pm, Yuval Levy <goo...@levy.ch> wrote:
> Hi all,
>
> In a nutshell: the conditions to declare a release final are:
> * the code builds on the major supported platforms (Ubuntu, Fedora, OSX,
> Windows)
I can report that I have successfully built a Fedora 11 X86_64
package, which appears to work without error.
It has successfuly reproduced results obtained from Hugin 0.8 on a
couple of projects, so whilst not exhaustive testing, it does look OK.
Stitching with the gpu is without error, using an Nvidia 9600GT and
the proprietary Nvidia driver.
Hope this helps.
Cheers,
Terry
Yuval Levy
Tduell wrote:
> Stitching with the gpu is without error, using an Nvidia 9600GT and
> the proprietary Nvidia driver.
lucky you!
> Hope this helps.
a lot! these are *excellent* news.
Yuv
Tduell
On Sep 4, 12:38 pm, Yuval Levy <goo...@levy.ch> wrote:
> Thanks, Terry,
>
> Tduell wrote:
> > Stitching with the gpu is without error, using an Nvidia 9600GT and
> > the proprietary Nvidia driver.
>
> lucky you!
> > Hope this helps.
>
> a lot! these are *excellent* news.
Upon reflection and a tad more testing there are a couple of things
that I should mention. I think these issues may have come up before.
The fast preview window has a bit of mind of its own on some projects,
the display being horribly corrupted with lots of triangles spearing
off into the middle distance. In almost all cases the normal preview
window is able to display correctly. This behaviour of the fast
preview window has been somewhat erratic and it has been hard to see
any pattern to the behaviour.
There have been a number of projects of late (prior to this beta2
version but I can't be sure how far back it goes) where the
'Assistant' reports very bad fit, with quite large values reported for
the mean and max, but a look at the control points doesn't show any
values which come even close. For example, one project reports mean
error 7.0 and max 886, but the largest I can see in the control points
tab is 22.25. Maybe I am misunderstanding the report.
Sorry if this muddies the waters. I should have been reporting these
things earlier, but I am usually a tad reluctant to do so until I'm
pretty sure that it isn't due to some clumsy usage on my part.
Cheers,
Terry
If
T. Modes
On 4 Sep., 02:44, Tduell <tdu...@iinet.net.au> wrote:
> Stitching with the gpu is without error, using an Nvidia 9600GT and
> the proprietary Nvidia driver.
>
The output of nona -g is always padded to a multiply of 8 (at least
with my ATI graphic card).
(http://sourceforge.net/tracker/?
func=detail&aid=2831574&group_id=77506&atid=550441)
As a result nona is crashing for instance when output non-cropped tiff
but with a crop area.
(The crash occurs in the saving procedure because of the slightly
different images size the remapped images have and the image size nona
wants to output.)
Did you also observed this bug?
Thomas
Tduell
On Sep 4, 3:40 pm, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
> Hello Terry,
>
> On 4 Sep., 02:44, Tduell <tdu...@iinet.net.au> wrote:
>
> > Stitching with the gpu is without error, using an Nvidia 9600GT and
> > the proprietary Nvidia driver.
>
> what's about the image size of the output?
I'll have to run some more checks and see.
> As a result nona is crashing for instance when output non-cropped tiff
> but with a crop area.
> (The crash occurs in the saving procedure because of the slightly
> different images size the remapped images have and the image size nona
> wants to output.)
>
> Did you also observed this bug?
I did observe on a previous svn snapshot (can't remember number but it
was when gpu functionality was included) that selecting 'create
cropped images by default' had no effect, so I have had that option
disabled.
I will be a bit more rigorous in my testing of the gpu options with
the beta2 version and report back.
I wonder if the gpu code is more acceptable to the Nvidia than the
Ati...just thinking out loud.
Cheers,
Terry
>
> Thomas
Tduell
On Sep 4, 4:34 pm, Tduell <tdu...@iinet.net.au> wrote:
> I will be a bit more rigorous in my testing of the gpu options with
> the beta2 version and report back.
using the beta2 version in Fedora 11 x86_64.
I tried all the options that looked relevant, as follows.
gpu on, crop as default in prefs, no crop selected in fast preview:
works OK, output image 4928x4437
gpu on, crop as default in prefs, crop selected in fast preview: works
OK, output image 3970x2964
gpu on, no crop set in defaults, no crop selected in fast preview:
works OK, output image 4928x4437
gpu off, no crop selected in fast preview, (this is the basic
operation as per 0.8), works OK, output image 4928x4437
Does that info help?
Cheers,
Terry
Yuval Levy
Tduell wrote:
> gpu on, crop as default in prefs, no crop selected in fast preview:
> works OK, output image 4928x4437
> gpu on, crop as default in prefs, crop selected in fast preview: works
> OK, output image 3970x2964
> gpu on, no crop set in defaults, no crop selected in fast preview:
> works OK, output image 4928x4437
> gpu off, no crop selected in fast preview, (this is the basic
> operation as per 0.8), works OK, output image 4928x4437
>
> Does that info help?
partially. 4928 is a multiple of 8 (and if I am not mistaken, the
padding is to lines of 8 pixels, to improve the speed of transfer
between system memory and GPU memory).
I wish I could try, but my weak chipset embedded nVidia GPU is stuck
with the Framebuffer error (incomplete attachment), into which I try to
research, to no avail so far.
Yuv
Tduell
On Sep 4, 10:56 pm, Yuval Levy <goo...@levy.ch> wrote:
> > Does that info help?
>
> partially. 4928 is a multiple of 8 (and if I am not mistaken, the
> padding is to lines of 8 pixels, to improve the speed of transfer
> between system memory and GPU memory).
>
> I wish I could try, but my weak chipset embedded nVidia GPU is stuck
> with the Framebuffer error (incomplete attachment), into which I try to
> research, to no avail so far.
Having just re-read Thomas's story I realize I have probably been
testing the wrong conditions.
My results reported (posting Sep 4 5:01 pm) were for jpg output from
the stitcher, so I have just tried a couple more tests for the same
project, but with tiff output.
1: Prefs gpu on, no crop; selected a crop area in fast preview window.
OK, output 3978x2981
2: Pres gpu on, saved crop area; fast preview window opens with a
letter box opening crop area in the middle of the display, size of
automatically set cropped area unknown. I dragged the crop area out to
the full display (as per no crop). Saved OK, output 4920x4437.
Having pondered this a tad I'm not sure that I fully understand the
conditions of the problem that Thomas reported, and hence my tests may
not be helping.
As my version appears to be robust, i.e. no crashes, please elaborate
a tad more on what tests will help, if more needed.
Cheers,
Terry
T. Modes
I uploaded a test case to the bug tracker
http://sourceforge.net/tracker/index.php?func=detail&aid=2831574&group_id=77506&atid=550441
Maybe you could test it on your machine.
Details to the test case are in comments to the ticket.
@Yuv
> I'll issue a release candidate in the coming days
I would wait a couple of day. Maybe someone could fix some of the big
problems in nona-gpu (e. g. your incomplete framebuffer problem, or my
padding problem). I think we should not release a version, where the
first point of the change list has an comment of "reported not to work
in most cases" (see your release notes for beta). IMHO it should work
in some more cases before we release.
Also the translation for the release of 2009.2 are behind the stand of
0.8
We should give the translators some more time, to get a similar
coverage of translation as 0.8 (Currently there are some untranslated
strings in the main interface, which looks not so professional for an
release.)
Thomas
Tduell
> I uploaded a test case to the bug trackerhttp://sourceforge.net/tracker/index.php?func=detail&aid=2831574&grou...
> Details to the test case are in comments to the ticket.
gpu-cc: stitch cropped to 1057x7
gpu-cnc: stitch uncropped 1231x1098
gpu-ncc: cropped to 1057x7
gpu-ncnc: stitch uncropped 1231x1098
I didn't intervene in any way, simply ran the process and saved the
pano.
Hope I have interpreted your requirements correctly, and that these
results are helpful.
If no to any of above, I will try again :-)
Cheers,
Terry
Yuval Levy
T. Modes wrote:
> I would wait a couple of day. Maybe someone could fix some of the big
> problems in nona-gpu (e. g. your incomplete framebuffer problem, or my
> padding problem).
I am not sure if the incomplete framebuffer is really a bug in the
nona-gpu code; or if it is the result of some combination of hardware,
driver, and software. The only way to find out is to release and get a
wider set of reports.
> I think we should not release a version, where the
> first point of the change list has an comment of "reported not to work
> in most cases" (see your release notes for beta). IMHO it should work
> in some more cases before we release.
I disagree with you. I have stated at the beginning of the release cycle
what the conditions are for release:
- the package builds on the major supported platforms (Ubuntu, Fedora,
OSX, Windows)
- there is no (unintentional) regression / breakage of functionality.
2009.2.0 ships with GPU-stitching disabled by default. The functionality
of nona when GPU-stitching is disable is exactly equal to 0.8.0. No
regression, no show stopper.
> Also the translation for the release of 2009.2 are behind the stand of
> 0.8
How can the translations be behind? all strings that were translated in
0.8 are still translated in 2009.2.0, so there can only be improvements?
again: no regression, no show stopper.
> We should give the translators some more time, to get a similar
> coverage of translation as 0.8 (Currently there are some untranslated
> strings in the main interface, which looks not so professional for an
> release.)
translators can work any time. If the translations are so important,
they will come, and we have an option of issuing a patch release (e.g.
2009.2.1).
the whole point of this new process is *not* to wait, nor to put
pressure on volunteers to deliver. What comes comes, what does not come
will come for the next release.
waiting is the problem, not "looking unprofessional".
nona-gpu has been waiting for too long before trunk was ready for a merge.
now lens calibration has just been merged into trunk and is also waiting
for a release.
after lens calibration there are other major changes that need to be
merged and released - one by one: deghosting; new layout; vigra1.6.
I don't want get stuck with the problem that we had for 0.8.0: too much
stuff was added to trunk before releasing and it has taken so long to
fix it for release.
trunk is always open for small incremental changes, and if we release
frequently, those small incremental changes, including the fixes for 8
pixel padding; framebuffer; translations, etc.) will just be released as
they go.
Yuv
Yuv
Bruno Postle
>
>> Also the translation for the release of 2009.2 are behind the stand of
>> 0.8
>
>How can the translations be behind? all strings that were translated in
>0.8 are still translated in 2009.2.0, so there can only be improvements?
Some of the very prominent strings in the GUI have changed so it
would be good to get some more translations updated before this next
release.
We need to make translators aware that there will be a release
*soon*, I'm not sure we have done this.
Translators start here, I think there are only 25 or so new
strings, so it isn't a big job this time:
http://wiki.panotools.org/Hugin_translation_guide
--
Bruno
RueiKe
I found most of the fuzzy translations also need work. I plan to
finish the Traditional Chinese translation tomorrow.
Regards,
Rick
Yuval Levy
> Some of the very prominent strings in the GUI have changed so it
> would be good to get some more translations updated before this next
> release.
>
> We need to make translators aware that there will be a release
> *soon*, I'm not sure we have done this.
yes, so far I did not announce beta1 and only announced beta2 here and
not on the SourceForge system - I wanted to be sure of my tarballs.
I'll issue beta3 (and not RC1) next. and I'll issue the call for
translations in the release notes. Then I'll issue RC1 one week later.
Then we can wait. Even indefinitely if that's the collective decision.
The new development model is about branching. Like in nature, a branch
does not always florish - whether it is a development or a release
branch. It is possible to abandon a release branch at beta or RC stage.
People vote with their feets, with their actions, with their wallets. In
this case: if there is enough interest in a release volunteers will work
on bringing the branch to the next level. If not the branch will linger
and volunteers will continue to work on other branches (e.g. trunk).
We are in a transition and it is the first time we use this new model.
We need to observe and learn from our own collective behavior. In the
past we were way to slow releasing.
I have no control on volunteer resources. The only thing I can define is
the level of quality at which I am ready to call it a release:
1. the code builds on the main supported platforms (Ubuntu, Fedora, OSX,
Windows)
2. there is no functional regression unless intended
Other may prefer higher (or lower) quality standards, including
translations and testing. Everybody has their personal quality
standards, and they are all right. I respect them. We have to compromize
on and agree on the terms for Hugin release, not on the personal quality
standards.
There is a trade off between the level of quality and the cost and time
associated with achieving it. Perfection can't be achieved, not even
with money (although if translations are important, a bounty should not
be that expensive. Depending on the language, commercial translation is
less than 1$/word on the commercial market).
I know of much less complex software packages than Hugin where testing
before a *patch* release (e.g. security fix) is a six digits US$ figure
(and still has very embarassing glitches). We can't afford this -
neither in money nor in equivalent human time.
To me volunteer contributors are like a fluid: they decide what they
want to work on and when. I have very little leverage on them. The fluid
flows magnetically attracted to where there is interest. If there is
interest in a more polished release, the fluids will be attracted toward
that branch. I am happy to observe that the fluids are attracted by
2009.2. In the meantime trunk has evolved and I start to be more
attracted by it. I want to push lens calibration out to the general
public. Not before bringing 2009.2 to a release. And after lens
calibration there are other cool functionalities in line for integration
and release.
My vision is that by early 2010 we have absorbed all queued development
branches / features and we can make a plan where we go from there, based
on a robust, tried and tested parallel development process, with
specified conditions for release.
Maybe
1. the code builds on the main supported platforms (Ubuntu, Fedora, OSX,
Windows)
2. there is no functional regression unless intended
is too low a standard.
It has been discussed on the GSoC 2009 mentors list as how to integrate
the GSoC 2009 projects into trunk without running into the slow down of
GSoC 2008 / 0.8.0 (where we took too big a bite at once and were delayed
for months of fixing).
We can re-open the discussion about the conditions for release here if
there is enough interest. I would prefer this to happen after we
released the GSoC 2009 code (three releases are planned) and learn from
the experience.
Yuv
Yuv