<p dir="ltr">Hi!</p>
<p dir="ltr">El 26/03/2014 13:04, "Jos Poortvliet" <<a href="mailto:jospoortvliet@gmail.com">jospoortvliet@gmail.com</a>> escribió:<br>
><br>
> On Monday 17 March 2014 18:15:09 Kevin Ottens wrote:<br>
> > Hello,<br>
> ><br>
> > Thanks for the feedback!<br>
> ><br>
> > Adding kde-promo in CC since it might have implications on future<br>
> > communication.<br>
><br>
> Ok, reading the whole thing - it seems a simple dot story would be useful to<br>
> explain that we've made some decisions that will be relevant for those<br>
> porting their applications to Frameworks 5. If I understood it correctly,<br>
> these decisions are:<br>
><br>
> * Some major KDE technologies are deprecated and moved to KDE Porting Aids<br>
> * KDE Porting Aids will have a limited shelf life of about three releases<br>
> * List of tech to be in Porting aid not 100% finished but at least:<br>
>  * khtml<br>
>  * kjs<br>
>  * kjsembed<br>
>  * krunner<br>
>  * kmediaplayer<br>
>  * And of course it offers kdelibs4support (what is that exactly?)</p>
<p dir="ltr">><br>
> Also, these components are no longer part of KDE Frameworks 5, which you want<br>
> to emphasize in the communication.<br>
><br>
> Just imagine what header would you like to see on an announcement/article:<br>
> * Frameworks 5 To Not Include Deprecated Technologies<br>
> * KDE Porting Aids To Have Three Releases<br>
> * Introducing KDE Porting Aids And Changes to Frameworks 5<br>
><br>
> I'm guessing the first, but - just checking.</p>
<p dir="ltr">I think that the third is more informative and more neutral.</p>
<p dir="ltr">Cheers,</p>
<p dir="ltr">David Gil</p>
<p dir="ltr">><br>
> /J<br>
><br>
> > On Saturday 15 March 2014 16:59:54 Kevin Ottens wrote:<br>
> > > Here are the different options, they're clearly not mutually exclusive.<br>
> > ><br>
> > > 1) Split Tier 4 in a Tier 4 and a Tier Deprecated :)<br>
> > > [...]<br>
> > > 2) Release the deprecated content as a separate product<br>
> > > [...]<br>
> > > 3) Roll all the deprecated modules into KDE4Support<br>
> > > [...]<br>
> > > 4) Announce the deprecated modules will only be released three times<br>
> > > [...]<br>
> > ><br>
> > > That's it for the four ideas to deal with the deprecated modules, now<br>
> > > let's find a working cocktail.<br>
> ><br>
> > So let's pick the following cocktail: 1, 2 and 4.<br>
> ><br>
> > That means we immediately move khtml and kde4support out of KDE<br>
> Frameworks<br>
> > (to be widely advertised) and into a KDE Porting Aids product (to be<br>
> > advertised only to existing KDE developers).<br>
> ><br>
> > Ben, I think you're going to hate me for that, but we learn as we<br>
> > progress... That means we're moving ASAP khtml and kde4support<br>
> > repositories out of the frameworks group of the projects tree into a new<br>
> > portingaids group.<br>
> ><br>
> > We'll also announce at beta time the second product, and that we aim for<br>
> > making only three releases out of it, coordinated with KDE Frameworks<br>
> > releases as to give people time to port away from it.<br>
> ><br>
> > Now, the last point... What else do we want to move from KDE Frameworks to<br>
> > KDE Porting Aids? Aleix and Aaron proposed the following content for KDE<br>
> > Porting Aids:<br>
> >  * kde4support (obvious);<br>
> >  * khtml (planned for a long time);<br>
> >  * kjs (because of khtml I gather);<br>
> >  * kjsembed (ditto);<br>
> >  * krunner (because of upcoming sprinter, and only one user anyway);<br>
> >  * kmediaplayer (unused AFAIK).<br>
> ><br>
> > I think that list makes sense. Is there anyone who couldn't sleep at night<br>
> > if those were in KDE Porting Aids?<br>
> ><br>
> > Regards.<br>
><br>
> _______________________________________________<br>
> Kde-frameworks-devel mailing list<br>
> <a href="mailto:Kde-frameworks-devel@kde.org">Kde-frameworks-devel@kde.org</a><br>
> <a href="https://mail.kde.org/mailman/listinfo/kde-frameworks-devel">https://mail.kde.org/mailman/listinfo/kde-frameworks-devel</a><br>
><br>
</p>