Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
On Friday 09 May 2008, David Faure wrote: On Tuesday 06 May 2008, Tom Albers wrote: Op dinsdag 06 mei 2008 18:46 schreef u: Am Dienstag, 6. Mai 2008, um 18:39 Uhr, schrieb Tom Albers: Op dinsdag 06 mei 2008 18:30 schreef u: I disagree. I think it is a must to be BC between minor releases. Not for a rarely-used lib like one that kdeutils would provide, IMHO. Wearing my distro packagers hat, not being binary compatible is acceptable *IF* you remember to also bump the SONAME /Sune -- How might I explore the software from AutoCAD 2.9 and from the control panel inside Office? You should never mount the URL and you either have to reset a server of a PCI system, or can never ping the GUI on a computer over a driver to the DirectGL pointer, in such way from Explorer 8000 you neither must turn on the laser login, nor need to insert the graphic attachment for telnetting from a AGP mousepad. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
On Tuesday 06 May 2008, Tom Albers wrote: Op dinsdag 06 mei 2008 18:46 schreef u: Am Dienstag, 6. Mai 2008, um 18:39 Uhr, schrieb Tom Albers: Op dinsdag 06 mei 2008 18:30 schreef u: I disagree. I think it is a must to be BC between minor releases. Not for a rarely-used lib like one that kdeutils would provide, IMHO. For me it would be more work, as I would have development spanned between extragear/libs and kdeutils. And it would add an additional (if only soft) dependency between modules. No, as long as you make releases from the library, it's is just another 'external' dependency. As long as it is not a cyclic dependency as we now face with libkipi, it is not a problem. We misunderstand each other? kdeutils/okteta would depend on extragear/libs/okteta. Now it does not. Think of the packagers. And checkouts of KDE's repository. No. it is perfectly fine for a kdeutils app to depend on a library. If that happens to live in kde's svn too, that's fine. It is up to you to keep the kdeutils app compilable to your latest release of the lib. I disagree. There's stuff in extragear that needs the base kde modules (trunk/KDE/*), so we shouldn't have the reverse dependency. trunk/KDE can depend on kdesupport libs, but not on extragear libs - extragear is compiled *after* trunk/KDE, otherwise we have a cyclic dependency. -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
Am Dienstag, 6. Mai 2008, um 17:17 Uhr, schrieb Andreas Pakulat: On 05.05.08 21:24:52, Andras Mantia wrote: Actually would be nice to see at least a KDevPlatform release. I know its hard, but maybe makes sense, just like kdelibs was released before the actual KDE 4.0.0. Well, we could probably do that, but without any guarantees regarding binary compatibility. Especially not for the interfaces, shell, project, sublime, language and vcs libraries. I have a similar problem. I know at least one person which would like to make use of the Okteta libraries (implementing a specialised ByteArrayModel) in a 3rd-party project after the 4.1 release. But I know for sure the API will change for 4.2 again, so I do not install any headers. Right now I had to tell him bad luck... I did not find an explicit rule for this on techbase.kde.org, just remember the general unwritten rule ensure binary interface compatibility in minor releases. Could this rule be made mandatory only for kdelibs and kdepimlibs? So young and evolving libraries could follow the principle release often and early and get some more feedback, until they are mature enough to keep BIC till a next major release. Those interested to make use of such libraries would know of the risks and have a reason for still using them. Of course the API documentation should contain proper big warnings. Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
On 06.05.08 17:56:11, Friedrich W. H. Kossebau wrote: Am Dienstag, 6. Mai 2008, um 17:17 Uhr, schrieb Andreas Pakulat: On 05.05.08 21:24:52, Andras Mantia wrote: Actually would be nice to see at least a KDevPlatform release. I know its hard, but maybe makes sense, just like kdelibs was released before the actual KDE 4.0.0. Well, we could probably do that, but without any guarantees regarding binary compatibility. Especially not for the interfaces, shell, project, sublime, language and vcs libraries. I have a similar problem. I know at least one person which would like to make use of the Okteta libraries (implementing a specialised ByteArrayModel) in a 3rd-party project after the 4.1 release. But I know for sure the API will change for 4.2 again, so I do not install any headers. Right now I had to tell him bad luck... I did not find an explicit rule for this on techbase.kde.org, just remember the general unwritten rule ensure binary interface compatibility in minor releases. Thats currently only a rule for kdelibs+kdepimlibs - AFAIK. Other modules in KDE/ need to decide on that themselves, for example kdegames broke BC in their libkdegames library between 4.0 and 4.1. The techbase page explicitly says that the guidelines are not mandatory. Andreas -- Tomorrow, you can be anywhere. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
Op dinsdag 06 mei 2008 17:56 schreef u: Am Dienstag, 6. Mai 2008, um 17:17 Uhr, schrieb Andreas Pakulat: On 05.05.08 21:24:52, Andras Mantia wrote: Actually would be nice to see at least a KDevPlatform release. I know its hard, but maybe makes sense, just like kdelibs was released before the actual KDE 4.0.0. Well, we could probably do that, but without any guarantees regarding binary compatibility. Especially not for the interfaces, shell, project, sublime, language and vcs libraries. I have a similar problem. I know at least one person which would like to make use of the Okteta libraries (implementing a specialised ByteArrayModel) in a 3rd-party project after the 4.1 release. But I know for sure the API will change for 4.2 again, so I do not install any headers. Right now I had to tell him bad luck... I did not find an explicit rule for this on techbase.kde.org, just remember the general unwritten rule ensure binary interface compatibility in minor releases. From the policies section: http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ In the KDE project, we will provide binary compatibility within the life-span of a major release. Could this rule be made mandatory only for kdelibs and kdepimlibs? So young and evolving libraries could follow the principle release often and early and get some more feedback, until they are mature enough to keep BIC till a next major release. Those interested to make use of such libraries would know of the risks and have a reason for still using them. Of course the API documentation should contain proper big warnings. I disagree. I think it is a must to be BC between minor releases. If you want to be bic public, go to extragear/libs untill you are ready... Best, Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
Am Dienstag, 6. Mai 2008, um 18:15 Uhr, schrieb Andreas Pakulat: On 06.05.08 17:56:11, Friedrich W. H. Kossebau wrote: Am Dienstag, 6. Mai 2008, um 17:17 Uhr, schrieb Andreas Pakulat: On 05.05.08 21:24:52, Andras Mantia wrote: Actually would be nice to see at least a KDevPlatform release. I know its hard, but maybe makes sense, just like kdelibs was released before the actual KDE 4.0.0. Well, we could probably do that, but without any guarantees regarding binary compatibility. Especially not for the interfaces, shell, project, sublime, language and vcs libraries. I have a similar problem. I know at least one person which would like to make use of the Okteta libraries (implementing a specialised ByteArrayModel) in a 3rd-party project after the 4.1 release. But I know for sure the API will change for 4.2 again, so I do not install any headers. Right now I had to tell him bad luck... I did not find an explicit rule for this on techbase.kde.org, just remember the general unwritten rule ensure binary interface compatibility in minor releases. Thats currently only a rule for kdelibs+kdepimlibs - AFAIK. Other modules in KDE/ need to decide on that themselves, for example kdegames broke BC in their libkdegames library between 4.0 and 4.1. Was libkdegames public for 3rd-party development, i.e. have the headers been installed? The techbase page explicitly says that the guidelines are not mandatory. Which page is that? Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
Op dinsdag 06 mei 2008 18:30 schreef u: I disagree. I think it is a must to be BC between minor releases. For everything? Yes. If you want to be bic public, go to extragear/libs untill you are ready... What would this change for 3rd-party developers? You can make a release whenever you like and bump the major so version of the lib as you like in each release. For me it would be more work, as I would have development spanned between extragear/libs and kdeutils. And it would add an additional (if only soft) dependency between modules. No, as long as you make releases from the library, it's is just another 'external' dependency. As long as it is not a cyclic dependency as we now face with libkipi, it is not a problem. Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
Am Dienstag, 6. Mai 2008, um 18:39 Uhr, schrieb Tom Albers: Op dinsdag 06 mei 2008 18:30 schreef u: I disagree. I think it is a must to be BC between minor releases. If you want to be bic public, go to extragear/libs untill you are ready... What would this change for 3rd-party developers? You can make a release whenever you like and bump the major so version of the lib as you like in each release. That would be me, but I asked for 3rd-party developers. Then, I know I would not make releases independent of the KDE ones, because I would develop the libs and the program together. So nothing would change for 3rd parties, just another location. For me it would be more work, as I would have development spanned between extragear/libs and kdeutils. And it would add an additional (if only soft) dependency between modules. No, as long as you make releases from the library, it's is just another 'external' dependency. As long as it is not a cyclic dependency as we now face with libkipi, it is not a problem. We misunderstand each other? kdeutils/okteta would depend on extragear/libs/okteta. Now it does not. Think of the packagers. And checkouts of KDE's repository. Friedrich ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
On 06.05.08 18:22:09, Friedrich W. H. Kossebau wrote: Am Dienstag, 6. Mai 2008, um 18:15 Uhr, schrieb Andreas Pakulat: On 06.05.08 17:56:11, Friedrich W. H. Kossebau wrote: Am Dienstag, 6. Mai 2008, um 17:17 Uhr, schrieb Andreas Pakulat: On 05.05.08 21:24:52, Andras Mantia wrote: Actually would be nice to see at least a KDevPlatform release. I know its hard, but maybe makes sense, just like kdelibs was released before the actual KDE 4.0.0. Well, we could probably do that, but without any guarantees regarding binary compatibility. Especially not for the interfaces, shell, project, sublime, language and vcs libraries. I have a similar problem. I know at least one person which would like to make use of the Okteta libraries (implementing a specialised ByteArrayModel) in a 3rd-party project after the 4.1 release. But I know for sure the API will change for 4.2 again, so I do not install any headers. Right now I had to tell him bad luck... I did not find an explicit rule for this on techbase.kde.org, just remember the general unwritten rule ensure binary interface compatibility in minor releases. Thats currently only a rule for kdelibs+kdepimlibs - AFAIK. Other modules in KDE/ need to decide on that themselves, for example kdegames broke BC in their libkdegames library between 4.0 and 4.1. Was libkdegames public for 3rd-party development, i.e. have the headers been installed? AFAIK some apps in extragear and playground use it, AFAIK. The techbase page explicitly says that the guidelines are not mandatory. Which page is that? http://techbase.kde.org/index.php?title=Policies/Library_Code_Policy Right at the top. Andreas -- Life, loathe it or ignore it, you can't like it. -- Marvin, Hitchhiker's Guide to the Galaxy signature.asc Description: Digital signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
On 06.05.08 19:01:15, Tom Albers wrote: Op dinsdag 06 mei 2008 18:46 schreef u: Am Dienstag, 6. Mai 2008, um 18:39 Uhr, schrieb Tom Albers: Op dinsdag 06 mei 2008 18:30 schreef u: I disagree. I think it is a must to be BC between minor releases. If you want to be bic public, go to extragear/libs untill you are ready... What would this change for 3rd-party developers? You can make a release whenever you like and bump the major so version of the lib as you like in each release. That would be me, but I asked for 3rd-party developers. Then, I know I would not make releases independent of the KDE ones, because I would develop the libs and the program together. So nothing would change for 3rd parties, just another location. The difference is that you have a proper versioning with library version numbers. 3rd party devels can check for that and adapt their code to those versions. What has library versioning to do with keeping BC? If a lib breaks BC it increases its so version and can also adjust its major version number. The library doesn't have to follow the global KDE version number at all, for example the kdevplatform libs don't do it for the plain reason that its not very honest to say they are version 4.x. That version would indicate a matureness the library simply doesn't have. I like to keep minor release from KDE BC and more importantly 3rd party devels should be able to rely on that. Right, people using a lib need to rely on that lib keeping BC within a major version, that doesn't mean a library can't change BC between releases, it just means it needs to increase its major version. And if the library devs want to release it with KDE and have it as KDE module thats fine too - IMHO. Andreas -- You are a fluke of the universe; you have no right to be here. signature.asc Description: Digital signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Goals? How are we doing?
On Tuesday 06 May 2008, Andreas Pakulat wrote: Well, we could probably do that, but without any guarantees regarding binary compatibility. Especially not for the interfaces, shell, project, sublime, language and vcs libraries. Yes, this is a problem. But still would be nice to release, like e.g v3.99 of the platform (or 0.99 I don't remember now what was decided about the version numbering) and stating that BC is not guaranteed. And of course name the libraries in a form that the final 4.0 libraries will have different so versions. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: breaking BIC for new addon libs in minor releases (was: Re: Goals? How are we doing?)
A Dimarts 06 Maig 2008, Tom Albers va escriure: Op dinsdag 06 mei 2008 18:30 schreef u: I disagree. I think it is a must to be BC between minor releases. For everything? Yes. I disagree, this was never a promise we made outside kdelibs + kdepimlibs + maybe kdebase-runtime. I agree it is good not changing SC/BC for the sake of doing it but let's not make things imposible to work, or do you want libokteta (e.g) to virtually be forked until KDE5 if current api is not good enough? Albert If you want to be bic public, go to extragear/libs untill you are ready... What would this change for 3rd-party developers? You can make a release whenever you like and bump the major so version of the lib as you like in each release. For me it would be more work, as I would have development spanned between extragear/libs and kdeutils. And it would add an additional (if only soft) dependency between modules. No, as long as you make releases from the library, it's is just another 'external' dependency. As long as it is not a cyclic dependency as we now face with libkipi, it is not a problem. Toma ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Goals? How are we doing?
Here's a list of our goals for 4.1. Please provide a status update, if you can: - Windows port (Frameworks and Applications) - Mac port (Frameworks and Applications) - OpenSolaris port - Plasma with widgets on canvas, makes things like layouting much easier, and generally integrating widgets into Plasmoids - Webkit in Plasma - GStreamer, Quicktime, DirectShow9 Phonon backends - Apple dashboard widgets support in Plasma - Decibel VOIP and real-time communication framework - Dragon Player multimedia player = This is Done! - Lokalize (formerly Kaider) computer-aided translation system =This is Done! - More polished Kopete - KDevelop and KDevplatform modules =We should remove this goal, I guess? - KDE-PIM module, with some Akonadi functionality - KBlogger for KDE-PIM =This won't happen. I'll remove it. - Move Akonadi library into the kdepimlibs module = This is Done! - GetHotNewStuff2 / DXS - Plasmagik plasma packages and add-on creator ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Goals? How are we doing?
On Monday 05 May 2008 09:46:48 Allen Winter wrote: Here's a list of our goals for 4.1. Please provide a status update, if you can: - Windows port (Frameworks and Applications) - Mac port (Frameworks and Applications) - OpenSolaris port - Plasma with widgets on canvas, makes things like layouting much easier, and generally integrating widgets into Plasmoids - Webkit in Plasma - GStreamer, Quicktime, DirectShow9 Phonon backends - Apple dashboard widgets support in Plasma - Decibel VOIP and real-time communication framework - Dragon Player multimedia player = This is Done! - Lokalize (formerly Kaider) computer-aided translation system =This is Done! - More polished Kopete Not happening for 4.1. Kopete has next to zero developers ATM. They've all been sucked into real life. :( - KDevelop and KDevplatform modules =We should remove this goal, I guess? I don't know. We tried hard to get to a point of being releaseable, but we're not there yet. (or people are too picky). I'll see about pushing the point this week. - KDE-PIM module, with some Akonadi functionality - KBlogger for KDE-PIM =This won't happen. I'll remove it. - Move Akonadi library into the kdepimlibs module = This is Done! - GetHotNewStuff2 / DXS - Plasmagik plasma packages and add-on creator Thanks -- Matt ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Goals? How are we doing?
On Monday 05 May 2008, Allen Winter wrote: - Plasma with widgets on canvas, makes things like layouting much easier, and generally integrating widgets into Plasmoids - Webkit in Plasma both are done. - GStreamer, Quicktime, DirectShow9 Phonon backends - Apple dashboard widgets support in Plasma in kdereview atm. will be doing a bunch of moves from review next week i think. - Plasmagik plasma packages and add-on creator this is actually a topic for a SoC project so i'm hesitant to move it out at this point. we'll punt on this for 4.2 and/or move it to extragear at the end of SoC -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Goals? How are we doing?
On Monday 05 May 2008 11:07:41 Matt Rogers wrote: On Monday 05 May 2008 09:46:48 Allen Winter wrote: Here's a list of our goals for 4.1. Please provide a status update, if you can: - KDevelop and KDevplatform modules =We should remove this goal, I guess? I don't know. We tried hard to get to a point of being releaseable, but we're not there yet. (or people are too picky). I'll see about pushing the point this week. I'm having a similar struggle with kdepim. Perhaps i am being too picky. The Ultimate Authority (my wife) says to release kdepim. So that's what we'll try to do -- however probably removing kpilot, kmobiletools, and maybe a couple others... ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
KNewStuff2/DXS Status (was Goals? How are we doing?)
Allen, others, Sorry, didn't subscribe until after you asked, but here's the current status of KNewStuff2/DXS. KNewStuff2 is currently very complete as far as using http providers like kde- look.org, kde-apps.org, etc. Caching (feature mentioned on the 4.1 goal page) is fairly stable, but could use more testing when used with DXS. I don't see anyone needing/wanting this yet, except Kalzium, but it'll probably wait until Categories are implemented also. The ui changes/fixes will be in place shortly assuming Goya makes it into kdereview and then kdelibs in time. Otherwise, it'll have to wait until 4.2 unfortunately. DXS Implementation is getting there, currently, viewing, downloading, setting comments, viewing comments, etc. works. New providers can be set up pretty quickly on data.knewstuff.org (which will hopefully soon be aliased as newstuff.kde.org) The server there is a test server, but with newstuff.kde.org pointing there, it should be trivial to switch to a server of our own once we show sysadmin the need for one, we already have daily backups of the database, and possibly web-content (Josef, feel free to clarify) to KDE servers. Categories is another thing that has been designed, but not implemented completely yet. I'll try to get this in this week, but otherwise it'll have to wait until 4.2 also. A couple games and Kalzium would like this very much. So I guess my priorities for release are as follows: 1. DXS working as well as http does (wrt caching and registry). 2. Ui fixes if goya makes it into kdelibs in time. 3. Categories support. I'll do my best to get all of them done. Jeremy ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Goals? How are we doing?
On Monday 05 May 2008 11:18:04 Aaron J. Seigo wrote: On Monday 05 May 2008, Allen Winter wrote: - Plasma with widgets on canvas, makes things like layouting much easier, and generally integrating widgets into Plasmoids - Webkit in Plasma both are done. - GStreamer, Quicktime, DirectShow9 Phonon backends - Apple dashboard widgets support in Plasma in kdereview atm. will be doing a bunch of moves from review next week i think. - Plasmagik plasma packages and add-on creator this is actually a topic for a SoC project so i'm hesitant to move it out at this point. we'll punt on this for 4.2 and/or move it to extragear at the end of SoC Please clarify the Plasmagik status.. do you mean I should remove it from the 4.1 Goals, or that I should reschedule it for the 4.2 Goals? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Goals? How are we doing?
On Monday 05 May 2008, Allen Winter wrote: this is actually a topic for a SoC project so i'm hesitant to move it out at this point. we'll punt on this for 4.2 and/or move it to extragear at the end of SoC Please clarify the Plasmagik status.. do you mean I should remove it from the 4.1 Goals, or that I should reschedule it for the 4.2 Goals? resched for 4.2 i think so the SoC project can have its run. whether it will land in base or extragear is the only question at this point. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Goals? How are we doing?
On Monday 05 May 2008, Matt Rogers wrote: - KDevelop and KDevplatform modules =We should remove this goal, I guess? I don't know. We tried hard to get to a point of being releaseable, but we're not there yet. (or people are too picky). I'll see about pushing the point this week. Actually would be nice to see at least a KDevPlatform release. I know its hard, but maybe makes sense, just like kdelibs was released before the actual KDE 4.0.0. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Phonon backends, was Re: Goals? How are we doing?
On Monday 05 May 2008 16:46:48 Allen Winter wrote: Here's a list of our goals for 4.1. Please provide a status update, if you can: - GStreamer, Quicktime, DirectShow9 Phonon backends This is something seems not solved yet. From re-reading related discussions, I gather that the release strategy of Phonon looks like Matthias describes: On Saturday 29 March 2008 11:36:41 Matthias Kretz wrote: On releases: - libphonon gets released with KDE and Qt. KDE 4.0 shipped libphonon 4.0, Qt 4.4 will ship libphonon 4.1, KDE 4.1 will ship libphonon 4.2 - phonon-xine will only get released with KDE - phonon-gstreamer get's released with Qt, but I will look into whether we want to release phonon-gstreamer with KDE 4.1, too - phonon-qt/ds will only get released with Qt unless some KDE-Windows/Mac developer wants to do something there Last signs on core-devel said that the phonon backends in kdereview required a newer Qt version than qt-copy at that point in time. I assume that as soon as 4.4 hits qt-copy that is solved (or maybe it even is already, status?). So those backends could then go with libphonon 4.2 into ... The question is wether we want to release the backends in kdebase or in extragear? The QuickTime7 backend won't build outside Qt, so we won't release it (and it probably doesn't make much sense to do so anyway). The question is how much sense it makes to have our own releases for those backends as well. It would be worth it when we want to add features and require them, and Qt cannot be updated in the meantime. Not sure about the DS9 backend. In any case, those backends have been in kdereview forever, which isn't good. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Phonon backends, was Re: Goals? How are we doing?
On Monday 05 May 2008, Sebastian Kuegler wrote: On Monday 05 May 2008 16:46:48 Allen Winter wrote: Here's a list of our goals for 4.1. Please provide a status update, if you can: - GStreamer, Quicktime, DirectShow9 Phonon backends This is something seems not solved yet. From re-reading related discussions, I gather that the release strategy of Phonon looks like Matthias describes: On Saturday 29 March 2008 11:36:41 Matthias Kretz wrote: On releases: - libphonon gets released with KDE and Qt. KDE 4.0 shipped libphonon 4.0, Qt 4.4 will ship libphonon 4.1, KDE 4.1 will ship libphonon 4.2 - phonon-xine will only get released with KDE - phonon-gstreamer get's released with Qt, but I will look into whether we want to release phonon-gstreamer with KDE 4.1, too - phonon-qt/ds will only get released with Qt unless some KDE-Windows/Mac developer wants to do something there Last signs on core-devel said that the phonon backends in kdereview required a newer Qt version than qt-copy at that point in time. I assume that as soon as 4.4 hits qt-copy that is solved (or maybe it even is already, status?). So those backends could then go with libphonon 4.2 into ... The question is wether we want to release the backends in kdebase or in extragear? The QuickTime7 backend won't build outside Qt, so we won't release it (and it probably doesn't make much sense to do so anyway). The question is how much sense it makes to have our own releases for those backends as well. It would be worth it when we want to add features and require them, and Qt cannot be updated in the meantime. Not sure about the DS9 backend. In any case, those backends have been in kdereview forever, which isn't good. I'd like to move the gstreamer backend out of kdereview and into either kdemultimedia or kdebase for KDE 4.1. After 4.1, I think phonon and its backends will have to release independently of KDE. The GStreamer backend for 4.1 has an important difference to the one in Qt4.4: It integrates correctly into the device preference settings - just like the phonon xine backend does already. I don't want to move any of the other backends as I don't work on those and can't test them. As I don't know of any KDE people working on them or anybody interested in getting them into a KDE 4.1 release I see no point in moving them to a KDE module. They just need some open repository until Phonon has found its right place. -- Matthias Kretz (Germany) http://Vir.homelinux.org/ [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
