From kde-core-devel Mon Jan 06 06:52:50 2014 From: Kevin Ottens Date: Mon, 06 Jan 2014 06:52:50 +0000 To: kde-core-devel Subject: KDE Frameworks: Moving toward 5.0 final and Governance Message-Id: <3082524.8z6FG6dxrz () wintermute> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=138899121007825 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart1700754.BCACFGOxk3" --nextPart1700754.BCACFGOxk3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hello all, Now that TP1 is almost out of the door, it is time to move toward the f= inal=20 release and put in place the governance of KDE Frameworks. It is a very= large=20 and multi-faceted product, so we will need people with longer term comm= itment=20 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 sh= orter=20 weekly cycle to nail down the remaining minor issues. We don't expect the source code to drastically change between now and f= inal.=20 At least, short term, we shouldn't see code flying from one framework t= o=20 another one. As you can see most of the tasks revolve around the toolin= g next=20 to the code (CI, buildsystem, apidox, etc.)... Still there's one big el= ephant=20 missing there as it's not really something actionable: code quality. I urge everyone, and in particular people volunteering to maintain a=20= framework, to do a pass of review of our code base and APIs to moderniz= e them=20 when appropriate. It is a very big task, and in no way can be coordinat= ed in=20 the way we've been working so far. Maintainers will be a crucial part o= f a=20 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= =20 default". It's great to have someone like David around, but at the same= time=20 it's delusional and dangerous to think that he'll always be able to sav= e the=20 day. This model has to stop now. And hopefully having smaller packages = will=20 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 e= ntries=20 marked unmaintained. KDE Frameworks as a set of technologies will only = be=20 taken seriously if we get something more complete there. I urge everyon= e with=20 an interest in KDE Frameworks to step up, look at that list and volunte= er to=20 maintain a framework. If you volunteer, know that the following will be= =20 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=20 the help of others); 3) Stick around for a long period to act as maintainer (see below for=20= details); 4) The day you want to move away from your duties, do so responsibly, = don't=20 just disappear, make sure you pass the torch to someone else (probably = the=20 most important point in the list!). ### Governance at the framework level At the framework level, the maintainer will be responsible for the qual= ity of=20 the code produced. In particular he'll have to make sure the different=20= 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 requ= ired=20 from=20a maintainer) will be to: * Review others' code; * Make sure that his module is always in a releasable state (in partic= ular=20 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=20 direction to give to the module (of course they can, it's just not requ= ired).=20 That means it is fine to be more of the reactive type of maintainer if = you=20 want to, letting contributors propose directions and trying to move the= lines,=20 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=20 modules and that number will likely increase again for 5.1), we also ne= ed to=20 have a body that looks at the overall coherency of the whole. My goal h= ere is=20 not to create a huge bureaucracy, so we'll start as small as possible a= nd grow=20 if the need arises. To bootstrap this body, we'll reuse something as close to the status qu= o as=20 possible. In our case that means that the KDE Frameworks Release Team w= ill=20 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=20 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=20 the trenches (that is the maintainers and contributors). David will likely focus more on participating in the day to day activit= ies for=20 the release execution. I will likely focus more on facilitating the cre= ation=20 of the product definition, release schedule and policies. That should p= retty=20 much reflect what we've been both doing the past few weeks, not taking=20= decisions in our hands but making sure we end up with decisions when ne= eded. Thanks for your attention if you read that far. Regards. =2D-=20 K=E9vin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com --nextPart1700754.BCACFGOxk3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEABECAAYFAlLKUsIACgkQB0u7y43syeIrqACfVGhLAryBQR0fmYqZq9gAMMkZ 8A0An2WggYI6/wyO6Nj8lotAjm2qk0o8 =EU1f -----END PGP SIGNATURE----- --nextPart1700754.BCACFGOxk3--