thiago at kde.org
Fri Mar 28 10:59:02 GMT 2008
On Friday 28 March 2008 11:31:43 Matthias Kretz wrote:
> kdesupport would not work as the backends depend on code in kdelibs.
> Extragear would also be lying a bit since the code as it is there never
> gets released as a single package.
Well, the xine backend may, but the Qt backends certainly don't depend on
kdelibs code :-)
> But the problem with Qt and KDE releases of phonon and phonon backends is a
> more general problem. The ideal solution would be that KDE and Qt release
> new versions at the same time. Until that happens (I may dream, right?) we
> need some other solution to not freeze libphonon every other month.
It's not going to happen for a variety of reasons. Besides, we *want* the Qt
releases to be ahead of the KDE ones, at least by a month or two.
> For that I'd love to have some place in svn where the phonon code never
> gets frozen and then branch off for either Qt or KDE releases. The same for
> backends (except all those that won't get released with Qt, like
> phonon-xine). The phonon-gstreamer backend will need a KDE version to make
> use of libkaudiodevicelist (which uses Solid) in order to do the best
> possible device listing (as you got used to from the xine backend).
"never gets frozen" = trunk. Like I said, that's how we work internally with
Perforce and how WebKit works.
Imagine how everyone (TT, KDE devels, GTK devels, Nokia, etc.) would react if
Apple decided suddenly to freeze trunk on WebKit because of Safari 4.0 which
will be released in two years?
But let's not push this decision yet. Let me propose something else then:
we're investigating switching to Git in a few months, before the Qt 4.5
release. We could decide to move the Phonon backends to a "neutral ground"
Git repository. Both sides would have to periodically merge the changes from
the "master" branch into their own tree.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel