--nextPart13408321.gnUC9NRB8r
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Ian Monroe wrote:
>On Thu, Mar 27, 2008 at 9:11 AM, Kevin Krammer <kevin.krammer@gmx.at>=20
wrote:
>> On Thursday 27 March 2008, Sebastian Kuegler wrote:
>>  > The Phonon backends have been in kdereview for ages now. How about
>>  > we move them into kdelibs now?
>>
>>  I think Thiago initially added them to kdebase/runtime and moved them
>> out because of the 4.0 freeze. So they should probably be moved back
>> there again. On Thu, Mar 27, 2008 at 6:13 AM, Sebastian Kuegler
>> <sebas@kde.org> wrote: The Phonon backends have been in kdereview for
>> ages now. How about we move them into kdelibs now?
>
>Is Trolltech promising to follow the KDE release cycle? That would be
>two product release cycles they'd have to contend with, seems unlikely
>to me.

No, Trolltech will follow the Qt release cycle. We will create a branch in=
=20
Subversion when we've reached feature freeze and then work there.

The problem is when KDE freezes trunk but Qt's next version isn't frozen=20
yet. The ideal situation would be that trunk never freezes, but KDE=20
instead branches into the next version. That's how we develop internally=20
(qt/main never freezes) as well as WebKit.

Another possibility is to put the code somewhere other than kdebase:=20
kdesupport or extragear/multimedia.

>We could just let Qt handle releasing the backends, so extragear would
>make sense. However I could see us adding features to their backends
>to support newer libphonon features (since Qt is always going to be a
>little behind with their copy of Phonon), so having KDE releases of
>Gst/ds9/qt would make sense at that point. I'm still not sure kdebase
>is a workable way to do it, seems like we would want to release a
>recent tag of their backends, not just whatever happens to be in
>kdebase at the time.
>
>Last time I tried to compile phonon-gstreamer (last week), it appeared
>to not compile due to it requiring a Qt 4.4 newer then the one in
>qt-copy.

Yeah, it makes sense. I guess extragear is preferrable. The odd thing is=20
that the code is found under "src/3rdparty/kdebase" in Qt's sources.

=2D-=20
=A0 Thiago Macieira =A0- =A0thiago (AT) macieira.info - thiago (AT) kde.org
=A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:
=A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358

--nextPart13408321.gnUC9NRB8r
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBH6/6HM/XwBW70U1gRAly3AJ9+wJIe0KXkPuYo6HmZPE0s1TUpdwCfV3Tk
YHEC8wgPcxvYSF3IusKeTls=
=OdDG
-----END PGP SIGNATURE-----

--nextPart13408321.gnUC9NRB8r--