KDE Frameworks: Moving toward 5.0 final and Governance
ervin at kde.org
Mon Jan 6 06:52:50 GMT 2014
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?
(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:
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
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:
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.
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud supporter of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel