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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
