[Pkg-phototools-devel] Hugin + Debian - touching base

[Yuval Levy]

Hi Sebastian,

I add Christoph Spiel to the conversation - he knows better about the 
current status of enblend. He is the magician pulling all the strings 
together and making it happen.

Sebastian Harl wrote:
> 3.2 is not available in any stable release so far and we're gonna have
> some time to fix any outstanding issues before the next release
> (Squeeze).

when is Debian Squeeze planned?


>>> Currently, the only outstanding issue that has been reported is the
>>> embedded version of libvigraimpex. It would be nice to be able to use
>>> the packaged, unmodified version at some point in the future (see
>>> [bts542258] for details).
>> yes, this would be nice. I am not enough of a coder to take care of  
>> this. I've added it to the Enblend bug tracker, [artifact 2853074]
> 
> I might look into that myself when I find some time to do so. I'm
> currently about to finish my university studies and I'll have more free
> time once that's done ;-)

congrats on your graduation!


>> have you tried the latest Hg version? you probably don't need  
>> [instructions] - it's much faster on multi-core CPUs; it is much more  
>> robust (projects of mine that segfault 3.2 complete like a charm on 4.0  
>> pre release); and worth being pushed into unstable already now.
> 
> I will have a look at that. Do you think it's in a state that might be
> released with Debian already? Else, I guess, I'll upload to experimental
> for now.

my personal judgment: 4.0 pre-release (a.k.a. Christoph's branch) is 
better than anything 3.x. I had plenty of cases where 3.x crashed and 
4.0 pre-release did the job. Chris can tell you more about the status of 
4.0.


>> When I look at [backports] we're still 0.7.0. I have no clue what the  
>> policies are at Debian for inclusion in stable and unstable. I would  
>> like to help streamline/improve/accelerate the trickling down of newer  
>> versions of Hugin/Enblend/Libpano.
> 
> Uhm … in a nutshell, this is the life cycle of a package:
> 
>  * Packages are uploaded to unstable at some time (mostly random,
>    whenever the package maintainer manages to do so).
> 
>  * Usually (unless there are serious issues with the package) the
>    package automatically migrates to testing after ten days.
> 
>  * When the release managers decide to start preparing a new release
>    (this used to happen about 1.5 years after the last release, it's an
>    ongoing discussion how this is going to be handled in the future),
>    testing is frozen, i.e. no "new features" are allowed in.
> 
>  * Whenever most of the known serious issues have been straightened out
>    (I'm not going into details about that), the frozen testing will
>    eventually be marked as (the new) stable.
> 
>  * After that, no new packages are allowed into stable, besides fixes
>    for critical and security related issues.
> 
>  * To fill the gap between stable ("rock solid" software) and testing /
>    unstable (new versions of software), there are services like
>    backports.org that make new versions available to users of stable.
> 
> Does that give you an idea how things work? You'll find much more
> detailed information on the web …

thank you, yes. I understand the general idea. The detailed question 
would be then: who put 0.7.0 into backports.org? how does this happen? 
can we make it happen for 0.8.0 ? and for 2009.2.0 (expected before the 
end of the month)? and for enblend 4.0?

have a good day
Yuv