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 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 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: kde4support => kdelibs4support[Was: Re: Releasing Deprecated modules and Tier 4 Definition]
On Thu, Apr 3, 2014 at 8:53 PM, Kevin Ottens 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 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 Wednesday 19 March 2014 10:41:15 Ben Cooksley wrote: > On Wed, Mar 19, 2014 at 7:15 AM, Kevin Ottens 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: 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 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 Wed, Mar 19, 2014 at 7:15 AM, Kevin Ottens 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: 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: 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
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 March 2014 16:45, Alex Merry wrote: > On 17/03/14 15:25, Aurélien Gâteau wrote: >> 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". + 1 > ... 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. I think I've advocated in other forums that we need a "maturity" metadata flag for Apps and Frameworks that relates to our Application/Frameworks Life Cycle and is documented somewhere prominent so users know what we mean and promise, something like: Experimental / Playground / Unstable Incubator / Review / Tech Preview Stable / Released / Supported / Active Deprecated / Inactive Unsupported / Retired / Abandoned John. ___ 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: 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
> 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
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
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
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 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 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 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
Re: Releasing Deprecated modules and Tier 4 Definition
On Sat, Mar 15, 2014 at 4:59 PM, 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. > 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
