KDE Frameworks: Moving toward 5.0 final and Governance

[Kevin Ottens]

Hello all,

Now that TP1 is almost out of the door, it is time to move toward the final 
release and put in place the governance of KDE Frameworks. It is a very large 
and multi-faceted product, so we will need people with longer term commitment 
if we want it to shine on release day.

## What's left for a final?

Short answer:
http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation
(Tasks for Final Release section)

To get there, we'll move into a monthly release schedule:
 * Alpha 1, February 1st;
 * Alpha 2, March 1st;
 * Beta 1, April 1st;
 * Beta 2, May 1st;
 * Final, June 1st;

Between beta 2 and final we'll insert release candidates following a shorter 
weekly cycle to nail down the remaining minor issues.

We don't expect the source code to drastically change between now and final. 
At least, short term, we shouldn't see code flying from one framework to 
another one. As you can see most of the tasks revolve around the tooling next 
to the code (CI, buildsystem, apidox, etc.)... Still there's one big elephant 
missing there as it's not really something actionable: code quality.

I urge everyone, and in particular people volunteering to maintain a 
framework, to do a pass of review of our code base and APIs to modernize them 
when appropriate. It is a very big task, and in no way can be coordinated in 
the way we've been working so far. Maintainers will be a crucial part of a 
successful code quality review, which leads me to the governance...

## Frameworks Governance?

I used to say that the maintenance model of kdelibs was "David Faure by 
default". It's great to have someone like David around, but at the same time 
it's delusional and dangerous to think that he'll always be able to save the 
day. This model has to stop now. And hopefully having smaller packages will 
help people to feel responsible for their modules.

The current list of modules is there:
http://community.kde.org/Frameworks/List

As you can see there's quite some holes in the table, and quite a few entries 
marked unmaintained. KDE Frameworks as a set of technologies will only be 
taken seriously if we get something more complete there. I urge everyone with 
an interest in KDE Frameworks to step up, look at that list and volunteer to 
maintain a framework. If you volunteer, know that the following will be 
expected from you:
 1) Complete in the table the information regarding your framework;
 2) Do an API review and modernization pass in your framework (possibly with 
the help of others);
 3) Stick around for a long period to act as maintainer (see below for 
details);
 4) The day you want to move away from your duties, do so responsibly, don't 
just disappear, make sure you pass the torch to someone else (probably the 
most important point in the list!).

### Governance at the framework level

At the framework level, the maintainer will be responsible for the quality of 
the code produced. In particular he'll have to make sure the different 
policies in place are respected inside his module:
http://community.kde.org/Frameworks/Policies

In practice that means that the day to day activities (and minimum required 
from a maintainer) will be to:
 * Review others' code;
 * Make sure that his module is always in a releasable state (in particular 
the CI is always green);
 * Decide on the direction his module is going in case of conflicts.

Note that we're not expecting maintainers to have ideas on features or on a 
direction to give to the module (of course they can, it's just not required). 
That means it is fine to be more of the reactive type of maintainer if you 
want to, letting contributors propose directions and trying to move the lines, 
you just have to pick one in case of conflicting goals.

### Governance at the KDE Frameworks level

Because of the structure of KDE Frameworks (which is already more than 50 
modules and that number will likely increase again for 5.1), we also need to 
have a body that looks at the overall coherency of the whole. My goal here is 
not to create a huge bureaucracy, so we'll start as small as possible and grow 
if the need arises.

To bootstrap this body, we'll reuse something as close to the status quo as 
possible. In our case that means that the KDE Frameworks Release Team will 
start with David Faure and myself.

The responsibilities of that team will be the following:
 * Beating the drum on the product rhythms (mostly the release schedule, but 
also interim meetings);
 * Defining the content of the overall product;
 * Defining the rules of work.
All of that in the usual KDE fashion, that is by collecting information from 
the trenches (that is the maintainers and contributors).

David will likely focus more on participating in the day to day activities for 
the release execution. I will likely focus more on facilitating the creation 
of the product definition, release schedule and policies. That should pretty 
much reflect what we've been both doing the past few weeks, not taking 
decisions in our hands but making sure we end up with decisions when needed.

Thanks for your attention if you read that far.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter 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/20140106/f700e6f6/attachment.sig>