kde4

[Ana Guerrero]

Some stuff already talked about this IRC, I'm repeating here to keep
the record.


On Fri, Apr 27, 2007 at 12:07:26PM +0200, Sune Vuorela wrote:
> KDE4 is coming - one day. Alphas are coming at May 3rd. I think we should try 
> package the alphas.

Yes, I think we should start packaging the alphas (or snapshots), but do not 
uploading them to experimental. And starting to upload to experimental with
the first beta due to June 25 (monday after debconf, ouch).


> 
> BUILDING
> 
> We need a lot of things in order to make kde4 usable. Partly a new 
> infrastructure is needed.
> 
> KDE4 uses cmake as build system. CDBS does not have anything directly that can 
> help us - but there is a cmake.mk in some of the kde-exstras packages, that 
> at least can serve as a inspiration.
> 
> The other parts of cdbs, the current kde.mk and the debian-qt-kde.mk does at 
> least need to be looked very carefully thru, if not completely rewritten.
>

Well, once we have started packaging the alphas, we'll discover the possible
problems and I think the best solution here is go patching^Wfixing as we go :-)
I do not think we'll have a clear idea about what is more suitable here until
we have packaged at least the alpha.


> We also have the opportunity to skip cdbs if we feel like. Or move patch 
> system to nice quilt. And other decisions. But I think we need the decisions 
> now.

I would like to continue with CDBS, and I agree about to use quilt. 


> 
> In general I would think we should start from scratch with empty debian dirs 
> in all source packages and take it from there. Maybe keep changelog for 
> historical purposes.
> 


Of course about keep the changelog.



> RELATED PACKAGES
> 
> kde4 currently uses a newer qt4 than the 4.3beta found in the kde subversion - 
> no one knows when qt4.3 will be stable - so we need to get qt4 updated to the 
> the snapshot at least.
>

Qt 4.3 will be released before the first beta (first of June) and i hope Pyro 
will uploads. Until them we can always package qt4.3 beta in alioth for our
use. 

> strigi is a very important build-dependency of kdelibs. And a newer snapshot 
> from kde trunk is also needed. I would also suggest moving strigi from 
> pkg-kde-extras to pkg-kde. And integrate the maintainers to pkg-kde team.
> 

There is not really need to move it from a team to the other.  Specially
because most of us belongs to both teams. Fathi, Mark, what about package 
lastest snapshot and upload it to experimental?


> dolphin is currently packaged in debian as a seperate thingy. Dolphin will be 
> the file manager in kde4 so we need some cooperation.  I suggest 'hijack' the 
> package and assimilate the dolphin maintainers to pkg-kde team.
> 

This will not be a problem until we upload kde 4.0 to unstable.. someday :-)
Until then, current dolphin can co-exist happily.  We should talk about this
with current maintainers, but there is not real hurry in this.


> KDE4 - PACKAGES
> 
> I would like if we could hook up with the 'review package descriptions' team 
> to create some useful goot package descriptions.
>

Yes, but it is still early to ask them for help. 

> I would also like if we aimed at making all the packages lintian clean. As 
> everything needs to be reworked anyway, we have the opportunity to do it.
> 

I doubt will be "lintian clean" some day, there will be always false
positives.


> 
> KDE3
> 
> I don't know fully have decided what to do about kde3 for the future. Maybe 
> starting with a amputated kde3libs (skipping khtml and maybe other parts as 
> well) to keep some compability and skip the rest of kde3. Maybe just skip 
> entire kde3.
> Most packages build-depending on kdebase-dev is window decorations - so that 
> could easily go away. But really many packages uses kdelibs.
>

I would not worry about this until kde4 is released. Seriously.

> 
> TIMELINE
> 
> upstream timeline starts with a + 
> My suggested actions are written in between - but maybe too tight.
> 
> +Mon, 30 April: Merge Phonon/Solid API cleanup branch.  Merge Nepomuk
> +Tues,  1 May: Begin kdelibs soft API freeze
> Have qt4 and strigi updated.
> Review cmake.mk and decide on what to do about how to build
> +Thu,  3 May: Tag KDE 4.0 Alpha1
> Infrastructure somewhat usable.
> Preliminary packages of kdelibs, kdepimlibs, kdebase ready
> +Tues, 8 May: New Application Freeze, Start Usability and Accessibility Review
> Do the rest of the packages.
> +Mon, 14 May: Tag KDE 3.5.7
> Do kde3.5.7.
> +Tues, 22 May: Expected release date of KDE 3.5.7
>

I can not commit to follow any timeline, sorry. 


IDEAS

Once we start packaging the betas, we could try to publish a lice CD 
with every beta. It is supposed to be easy make them :)


OTHER STUFF
I think we have already somehow decided do not make kde4 and kde3 coexist.


Ana