Hello lists, First of all, I'd like to apologize to everyone here as (so far) I didn't live up to previous commitments made. Indeed, shortly after Platform 11, I identified that the road the KDE Platform to the KDE Frameworks would require focused stewardship in a way we didn't need before. I volunteered to do the job, but due to my life outside of KDE Frameworks, I felt short on the organization and communication which needed to be put in place. That is partly why the effort is perceived to be stagnating, is not moving as quickly as it could, why kde-frameworks-devel never got announced properly (understandably leading to some conspiracy theories), and why everyone is wondering when? (although I'm not going to provide an answer to that).
Now it turns out the planets are almost aligned correctly now for me to resume the efforts and as such I'm back to work on KDE Frameworks. While I will be doing some coding on frameworks (I'm an addict!), the main way I will be contributing is to tackle the general stewardship and communication of KDE frameworks. Now, let me introduce the two major assets which got created to organize the KDE Frameworks development. = kde-frameworks-de...@kde.org At last, we're announcing properly the creation of kde-frameworks- de...@kde.org! This list was created mainly to drive the efforts of the creation of KDE Frameworks. A separate channel of communication was chosen to avoid some of the signal/noise shortcomings of kde-core-devel, can't really be denied... But it is also here to avoid disrupting kde-core-devel day to day operation regarding kdelibs. For now, it should really be seen as similar in its birth to our release-team list. Except that instead of cross-teams release topics, it's right now focusing on KDE Frameworks specific coordination and organization for its first release. It is what it has been used for so far and not more. Which means people are sharing tips or seeking solutions when some dependency change is needed. Those tips will get over time consolidated in the community wiki (more on that below). Will kde-frameworks-devel stay around after KDE Frameworks 5.0 is released? Hard to tell for now, we will see how the customs evolved around the time of release and decide based on that. My gut feeling is that long term kde-core- devel will stay around for patch reviews and day to day feature level operations and interaction with the broader community (where plasma meet dolphin for instance), while kde-frameworks-devel will be more about longer term planning and design across the whole KDE Frameworks offering. But again, that's pure conjecture at that point and we shouldn't set it in stone. Both are needed for now, let's see how it evolves. For now I'm trying to make sure the important information will be relayed to both mailing lists, which means in the short term I'll simply cross-post (first example right now), and over time we'll move toward a bi-monthly or weekly digest of what's going on in KDE Frameworks to be sent on kde-core-devel. = community.kde.org/Frameworks Let me introduce now what I consider the most important resource to the service of the community to reach the KDE Frameworks 5.0 landmark: the Frameworks area in the community.kde.org wiki! Its main purpose is to give an idea of the on-going efforts in KDE Frameworks land. It's very oriented into communicating and driving work, it also contains the policies in place. For now because of KDE Frameworks status it focuses almost exclusively on the transversal issues, but at some point we'll also open per-framework sections. If you look at the wiki right now you will see only three transversal efforts (named epics later on) which are active, they are the critical ones for a KDE Frameworks 5.0 release, none of the other ones are scheduled yet. They're nice to have but not essential to a release. Also you will see that the intent of this section is not to focus exclusively on "producing libraries", I want a whole product approach to KDE Frameworks because that's one of the clear outcomes of the Platform 11 discussions which touched more than just kdelibs in the end (leading to the creation of inqlude, discussions on a broader developer story, etc.). So KDE Frameworks as a product will be about more than just library development and API design even if it is a very important aspect of it obviously. Of course, it is supposed to be a living document, it's still young and probably not complete yet. That said it already helped a lot into uncovering some precious information which were buried in meeting notes or giving a clearer picture on where we stand and what we need to reach our goals. In fact, I'd like to point out the obvious result of collecting data in the wiki: we need more hands to help moving things forward code-wise, we also need more people volunteering to act as framework maintainers. One of the consequences of KDE Frameworks 5.0 is that it will be easier to act as such because of the more modular nature (it's one case of technical change impacting the social structure). It makes obvious the lack of responsibility in most of kdecore, kdeui and a few others libraries which have instead the "David Faure as fallback maintainer" mechanism which we shouldn't rely on anymore. You want fame and help the community at large? Here is your chance! It can be a tough job, but very rewarding in my opinion, most of the KDE products use kdelibs and will use the KDE Frameworks in the future. = Now at that point some of you might still wonder about when will we have a KDE Frameworks 5.0? My reply would be that a) it will be after Qt 5.0, so first ask the Qt project when they will release and b) when it is ready. :-) Now jokes aside, there's some things we cannot avoid before making a 5.0 release, and those are the three epics I selected for this milestone. Still, I strongly believe in regular releases and I'll push for them to happen as soon as we're in a position to have them, they will be alphas for a while of course. The exact rythm is something I don't want to force on the Frameworks maintainers, and I hope to build consensus on that during tomorrow's IRC meeting (which results will be relayed on mailing-lists). Thanks for your attention, now let's focus on preparing a great KDE Frameworks 5.0 release! Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.