No subject
Thu Mar 1 00:02:59 CET 2007
- shared libs libkexiv2 : 4 hours. very easy...
- shared libs libkdcraw : 1 day maximum, not more.
- shared libs libkipi : 3-4 days.
- digiKam core : 2-3 weeks (without testing indeep).
- DigikamImagePlugins : 1-2 weeks (without testing indeep).
- kipi-plugins : 4-5 weeks depending of contributors avaibility.
Nota : unforget than all Makefile.am/configure.in need to be converted to
CMake. This is a tiedous job, especially to test all compilations
conditions. The time given before do not includes CMake port
But, like you can see, all features will be frozen a few month, not one yea=
r
(:=3D))))
Of course, like i said 'porting to QT4', i would mean porting as well
without add new features or improve implementation indeep. I think this is
mandatory to be able to compare QT3 and QT4 implementations
> > If this would really freeze feature additions for one year,
> > I would also like to add a few wishes before that ;-)
> > (OTOH, Gilles is so fast, so maybe the freeze would much shorter ;-0)
>
> As someone who can (probably) not contribute to this migration I still
> would like to inject my opinion. A 1 year feature freeze will put-off
> everyone, first you, the developers, and than our users. It's too long a
> stretch of time.
>
> We should ask for help (even if we might not get any,
> because everyone active is in the same busy boat), and cut it into pieces
> like that:
> - As Gilles proposed, convert the libraries first
> - then the digikam core
> - add features when deemed juicy to qt3 at any time, interrupting
migration
> - migrate the plugins one by one
> - migrate kipis, and there export at first (here we have other developers=
)
>
> I also think that experience and know-how with migration will grow rapidl=
y
> everywhere, in particular in amarok which has to deal with threading as
> much as we have to. With the result that it will not take 1 year. I
> definitely hope so.
>
> Gerhard
I agree with Gilles about to merge both digiKam and digikamImagePlugins in
one
and only package, there is no reason to have two separate projects now.
agree
About migration to QT4 I think Gerhard makes a good proposition, this could
be
a good start point to work on a time line to get it.
What's about some features like non-destructive edition, light table, and
so...?
see my response before. This can be implemented just later QT4 port.
Gilles
------=_Part_67694_26498873.1172768923979
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
<br><br>
<div><span class=3D"gmail_quote">2007/3/1, F.J.Cruz <<a href=3D"mailto:f=
rancisco.jct at gmail.com">francisco.jct at gmail.com</a>>:</span></div>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">El Jueves, 1 de Marzo de 2007, G=
erhard Kulzer escribi=F3:<br>> Am Thursday 01 March 2007 schrieb Arnd Ba=
ecker:
<br>> > On Thu, 1 Mar 2007, Fabien wrote:<br>> ><br>> > [=
...]<br>> ><br>> > > I guess that when you will start to por=
t digiKam to QT4, there will be<br>> > > a feature freeze for arou=
nd 1 year, the time to change the source code
<br>> > > and to stabilize the new version, isn't it ?<br>>=
></blockquote>
<div> </div>
<div>From my developper viewpoint, this is my time plan to port on QT4 :</d=
iv>
<div> </div>
<div>- shared libs libkexiv2 : 4 hours. very easy...</div>
<div>- shared libs libkdcraw : 1 day maximum, not more.</div>
<div>- shared libs libkipi : 3-4 days.</div>
<div> </div>
<div>- digiKam core : 2-3 weeks (without testing indeep).</div>
<div>- DigikamImagePlugins : 1-2 weeks (without testing indeep).</div>
<div> </div>
<div>- kipi-plugins : 4-5 weeks depending of contributors avaibility.</div>
<div> </div>
<div>Nota : unforget than all <a href=3D"http://Makefile.am/configure.in">M=
akefile.am/configure.in</a> need to be converted to CMake. This is a tiedou=
s job, especially to test all compilations conditions. The time given befor=
e do not includes CMake port
</div>
<p>But, like you can see, all features will be frozen a few month, not one =
year (:=3D))))</p>
<div>Of course, like i said 'porting to QT4', i would mean porting =
as well without add new features or improve implementation indeep. I think =
this is mandatory to be able to compare QT3 and QT4 implementations</div>
<div> </div>
<div>> > If this would really freeze feature additions for one year,<=
br>> > I would also like to add a few wishes before that ;-)<br>> =
> (OTOH, Gilles is so fast, so maybe the freeze would much shorter ;-0)
<br>><br>> As someone who can (probably) not contribute to this migra=
tion I still<br>> would like to inject my opinion. A 1 year feature free=
ze will put-off<br>> everyone, first you, the developers, and than our u=
sers. It's too long a
<br>> stretch of time.<br>><br>> We should ask for help (even if w=
e might not get any,<br>> because everyone active is in the same busy bo=
at), and cut it into pieces<br>> like that:<br>> - As Gilles proposed=
, convert the libraries first
<br>> - then the digikam core<br>> - add features when deemed juicy t=
o qt3 at any time, interrupting migration<br>> - migrate the plugins one=
by one<br>> - migrate kipis, and there export at first (here we have ot=
her developers)
<br>><br>> I also think that experience and know-how with migration w=
ill grow rapidly<br>> everywhere, in particular in amarok which has to d=
eal with threading as<br>> much as we have to. With the result that it w=
ill not take 1 year. I
<br>> definitely hope so.<br>><br>> Gerhard<br><br>I agree with Gi=
lles about to merge both digiKam and digikamImagePlugins in one<br>and only=
package, there is no reason to have two separate projects now.<br> </=
div>
<div>agree</div>
<div><br>About migration to QT4 I think Gerhard makes a good proposition, t=
his could be<br>a good start point to work on a time line to get it.<br><br=
>What's about some features like non-destructive edition, light table, =
and
<br>so...?</div>
<div> </div>
<div>see my response before. This can be implemented just later QT4 port.<b=
r> </div>
<div>Gilles</div>
------=_Part_67694_26498873.1172768923979--
More information about the Digikam-devel
mailing list