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

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to