Re: kde4support = kdelibs4support[Was: Re: Releasing Deprecated modules and Tier 4 Definition]
On Thu, Apr 3, 2014 at 8:53 PM, Kevin Ottens er...@kde.org wrote: Hello, Hi all, On Thursday 03 April 2014 09:50:24 Jos Poortvliet wrote: On Wednesday 19 March 2014 10:41:15 Ben Cooksley wrote: On Wed, Mar 19, 2014 at 7:15 AM, Kevin Ottens er...@kde.org wrote: Hello, Hi, On Monday 17 March 2014 22:53:25 Mario Fux KDE ML wrote: Am Montag, 17. März 2014, 18.15:09 schrieb Kevin Ottens: Porting Aids: * kde4support (obvious); Just that it doesn't get forgotten I'd like to second Aarons (or who it was) proposal to rename kde4support to kdelibs4support at this occasion if it's an easy rename! This might be the perfect opportunity. Makes it easier for us promo people to tell that there is no KDE4 as well. I personally don't mind. I leave the call to Ben though, as it'd mean yet another rename and they're painful on the sysadmin side. If we can, i'd like to batch all the renames together, it is less disruptive to do it all at once. So this was never executed - I will update the dot story to refer to kde4support but I think it should really be renamed if at all possible. Damn! And now that would be SIC to make it happen... *sigh* Ben, could you please make it happen now? There's apparently nothing else to batch with it, it likely means disturbances all around too as the content of the module will have to be adjusted accordingly and all the modules depending on it will break. This rename has now been conducted. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com Thanks, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kde4support = kdelibs4support[Was: Re: Releasing Deprecated modules and Tier 4 Definition]
On Tuesday 08 April 2014 22:25:48 Ben Cooksley wrote: On Thu, Apr 3, 2014 at 8:53 PM, Kevin Ottens er...@kde.org wrote: Hello, Hi all, On Thursday 03 April 2014 09:50:24 Jos Poortvliet wrote: On Wednesday 19 March 2014 10:41:15 Ben Cooksley wrote: On Wed, Mar 19, 2014 at 7:15 AM, Kevin Ottens er...@kde.org wrote: Hello, Hi, On Monday 17 March 2014 22:53:25 Mario Fux KDE ML wrote: Am Montag, 17. März 2014, 18.15:09 schrieb Kevin Ottens: Porting Aids: * kde4support (obvious); Just that it doesn't get forgotten I'd like to second Aarons (or who it was) proposal to rename kde4support to kdelibs4support at this occasion if it's an easy rename! This might be the perfect opportunity. Makes it easier for us promo people to tell that there is no KDE4 as well. I personally don't mind. I leave the call to Ben though, as it'd mean yet another rename and they're painful on the sysadmin side. If we can, i'd like to batch all the renames together, it is less disruptive to do it all at once. So this was never executed - I will update the dot story to refer to kde4support but I think it should really be renamed if at all possible. Damn! And now that would be SIC to make it happen... *sigh* Ben, could you please make it happen now? There's apparently nothing else to batch with it, it likely means disturbances all around too as the content of the module will have to be adjusted accordingly and all the modules depending on it will break. This rename has now been conducted. Thanks a bunch! 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 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: kde4support = kdelibs4support[Was: Re: Releasing Deprecated modules and Tier 4 Definition]
Hello, On Thursday 03 April 2014 09:50:24 Jos Poortvliet wrote: On Wednesday 19 March 2014 10:41:15 Ben Cooksley wrote: On Wed, Mar 19, 2014 at 7:15 AM, Kevin Ottens er...@kde.org wrote: Hello, Hi, On Monday 17 March 2014 22:53:25 Mario Fux KDE ML wrote: Am Montag, 17. März 2014, 18.15:09 schrieb Kevin Ottens: Porting Aids: * kde4support (obvious); Just that it doesn't get forgotten I'd like to second Aarons (or who it was) proposal to rename kde4support to kdelibs4support at this occasion if it's an easy rename! This might be the perfect opportunity. Makes it easier for us promo people to tell that there is no KDE4 as well. I personally don't mind. I leave the call to Ben though, as it'd mean yet another rename and they're painful on the sysadmin side. If we can, i'd like to batch all the renames together, it is less disruptive to do it all at once. So this was never executed - I will update the dot story to refer to kde4support but I think it should really be renamed if at all possible. Damn! And now that would be SIC to make it happen... *sigh* Ben, could you please make it happen now? There's apparently nothing else to batch with it, it likely means disturbances all around too as the content of the module will have to be adjusted accordingly and all the modules depending on it will break. 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: kde4support = kdelibs4support[Was: Re: Releasing Deprecated modules and Tier 4 Definition]
On Wednesday 19 March 2014 10:41:15 Ben Cooksley wrote: On Wed, Mar 19, 2014 at 7:15 AM, Kevin Ottens er...@kde.org wrote: Hello, Hi, On Monday 17 March 2014 22:53:25 Mario Fux KDE ML wrote: Am Montag, 17. März 2014, 18.15:09 schrieb Kevin Ottens: Porting Aids: * kde4support (obvious); Just that it doesn't get forgotten I'd like to second Aarons (or who it was) proposal to rename kde4support to kdelibs4support at this occasion if it's an easy rename! This might be the perfect opportunity. Makes it easier for us promo people to tell that there is no KDE4 as well. I personally don't mind. I leave the call to Ben though, as it'd mean yet another rename and they're painful on the sysadmin side. If we can, i'd like to batch all the renames together, it is less disruptive to do it all at once. So this was never executed - I will update the dot story to refer to kde4support but I think it should really be renamed if at all possible. /J Regards. Thanks, Ben -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel 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 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: kde4support = kdelibs4support[Was: Re: Releasing Deprecated modules and Tier 4 Definition]
Hello, On Monday 17 March 2014 22:53:25 Mario Fux KDE ML wrote: Am Montag, 17. März 2014, 18.15:09 schrieb Kevin Ottens: Porting Aids: * kde4support (obvious); Just that it doesn't get forgotten I'd like to second Aarons (or who it was) proposal to rename kde4support to kdelibs4support at this occasion if it's an easy rename! This might be the perfect opportunity. Makes it easier for us promo people to tell that there is no KDE4 as well. I personally don't mind. I leave the call to Ben though, as it'd mean yet another rename and they're painful on the sysadmin side. 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 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: kde4support = kdelibs4support[Was: Re: Releasing Deprecated modules and Tier 4 Definition]
On Wed, Mar 19, 2014 at 7:15 AM, Kevin Ottens er...@kde.org wrote: Hello, Hi, On Monday 17 March 2014 22:53:25 Mario Fux KDE ML wrote: Am Montag, 17. März 2014, 18.15:09 schrieb Kevin Ottens: Porting Aids: * kde4support (obvious); Just that it doesn't get forgotten I'd like to second Aarons (or who it was) proposal to rename kde4support to kdelibs4support at this occasion if it's an easy rename! This might be the perfect opportunity. Makes it easier for us promo people to tell that there is no KDE4 as well. I personally don't mind. I leave the call to Ben though, as it'd mean yet another rename and they're painful on the sysadmin side. If we can, i'd like to batch all the renames together, it is less disruptive to do it all at once. Regards. Thanks, Ben -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Releasing Deprecated modules and Tier 4 Definition
On Sunday, March 16, 2014 11:43:12 David Faure wrote: There's a middle ground between actively maintain and we made it completely impossible to even fix one bug. at which point the person(s) doing the bug fixes can take on the project an handle releases. it is free software: people can fork and/or adopt. (i'll put more thoughts on this in my response to kevin's mail) ... or to follow a change in ECM, or whatever. if ECM changes 1.5 years (or whatever) after the initial KF5 release in a way that requires changing the build files, wouldn't that be a bug in ECM? at some point ECM needs to provide stability. -- Aaron J. Seigo 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: Releasing Deprecated modules and Tier 4 Definition
On Saturday, March 15, 2014 16:59:54 Kevin Ottens wrote: we would be releasing 5.0 with modules which would be immediately deprecated. the modules that i am aware of include: * kde4support * khtml * kjs * kjsembed * krunner there are a few others that are imho borderline cases (kmediaplayer as one example) but the above are the clear cases. as a side note, could we also rename kde4support to kdelibs4support? we've spent a lot of time and effort to stamp out the (broken) kde4 naming. 2) Release the deprecated content as a separate product this is the best option imho because: * it keeps Frameworks clear in scope and focus: the set of recommended and actively developed APIs. this should be useful for app developers and packagers alike. * it allows dropping the deprecated modules at a future time without worrying about what it means for Frameworks or how to communicate the change clearly * it sets a clear precedent for KF6 as to how to handle frameworks that become deprecated during KF5's life 3) Roll all the deprecated modules into KDE4Support -1, for the reasons dfaure noted. 4) Announce the deprecated modules will only be released three times +1 after those releases, the core team would no longer need to: * manage bug reports filed against those modules * coordinate the release of those modules (which at a minimum means building and testing prior to release) public communication will be clearer; instead of a vague deprecated, eventually dropped there is a clear horizon to communicate developers will have a soft deadline for when they should want to complete porting away from these modules. it's only a soft deadline as the code will obviously still exist and someone could pick up maintenance. we all know that things tend to happen faster / more reliably when there is deadline. if there is interest in maintaining the modules past that date, those interested can take on the effort after this point. -- Aaron J. Seigo 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: Releasing Deprecated modules and Tier 4 Definition
On Sat, Mar 15, 2014, at 8:59, Kevin Ottens wrote: 1) Split Tier 4 in a Tier 4 and a Tier Deprecated :) Currently we can consider Tier 4 as badly defined. It contains both parts with no API (apidox, frameworkintegration, kfileaudiopreview) mainly for integration between frameworks and parts with deprecated APIs (kde4support and khtml ATM). It is maybe a good reason to split that in two parts: * Tier 4 containing no API, meant for runtime integration between the other frameworks and tooling (it would contain apidox, frameworkintegration and kfileaudiopreview); * Tier Deprecated containing deprecated APIs meant as a temporary porting aid from kdelibs times (it would contain kde4support and khtml). What worries me with this approach is it feels like comparing apples and oranges here. To me a framework tier is about its dependencies, not about its maturity. I would suggest to instead introduce an orthogonal information: maturity, which could have the value: new, stable, deprecated. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Releasing Deprecated modules and Tier 4 Definition
On 17/03/14 15:25, Aurélien Gâteau wrote: On Sat, Mar 15, 2014, at 8:59, Kevin Ottens wrote: 1) Split Tier 4 in a Tier 4 and a Tier Deprecated :) Currently we can consider Tier 4 as badly defined. It contains both parts with no API (apidox, frameworkintegration, kfileaudiopreview) mainly for integration between frameworks and parts with deprecated APIs (kde4support and khtml ATM). It is maybe a good reason to split that in two parts: * Tier 4 containing no API, meant for runtime integration between the other frameworks and tooling (it would contain apidox, frameworkintegration and kfileaudiopreview); * Tier Deprecated containing deprecated APIs meant as a temporary porting aid from kdelibs times (it would contain kde4support and khtml). What worries me with this approach is it feels like comparing apples and oranges here. To me a framework tier is about its dependencies, not about its maturity. I would suggest to instead introduce an orthogonal information: maturity, which could have the value: new, stable, deprecated. ... which I think is where the confusion about tier 4 has come from. This maturity information would be familiar to anyone familiar with the Qt Project's processes, which would be a bonus. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Releasing Deprecated modules and Tier 4 Definition
Hello, Thanks for the feedback! Adding kde-promo in CC since it might have implications on future communication. 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. -- 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: Releasing Deprecated modules and Tier 4 Definition
Hello, Thanks for the feedback! Adding kde-promo in CC since it might have implications on future communication. 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? Hi, perhaps I am wrong, but is not kross as good candidate to be added to this list, too? Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Releasing Deprecated modules and Tier 4 Definition
On 17/03/14 17:15, 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). Despite being the kmediaplayer maintainer, I have no great love of it, and would be happy to see it deprecated. However, it does have users: kmid and kmplayer (in extragear/multimedia) both implement it, and there is an audio plugin for the rename dialog that consumes it. LXR reckons that's it, and we have the KIO KPreviewWidget stuff (that KFileAudioPreview implements, for example) for that sort of preview. Summary: let's deprecate it (and KMid can implement KPreviewWidgetBase if they want). Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: 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). what about kdesignerplugin and kplotting? 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
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
kde4support = kdelibs4support[Was: Re: Releasing Deprecated modules and Tier 4 Definition]
Am Montag, 17. März 2014, 18.15:09 schrieb Kevin Ottens: Hello, Morning Kevin Thanks for the feedback! Thanks for your coordination! [snip] 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); Just that it doesn't get forgotten I'd like to second Aarons (or who it was) proposal to rename kde4support to kdelibs4support at this occasion if it's an easy rename! This might be the perfect opportunity. Makes it easier for us promo people to tell that there is no KDE4 as well. * 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. Thanks Mario ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Releasing Deprecated modules and Tier 4 Definition
On 17/03/14 18:50, Treeve Jelbert 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). what about kdesignerplugin and kplotting? kdesignerplugin shouldn't be deprecated. No idea about kplotting. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Releasing Deprecated modules and Tier 4 Definition
On Saturday 15 March 2014 16:59:54 Kevin Ottens wrote: Hello all, This week, Aaron brought to my attention (thx!) that we would be releasing 5.0 with modules which would be immediately deprecated. Indeed that's a potential maintenance and messaging problem. Do you have a list of such modules? From Aleix's reply I kind of guess that krunner is one of them? I didn't know it was deprecated. Also, to make things worse, it looks like it makes the definition of Tier 4 harder. I know David and I often end up arguing about it. As a way out I'm putting on the table several options in order to gather feedback about them and see which cocktail we'll apply going forward. Note that we probably want to figure that out soon in order to not make the release of beta 1 more difficult than necessary. Here are the different options, they're clearly not mutually exclusive. 1) Split Tier 4 in a Tier 4 and a Tier Deprecated :) Currently we can consider Tier 4 as badly defined. It contains both parts with no API (apidox, frameworkintegration, kfileaudiopreview) mainly for integration between frameworks and parts with deprecated APIs (kde4support and khtml ATM). It is maybe a good reason to split that in two parts: * Tier 4 containing no API, meant for runtime integration between the other frameworks and tooling (it would contain apidox, frameworkintegration and kfileaudiopreview); * Tier Deprecated containing deprecated APIs meant as a temporary porting aid from kdelibs times (it would contain kde4support and khtml). Yes. 2) Release the deprecated content as a separate product This one kind of depend on (1). If we redefine Tier 4 and have a separate group of deprecated APIs, maybe we shouldn't make the deprecated content official part of KDE Frameworks. In which case we'd release two products: KDE Frameworks for everyone and KDE Porting Aids (in lack of a better name) containing the deprecated APIs. Clearly they are not of interest to the same audience and that could warrant having two products. Yes. 3) Roll all the deprecated modules into KDE4Support Instead of having several modules containing deprecated APIs as porting aids, and since we have already a module labelled as a porting aid, why not merge everything into a single module? That module obviously would be kde4support. I admit I'm not sure how practical it would be to merge such a large beast like khtml in there, it seems doable though. No. A tier can contain multiple frameworks, that's the difference between a tier and a framework :-) It especially means the tier of a framework can change if necessary, while this is much harder when everything is bundled together. I want to leave the khtml option open (it still has contributors, and could be considered useful in some use cases). 4) Announce the deprecated modules will only be released three times Probably easier if we also apply it with (2). But since they are a porting aid, it might not make sense to keep the release burden throughout the whole KDE Frameworks 5 lifetime, to finally stop releasing them in the distant future of KDE Frameworks 6. That's especially true because of the limited manpower, and it's not exactly easy on the morale to actively maintain and release something that everyone is running from. So, what about being honest with ourselves and limit the number of releases the deprecated modules would have? If we go that route, I propose only three releases (5.0, 5.1 and 5.2) and then we stop, that should give plenty of time for people to port away, especially since it would probably keep working longer (KDE Porting Aids 5.2 would likely work on top of KDE Frameworks 5.4 for instance), it's just that we won't make any special effort anymore to keep it working. I would say we'll see. As it is written above, all it means is that we're closing the door to fixing bugs after 5.2. I don't see any benefit in that, only downsides. The effort in releasing one more module amongst 57+ is negligible. There's a middle ground between actively maintain and we made it completely impossible to even fix one bug. ... or to follow a change in ECM, or whatever. -- 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
Releasing Deprecated modules and Tier 4 Definition
Hello all, This week, Aaron brought to my attention (thx!) that we would be releasing 5.0 with modules which would be immediately deprecated. Indeed that's a potential maintenance and messaging problem. Also, to make things worse, it looks like it makes the definition of Tier 4 harder. I know David and I often end up arguing about it. As a way out I'm putting on the table several options in order to gather feedback about them and see which cocktail we'll apply going forward. Note that we probably want to figure that out soon in order to not make the release of beta 1 more difficult than necessary. Here are the different options, they're clearly not mutually exclusive. 1) Split Tier 4 in a Tier 4 and a Tier Deprecated :) Currently we can consider Tier 4 as badly defined. It contains both parts with no API (apidox, frameworkintegration, kfileaudiopreview) mainly for integration between frameworks and parts with deprecated APIs (kde4support and khtml ATM). It is maybe a good reason to split that in two parts: * Tier 4 containing no API, meant for runtime integration between the other frameworks and tooling (it would contain apidox, frameworkintegration and kfileaudiopreview); * Tier Deprecated containing deprecated APIs meant as a temporary porting aid from kdelibs times (it would contain kde4support and khtml). 2) Release the deprecated content as a separate product This one kind of depend on (1). If we redefine Tier 4 and have a separate group of deprecated APIs, maybe we shouldn't make the deprecated content official part of KDE Frameworks. In which case we'd release two products: KDE Frameworks for everyone and KDE Porting Aids (in lack of a better name) containing the deprecated APIs. Clearly they are not of interest to the same audience and that could warrant having two products. 3) Roll all the deprecated modules into KDE4Support Instead of having several modules containing deprecated APIs as porting aids, and since we have already a module labelled as a porting aid, why not merge everything into a single module? That module obviously would be kde4support. I admit I'm not sure how practical it would be to merge such a large beast like khtml in there, it seems doable though. 4) Announce the deprecated modules will only be released three times Probably easier if we also apply it with (2). But since they are a porting aid, it might not make sense to keep the release burden throughout the whole KDE Frameworks 5 lifetime, to finally stop releasing them in the distant future of KDE Frameworks 6. That's especially true because of the limited manpower, and it's not exactly easy on the morale to actively maintain and release something that everyone is running from. So, what about being honest with ourselves and limit the number of releases the deprecated modules would have? If we go that route, I propose only three releases (5.0, 5.1 and 5.2) and then we stop, that should give plenty of time for people to port away, especially since it would probably keep working longer (KDE Porting Aids 5.2 would likely work on top of KDE Frameworks 5.4 for instance), it's just that we won't make any special effort anymore to keep it working. That's it for the four ideas to deal with the deprecated modules, now let's find a working cocktail. Feedback and opinions are of course welcome. 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: Releasing Deprecated modules and Tier 4 Definition
On Sat, Mar 15, 2014 at 4:59 PM, Kevin Ottens er...@kde.org wrote: Hello all, This week, Aaron brought to my attention (thx!) that we would be releasing 5.0 with modules which would be immediately deprecated. Indeed that's a potential maintenance and messaging problem. Also, to make things worse, it looks like it makes the definition of Tier 4 harder. I know David and I often end up arguing about it. As a way out I'm putting on the table several options in order to gather feedback about them and see which cocktail we'll apply going forward. Note that we probably want to figure that out soon in order to not make the release of beta 1 more difficult than necessary. Here are the different options, they're clearly not mutually exclusive. 1) Split Tier 4 in a Tier 4 and a Tier Deprecated :) Currently we can consider Tier 4 as badly defined. It contains both parts with no API (apidox, frameworkintegration, kfileaudiopreview) mainly for integration between frameworks and parts with deprecated APIs (kde4support and khtml ATM). It is maybe a good reason to split that in two parts: * Tier 4 containing no API, meant for runtime integration between the other frameworks and tooling (it would contain apidox, frameworkintegration and kfileaudiopreview); * Tier Deprecated containing deprecated APIs meant as a temporary porting aid from kdelibs times (it would contain kde4support and khtml). 2) Release the deprecated content as a separate product This one kind of depend on (1). If we redefine Tier 4 and have a separate group of deprecated APIs, maybe we shouldn't make the deprecated content official part of KDE Frameworks. In which case we'd release two products: KDE Frameworks for everyone and KDE Porting Aids (in lack of a better name) containing the deprecated APIs. Clearly they are not of interest to the same audience and that could warrant having two products. 3) Roll all the deprecated modules into KDE4Support Instead of having several modules containing deprecated APIs as porting aids, and since we have already a module labelled as a porting aid, why not merge everything into a single module? That module obviously would be kde4support. I admit I'm not sure how practical it would be to merge such a large beast like khtml in there, it seems doable though. 4) Announce the deprecated modules will only be released three times Probably easier if we also apply it with (2). But since they are a porting aid, it might not make sense to keep the release burden throughout the whole KDE Frameworks 5 lifetime, to finally stop releasing them in the distant future of KDE Frameworks 6. That's especially true because of the limited manpower, and it's not exactly easy on the morale to actively maintain and release something that everyone is running from. So, what about being honest with ourselves and limit the number of releases the deprecated modules would have? If we go that route, I propose only three releases (5.0, 5.1 and 5.2) and then we stop, that should give plenty of time for people to port away, especially since it would probably keep working longer (KDE Porting Aids 5.2 would likely work on top of KDE Frameworks 5.4 for instance), it's just that we won't make any special effort anymore to keep it working. That's it for the four ideas to deal with the deprecated modules, now let's find a working cocktail. Feedback and opinions are of course welcome. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Hi, First of all, I agree that the definition of Tier 4 is gray at the moment, escentially it's mostly things we don't want people to depend on. 1) Tier Deprecated would probably contain KRunner too, especially if sprinters ends up joining the frameworks party, which I'm unsure. Personally I think 1 and 2 would work just fine. It's mostly making sure that people doing the promotion will promote what we actually want people to rely on. Option 4 would work too, but we probably want to decide that once we have more applications ported and see what's the status. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
