0.8.0 release?
Yuval Levy
it's been a while since three GSoC 2007 projects have been merged to
trunk. It works well for me. No regressions, and the new features (fast
preview, celeste, ptbatcher, new projections) work well for me and are a
significant improvement over 0.7.0
IMO it is time for a 0.8.0 release, so that we can move on to a further
round of improvement, features additions, bug fixing.
What do you think? Is there something that is still a show stopper for a
0.8.0 release?
Yuv
Bruno Postle
>
>IMO it is time for a 0.8.0 release, so that we can move on to a further
>round of improvement, features additions, bug fixing.
>
>What do you think? Is there something that is still a show stopper for a
>0.8.0 release?
A few things:
We need to switch at least the 'preview' toolbar button to launch
the 'fast preview', otherwise nobody will ever find it.
We have lots of new strings, the hugin.pot file needs updating and
we need to give translators a chance to submit updates (this
shouldn't stop us releasing 'betas').
The new projections require a new libpano13 release.
The manual needs to be updated.
There are lots of outstanding bugs, but Bug #2292979 is the one that
causes most grief, it should be easily fixable since it is
reproducible:
https://sourceforge.net/tracker/?func=detail&atid=550441&aid=2292979&group_id=77506
We have a 'nona-gpu' branch which is ready for merging with the
trunk, it would be silly not to introduce it before 0.8.0 since the
functionality is disabled by default anyway.
--
Bruno
Bruno Postle
>
>We have lots of new strings, the hugin.pot file needs updating and
Done. There are about 35 new strings, the .po files in SVN have now
been updated.
>we need to give translators a chance to submit updates (this
>shouldn't stop us releasing 'betas').
--
Bruno
J. Schneider
> On Sat 24-Jan-2009 at 21:32 +0000, Bruno Postle wrote:
>> We have lots of new strings, the hugin.pot file needs updating and
>
> Done. There are about 35 new strings, the .po files in SVN have now
> been updated.
I'm taking care of the German translation, if nobody hasn't already. But
I keep forgetting where to e-mail/upload the result.
A few questions (because I don't have a Windows binary to see where the
strings come from):
There is a string "Identify". There are different grammatical forms to
translate this?
Where is "Enter application" used? Does it mean "go into" the
application or should the application (path) be entered in a text box?
What is "adddir"? Something concerning adding of a directory, but what
does it mean exactly?
regards
Joachim
Bruno Postle
>
>I'm taking care of the German translation, if nobody hasn't already. But
>I keep forgetting where to e-mail/upload the result.
Best would be to attach it as a patch in the sourceforge tracker.
>There is a string "Identify". There are different grammatical forms to
>translate this?
In the fast preview there is an 'Identify' mode, it tells you which
photo(s) are directly under the mouse cursor.
>Where is "Enter application" used? Does it mean "go into" the
>application or should the application (path) be entered in a text box?
The Batch stitcher has an option to run an 'application', this is
the text box where you type the executable name.
>What is "adddir"? Something concerning adding of a directory, but what
>does it mean exactly?
Again in the batch stitcher, this (apparently, I haven't played with
this) asks for a directory and stitches all .pto projects it finds
there.
--
Bruno
Yuval Levy
> We have a 'nona-gpu' branch which is ready for merging with the
> trunk, it would be silly not to introduce it before 0.8.0 since the
> functionality is disabled by default anyway.
I thought it was work in progress. I've built it in Linux. Easy. Then I
set remapUsingGPU to true, rebuilt it and tested. I'm on an old Intel
based notebook. It was slow but it worked. I'll try it on my workstation
where I have a slightly better GPU next week.
In Windows I had to build freeglut, add a modified a FindGLUT.cmake file
that I found in the cmake.org repository to the cmake modules, until
cmake produced an MSVC project. Then there was an error (sys/time.h does
not exist in MSVC). I solved it with an #ifndef win32, tried to build
again and now I get a flurry of errors... will post them later.
Anyway, seems cool. Does it support also the new projections?
Yuv
Rich
> On Sat 24-Jan-2009 at 14:28 -0500, Yuval Levy wrote:
>> IMO it is time for a 0.8.0 release, so that we can move on to a further
>> round of improvement, features additions, bug fixing.
>>
>> What do you think? Is there something that is still a show stopper for a
>> 0.8.0 release?
>
> A few things:
>
> We need to switch at least the 'preview' toolbar button to launch
> the 'fast preview', otherwise nobody will ever find it.
what about hugin setting EV to some ridiculously large value for opened
photos ?
for me, opening a few images exposure value is set to 13.something -
took me some time to find out why my resulting pano is all-white. i'd
expect a novice user to be quite annoyed about that...
...
--
Rich
Simon Oosthoek
I'll see what I can do for the dutch translation, my time is more
limited than it used to be, but I should be able to get something going...
Cheers
Simon
Harry van der Wolf
Ippei applied a hack but that hack works for Leopard and breaks Tiger.
It is a confirmed bug for wxwidgets but not yet solved. I now have a hack which checks for the osversion and executes neccessary code accordingly. Due to whatever reason I had a corrupted development system for a couple of days. I can only start now to apply the hack. I suppose we know within a week whether it works or not but at least before that time I would not like to have a 0.8 release.
I assume that the translators might need more time, but I wanted to let you know.
Harry
Bruno Postle
> I suppose we know within a week whether it works or not but at
> least before that time I would not like to have a 0.8 release.
Don't worry, it took 0.7.0 a couple of months to get from this stage
to a final release, though it would be nice to do this one a bit
quicker.
--
Bruno
Yuval Levy
If it takes a few weeks after release to have binaries for the
proprietary platforms (read: Mac / Windows) it is OK too.
Ideally I would like to have a release by early March so that we can
show off in our application for GSoC 2009 that most of the GSoC 2008
projects are useful and in production.
And ideally I would like to have a quarterly release cycle.
The sore point for me is that all of these features stay for too long in
the limbo of the SVN repository without a release, leaving it for others
(read commercial software) to breast themselves with having introduced
those features first.
We shall release more frequently, more often, and for Linux and in
English first. Translations and ports to other platforms can follow from
the release branch shortly thereafter if they are not ready by the
time the code is ready for release on the main Linux distros in the most
widely supported languages.
Yuv
Lukáš Jirkovský
exact time).
But it could be better to release more often but not stable versions
(like 0.7 and 0.8 were). More betas could be of some use.
Actually there are packages of svn versions, so why not cal them beta?
It would attract more attention, especially from "normal" users and
from distributions in case of Linux.
Bruno Postle
>
>But it could be better to release more often but not stable versions
>(like 0.7 and 0.8 were). More betas could be of some use.
>Actually there are packages of svn versions, so why not cal them beta?
Yes, we should release a 0.8.0 beta1 soon.
--
Bruno
Yuval Levy
> I don't like stable release cycle (I mean releasing new version after
> exact time).
I would not like to see the clock becoming the main driver of the
release cycle either.
But I would like to see us release more often, and that's where a
deadline comes handy because else the release gets postponed indefinitely.
What I would like to see is more frequent release,s i.e. we should
*target* one every three months.
We had now enough material for a release since the end of GSoC2008. If
we don't set ourself some deadline we'll end up in the same pattern as
the one that lead to the lengthy and frustrating 0.7 release cycle.
> But it could be better to release more often but not stable versions
> (like 0.7 and 0.8 were). More betas could be of some use.
> Actually there are packages of svn versions, so why not cal them beta?
> It would attract more attention, especially from "normal" users and
> from distributions in case of Linux.
Anybody can fetch SVN, so there is no need to "release" SVN.
There are no particular requirements to SVN/trunk, while a release must
fullfill some more stringent requirements, such as
- it builds
- even more stringent: it build on most supported platforms
- old and tested functionality is not broken (can't guarantee that for
trunk/SVN all the time)
- the strings are up to date
there is an increasingly stringent sets of requirement for software to
be considered alpha, beta, release candidate, release.
Unless you want to give up on quality during releases, but then each and
every single SVN change can be made into a release.
There is a trade-off between speed and quality. Trunk should focus on
speed. Make the change once it has passed an initial simple test and
test broadly later. Releases should focus on quality. Branch out for
release, then polish up in the cycle from alpha to beta to release
candidate, each one fulfilling more stringent quality criteria than the
previous one.
what you describe above are "snapshots". SVN-snapshots are a good idea
but they don't replace releases. AFAIK no Linux distribution includes
snapshots on a regular basis.
Yuv
Releases serve a different public.
>
> >
Rich
> Lukáš Jirkovský wrote:
>> I don't like stable release cycle (I mean releasing new version after
>> exact time).
>
> I understand this, and I know where you come from.
>
> I would not like to see the clock becoming the main driver of the
> release cycle either.
>
> But I would like to see us release more often, and that's where a
> deadline comes handy because else the release gets postponed indefinitely.
>
> What I would like to see is more frequent release,s i.e. we should
> *target* one every three months.
this usually depends on developer activity. maybe a longer period works
better for some projects, maybe shorter for others.
now, what seems to make sense - target for a release every n months, no
new features in trunk for last month or so (of course, still can be
developed in branches).
once it's stable, decide how many new features are there. many ? new
major release. few or bugfixes only ? new minor release.
...
> There is a trade-off between speed and quality. Trunk should focus on
> speed. Make the change once it has passed an initial simple test and
> test broadly later. Releases should focus on quality. Branch out for
> release, then polish up in the cycle from alpha to beta to release
> candidate, each one fulfilling more stringent quality criteria than the
> previous one.
ok, that's probably even better than freezing the trunk ;)
> what you describe above are "snapshots". SVN-snapshots are a good idea
> but they don't replace releases. AFAIK no Linux distribution includes
> snapshots on a regular basis.
>
> Yuv
>
>
> Releases serve a different public.
definitely. they can be considered the only thing most users will use.
faster release cycle pushes new features to users faster, generates
interest etc.
while i personally started using trunk soon after discovering hugin, i
wouldn't recommend that to most persons i know - but then they miss the
neat features...
--
Rich
prokoudine
> but they don't replace releases. AFAIK no Linux distribution includes
> snapshots on a regular basis.
FontForge, FFmpeg, PortAudio... Even hugin is shipped in Ubuntu as
0.7.0 + changes from SVN.
But I do agree that releases is what hugin should target :)
Alexandre
J. Schneider
> On Sun 25-Jan-2009 at 00:37 +0100, J. Schneider wrote:
>> I'm taking care of the German translation, if nobody hasn't already. But
>> I keep forgetting where to e-mail/upload the result.
>
> Best would be to attach it as a patch in the sourceforge tracker.
Thanks for your explanations.
I have some more questions (unclear meaning/usage), but meanwhile I
upload the intermediate result.
What means/Where is used:
Click to create or edit control points here.
(Does here refer to click or to create/edit? [Hier klicken, um
.../ Klicken um hier ... ?]
Specify project source file(s)
(What is meant by source file? I know project files.)
Photometrics
hi
hello
Match images to their numbers
(Is this an imperative or a statement?)
BTW, Poedit complains
"00:36:26: C:\...\de 2009-01-25.po:148: `msgid' and `msgstr' entries do
not both end with '\n'
00:36:26: C:\...\de 2009-01-25.po:160: `msgid' and `msgstr' entries do
not both end with '\n'
00:36:26: msgfmt: found 2 fatal errors"
Does anybody know what's wrong?
regards
Joachim
Bruno Postle
>
>I have some more questions (unclear meaning/usage), but meanwhile I
>upload the intermediate result.
>
>What means/Where is used:
>
>Click to create or edit control points here.
> (Does here refer to click or to create/edit? [Hier klicken, um
> .../ Klicken um hier ... ?]
This is the 'identify' mode in the new fast preview. Clicking on
the overlap between two photos will open those two photos in the
Control Points tab.
>Specify project source file(s)
> (What is meant by source file? I know project files.)
This is the file dialog in the Batch Stitcher for adding .pto
projects to the stitching queue.
>Photometrics
This is another mode in the fast preview, the preview won't do the
'photometric' stuff (vignetting mainly) unless you select it.
>hi
This is a tooltip on the celeste 'SVM threshold', ignore it it
shouldn't be there.
>hello
This is a tooltip on the celeste 'Gabor filter size', ignore it
again.
>Match images to their numbers
> (Is this an imperative or a statement?)
This is the tooltip text on the 'identify' tool, what it means it
that it will tell you the id numbers of images when you point at
them.
>BTW, Poedit complains
>"00:36:26: C:\...\de 2009-01-25.po:148: `msgid' and `msgstr' entries do
>not both end with '\n'
'\n' is a 'new-line'. gettext expects that the English String and
the German string should have the same number of new-lines.
--
Bruno
Bruno Postle
>>
>> What do you think? Is there something that is still a show stopper for
>> a 0.8.0 release?
> We need to switch at least the 'preview' toolbar button to launch the
> 'fast preview', otherwise nobody will ever find it.
Done.
> We have lots of new strings, the hugin.pot file needs updating and we
> need to give translators a chance to submit updates (this shouldn't stop
> us releasing 'betas').
Done, we have a Dutch translation and a German translation (not yet
applied).
> The new projections require a new libpano13 release.
I've put a libpano13-2.9.14_beta1 tarball on sourceforge, I'll do an
announcement in a moment:
https://sourceforge.net/project/showfiles.php?group_id=96188&package_id=237430
> The manual needs to be updated.
Done.
> There are lots of outstanding bugs, but Bug #2292979 is the one that
> causes most grief, it should be easily fixable since it is reproducible:
> https://sourceforge.net/tracker/?func=detail&atid=550441&aid=2292979&group_id=77506
Seems to be fixed.
> We have a 'nona-gpu' branch which is ready for merging with the trunk, it
> would be silly not to introduce it before 0.8.0 since the functionality
> is disabled by default anyway.
This isn't merged, I can't do any testing as I don't have access to
suitable hardware.
On Sun 25-Jan-2009 at 11:07 +0200, Rich wrote:
>what about hugin setting EV to some ridiculously large value for opened
>photos ?
>for me, opening a few images exposure value is set to 13.something -
>took me some time to find out why my resulting pano is all-white. i'd
>expect a novice user to be quite annoyed about that...
I don't see this, do we have a reproducible test case for this bug?
--
Bruno
Rich
...
> On Sun 25-Jan-2009 at 11:07 +0200, Rich wrote:
>> what about hugin setting EV to some ridiculously large value for opened
>> photos ?
>> for me, opening a few images exposure value is set to 13.something -
>> took me some time to find out why my resulting pano is all-white. i'd
>> expect a novice user to be quite annoyed about that...
>
> I don't see this, do we have a reproducible test case for this bug?
http://tndruka.lv/stuff/exposure_test.tar.bz2
test.pto created with autopano-sift-c.
loading it sets EV for the first image to 13.3 (this is a bit weird,
when i was stiching this pano for the first time, it got set to 13.3 for
all images).
now, loading exif for the rest of the images (one in this reduced
testcase) does indeed set EV to 13.3, which gives you nice, white area
where outcome is supposed to be. i even enblended it once, hoping it's
hugin preview being wrong :)
--
Rich