The Frameworks: Reloaded

Sat Dec 3 20:31:29 UTC 2011

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-devel at kde.org =
At last, we're announcing properly the creation of kde-frameworks-
devel at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20111203/036b98b8/attachment.sig>