Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
On Friday 28 March 2014 20:17:40 Markus Slopianka wrote: On Friday 28 March 2014 15:42:16 David Faure wrote: Well we can't deprecate both khtml and kdewebkit. What do we use then, right now, to browse the web in a KDE application? Deprecate does not mean that both are not available any longer, just that 3rd party developers don't get a wrong impression that it'll be well maintained for the entirety of the KF5 series. Unless someone steps in to maintain QtWebKit, QtWebEngine is the sole future... Deprecating something before the replacement is available is very bad practice IMHO. It dilutes the notion of deprecating, too (from please move away from this to you know, one day you will have to move away from this). Once the future is there, i.e. once QtWebEngine is available, we can look at deprecating kdewebkit. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
On Friday 28 March 2014 15:42:16 David Faure wrote: Well we can't deprecate both khtml and kdewebkit. What do we use then, right now, to browse the web in a KDE application? Deprecate does not mean that both are not available any longer, just that 3rd party developers don't get a wrong impression that it'll be well maintained for the entirety of the KF5 series. Unless someone steps in to maintain QtWebKit, QtWebEngine is the sole future... ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
On Tuesday 18 March 2014 17:32:58 Markus Slopianka wrote: On Tuesday 18 March 2014 13:37:01 Aleix Pol wrote: Can we maybe agree that we want an extra value in the framework.yaml file indicating the maturity of the project? It's not about maturity, it's about security. QtWebKit is no longer maintained by Digia and I am not aware that anybody stepped up to maintain it. Therefore web security vulnerabilities stay unfixed. Well we can't deprecate both khtml and kdewebkit. What do we use then, right now, to browse the web in a KDE application? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
On Monday 17 March 2014 18:15:09 Kevin Ottens wrote: Hello, Thanks for the feedback! Adding kde-promo in CC since it might have implications on future communication. Ok, reading the whole thing - it seems a simple dot story would be useful to explain that we've made some decisions that will be relevant for those porting their applications to Frameworks 5. If I understood it correctly, these decisions are: * Some major KDE technologies are deprecated and moved to KDE Porting Aids * KDE Porting Aids will have a limited shelf life of about three releases * List of tech to be in Porting aid not 100% finished but at least: * khtml * kjs * kjsembed * krunner * kmediaplayer * And of course it offers kdelibs4support (what is that exactly?) Also, these components are no longer part of KDE Frameworks 5, which you want to emphasize in the communication. Just imagine what header would you like to see on an announcement/article: * Frameworks 5 To Not Include Deprecated Technologies * KDE Porting Aids To Have Three Releases * Introducing KDE Porting Aids And Changes to Frameworks 5 I'm guessing the first, but - just checking. /J On Saturday 15 March 2014 16:59:54 Kevin Ottens wrote: Here are the different options, they're clearly not mutually exclusive. 1) Split Tier 4 in a Tier 4 and a Tier Deprecated :) [...] 2) Release the deprecated content as a separate product [...] 3) Roll all the deprecated modules into KDE4Support [...] 4) Announce the deprecated modules will only be released three times [...] That's it for the four ideas to deal with the deprecated modules, now let's find a working cocktail. So let's pick the following cocktail: 1, 2 and 4. That means we immediately move khtml and kde4support out of KDE Frameworks (to be widely advertised) and into a KDE Porting Aids product (to be advertised only to existing KDE developers). Ben, I think you're going to hate me for that, but we learn as we progress... That means we're moving ASAP khtml and kde4support repositories out of the frameworks group of the projects tree into a new portingaids group. We'll also announce at beta time the second product, and that we aim for making only three releases out of it, coordinated with KDE Frameworks releases as to give people time to port away from it. Now, the last point... What else do we want to move from KDE Frameworks to KDE Porting Aids? Aleix and Aaron proposed the following content for KDE Porting Aids: * kde4support (obvious); * khtml (planned for a long time); * kjs (because of khtml I gather); * kjsembed (ditto); * krunner (because of upcoming sprinter, and only one user anyway); * kmediaplayer (unused AFAIK). I think that list makes sense. Is there anyone who couldn't sleep at night if those were in KDE Porting Aids? Regards. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
Hi! El 26/03/2014 13:04, Jos Poortvliet jospoortvl...@gmail.com escribió: On Monday 17 March 2014 18:15:09 Kevin Ottens wrote: Hello, Thanks for the feedback! Adding kde-promo in CC since it might have implications on future communication. Ok, reading the whole thing - it seems a simple dot story would be useful to explain that we've made some decisions that will be relevant for those porting their applications to Frameworks 5. If I understood it correctly, these decisions are: * Some major KDE technologies are deprecated and moved to KDE Porting Aids * KDE Porting Aids will have a limited shelf life of about three releases * List of tech to be in Porting aid not 100% finished but at least: * khtml * kjs * kjsembed * krunner * kmediaplayer * And of course it offers kdelibs4support (what is that exactly?) Also, these components are no longer part of KDE Frameworks 5, which you want to emphasize in the communication. Just imagine what header would you like to see on an announcement/article: * Frameworks 5 To Not Include Deprecated Technologies * KDE Porting Aids To Have Three Releases * Introducing KDE Porting Aids And Changes to Frameworks 5 I'm guessing the first, but - just checking. I think that the third is more informative and more neutral. Cheers, David Gil /J On Saturday 15 March 2014 16:59:54 Kevin Ottens wrote: Here are the different options, they're clearly not mutually exclusive. 1) Split Tier 4 in a Tier 4 and a Tier Deprecated :) [...] 2) Release the deprecated content as a separate product [...] 3) Roll all the deprecated modules into KDE4Support [...] 4) Announce the deprecated modules will only be released three times [...] That's it for the four ideas to deal with the deprecated modules, now let's find a working cocktail. So let's pick the following cocktail: 1, 2 and 4. That means we immediately move khtml and kde4support out of KDE Frameworks (to be widely advertised) and into a KDE Porting Aids product (to be advertised only to existing KDE developers). Ben, I think you're going to hate me for that, but we learn as we progress... That means we're moving ASAP khtml and kde4support repositories out of the frameworks group of the projects tree into a new portingaids group. We'll also announce at beta time the second product, and that we aim for making only three releases out of it, coordinated with KDE Frameworks releases as to give people time to port away from it. Now, the last point... What else do we want to move from KDE Frameworks to KDE Porting Aids? Aleix and Aaron proposed the following content for KDE Porting Aids: * kde4support (obvious); * khtml (planned for a long time); * kjs (because of khtml I gather); * kjsembed (ditto); * krunner (because of upcoming sprinter, and only one user anyway); * kmediaplayer (unused AFAIK). I think that list makes sense. Is there anyone who couldn't sleep at night if those were in KDE Porting Aids? Regards. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
Hello, On Tuesday 25 March 2014 16:41:12 Jos Poortvliet wrote: On Monday 17 March 2014 18:15:09 Kevin Ottens wrote: Adding kde-promo in CC since it might have implications on future communication. Ok, reading the whole thing - it seems a simple dot story would be useful to explain that we've made some decisions that will be relevant for those porting their applications to Frameworks 5. Could be a separate dot story, or could be part of the beta 1 announcement. If I understood it correctly, these decisions are: * Some major KDE technologies are deprecated and moved to KDE Porting Aids * KDE Porting Aids will have a limited shelf life of about three releases * List of tech to be in Porting aid not 100% finished but at least: * khtml * kjs * kjsembed * krunner * kmediaplayer * And of course it offers kdelibs4support (what is that exactly?) It is mainly old deprecated API from modules which don't exist anymore (like kdecore and kdeui) or fully deprecated classes of existing modules (like some classes of kio). Also, these components are no longer part of KDE Frameworks 5, which you want to emphasize in the communication. Right, very important point. Just imagine what header would you like to see on an announcement/article: * Frameworks 5 To Not Include Deprecated Technologies * KDE Porting Aids To Have Three Releases * Introducing KDE Porting Aids And Changes to Frameworks 5 I'm guessing the first, but - just checking. The first sounds negative to me, it'd sound like we completely drop them leaving people with no transition plan. Probably not the image we want to give... I think the third one although being more descriptive is the one with the least chances of being misrepresented. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
On Tue, Mar 18, 2014 at 4:36 AM, Markus Slopianka kamika...@gmx.de wrote: On Monday 17 March 2014 18:15:09 Kevin Ottens wrote: Now, the last point... What else do we want to move from KDE Frameworks to KDE Porting Aids? Aleix and Aaron proposed the following content for KDE Porting Aids: * kde4support (obvious); * khtml (planned for a long time); * kjs (because of khtml I gather); * kjsembed (ditto); * krunner (because of upcoming sprinter, and only one user anyway); * kmediaplayer (unused AFAIK). Um, isn't KDEWebKit missing? Digia already deprecated QtWebKit in favor of Chromium's Blink. Unless anybody is interested in maintaining QtWebKit the KDE bindings should be deprecated as well. Don't you think? ___ This message is from the kde-promo mailing list. Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on or temporarily stop your subscription. Maybe coming up with the list of modules now is not the most useful thing now. Can we maybe agree that we want an extra value in the framework.yaml file indicating the maturity of the project? A final list could be polished during the KF5 sprint [1]. Aleix [1] https://sprints.kde.org/sprint/224 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
On Tue, Mar 18, 2014, at 5:37, Aleix Pol wrote: Maybe coming up with the list of modules now is not the most useful thing now. Can we maybe agree that we want an extra value in the framework.yaml file indicating the maturity of the project? +1 Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
On Monday 17 March 2014 20:14:24 John Layt wrote: On 17 March 2014 18:15, Kevin Ottens er...@kde.org wrote: I think that list makes sense. Is there anyone who couldn't sleep at night if those were in KDE Porting Aids? +1 to this strategy, although some bikeshedding on the portingaids name might be welcome :-) Hmmm, nope, I'm drawing a blank... I like the limit on kde4support, we only have to look to Qt3Support to know that if the aids are left in place people will avoid porting away from them until they absolutely have to. I'm not sure we need to call it a product though, perhaps just saying a special category of Frameworks providing transitional support for a limited period of time for apps migrating from kdelibs4 to KF5 would be enough. Hey, how about KDE Transitional Frameworks? :-) Better name indeed... I would be concerned about the proximity with KDE Frameworks name wise though. That being said, having a crappy name for the product containing the deprecated modules is not necessarily a bad thing, we want to avoid marketing it widely anyway (at least outside of KDE). :-) Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
Hello, On Tuesday 18 March 2014 13:37:01 Aleix Pol wrote: On Tue, Mar 18, 2014 at 4:36 AM, Markus Slopianka kamika...@gmx.de wrote: On Monday 17 March 2014 18:15:09 Kevin Ottens wrote: Now, the last point... What else do we want to move from KDE Frameworks to KDE Porting Aids? Aleix and Aaron proposed the following content for KDE Porting Aids: * kde4support (obvious); * khtml (planned for a long time); * kjs (because of khtml I gather); * kjsembed (ditto); * krunner (because of upcoming sprinter, and only one user anyway); * kmediaplayer (unused AFAIK). Um, isn't KDEWebKit missing? Digia already deprecated QtWebKit in favor of Chromium's Blink. Unless anybody is interested in maintaining QtWebKit the KDE bindings should be deprecated as well. Don't you think? Might make sense... Maybe coming up with the list of modules now is not the most useful thing now. ... but I agree with that. Can we maybe agree that we want an extra value in the framework.yaml file indicating the maturity of the project? Yes, feel free to add it. And then anything labeled deprecated will get moved out of KDE Frameworks and into KDE Porting Aids before release. A final list could be polished during the KF5 sprint [1]. Agreed. It's also probably when we'll act on the moves. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
On Monday 17 March 2014 18:15:09 Kevin Ottens wrote: Now, the last point... What else do we want to move from KDE Frameworks to KDE Porting Aids? Aleix and Aaron proposed the following content for KDE Porting Aids: * kde4support (obvious); * khtml (planned for a long time); * kjs (because of khtml I gather); * kjsembed (ditto); * krunner (because of upcoming sprinter, and only one user anyway); * kmediaplayer (unused AFAIK). Um, isn't KDEWebKit missing? Digia already deprecated QtWebKit in favor of Chromium's Blink. Unless anybody is interested in maintaining QtWebKit the KDE bindings should be deprecated as well. Don't you think? ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
On Tuesday 18 March 2014 13:37:01 Aleix Pol wrote: Can we maybe agree that we want an extra value in the framework.yaml file indicating the maturity of the project? It's not about maturity, it's about security. QtWebKit is no longer maintained by Digia and I am not aware that anybody stepped up to maintain it. Therefore web security vulnerabilities stay unfixed. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
On 17 March 2014 18:15, Kevin Ottens er...@kde.org wrote: So let's pick the following cocktail: 1, 2 and 4. That means we immediately move khtml and kde4support out of KDE Frameworks (to be widely advertised) and into a KDE Porting Aids product (to be advertised only to existing KDE developers). Ben, I think you're going to hate me for that, but we learn as we progress... That means we're moving ASAP khtml and kde4support repositories out of the frameworks group of the projects tree into a new portingaids group. We'll also announce at beta time the second product, and that we aim for making only three releases out of it, coordinated with KDE Frameworks releases as to give people time to port away from it. Now, the last point... What else do we want to move from KDE Frameworks to KDE Porting Aids? Aleix and Aaron proposed the following content for KDE Porting Aids: * kde4support (obvious); * khtml (planned for a long time); * kjs (because of khtml I gather); * kjsembed (ditto); * krunner (because of upcoming sprinter, and only one user anyway); * kmediaplayer (unused AFAIK). I think that list makes sense. Is there anyone who couldn't sleep at night if those were in KDE Porting Aids? +1 to this strategy, although some bikeshedding on the portingaids name might be welcome :-) Hmmm, nope, I'm drawing a blank... I like the limit on kde4support, we only have to look to Qt3Support to know that if the aids are left in place people will avoid porting away from them until they absolutely have to. I'm not sure we need to call it a product though, perhaps just saying a special category of Frameworks providing transitional support for a limited period of time for apps migrating from kdelibs4 to KF5 would be enough. Hey, how about KDE Transitional Frameworks? :-) The important part is to have the clear definitions of what things mean and what our plans are. We made a horrible mistake in Qt5 of labelling things like QWidgets as Done as people just didn't understand what we meant and assumed the worst, and we all know the PR disaster that was. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
On 17 March 2014 20:14, John Layt jl...@kde.org wrote: I like the limit on kde4support, we only have to look to Qt3Support to know that if the aids are left in place people will avoid porting away from them until they absolutely have to. I'm not sure we need to call it a product though, perhaps just saying a special category of Frameworks providing transitional support for a limited period of time for apps migrating from kdelibs4 to KF5 would be enough. Hey, how about KDE Transitional Frameworks? :-) The important part is to have the clear definitions of what things mean and what our plans are. We made a horrible mistake in Qt5 of labelling things like QWidgets as Done as people just didn't understand what we meant and assumed the worst, and we all know the PR disaster that was. Oh, which is not to say that being deprecated / transitional / being given an EoL/EoS date would prevent someone from deciding to keep them alive outside Frameworks, or even bring them back in the distant future, just that is the current status. That would need good communication too. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
