Rules to be approved as part of KDE Frameworks

Hello lists,

As, Sebas pointed out we've been meeting here to work on plans to improve our
frameworks offering leading to the decision of leaving the current "kdelibs
model" behind and prepare for a more modular suite named KDE Frameworks. If
you didn't read his email yet, please do so before going back to this email.

Don't be afraid, this email is likely to be shorter than the previous one. ;-)
It might also be easier to understand the content of this email if you first
read my previous email about the KDE Frameworks, although that's probably not

Here, we'll be dealing with what will be part of the KDE Frameworks, the
answer is two fold really and depends if we're talking about a library or
smaller code contributions.

The content is mostly common sense, it is about trying to make explicit the
good practices already in place in our community. This email is a draft of a
future wiki page to complete our policies (or to be integrated in the existing
policy pages).

= Library Quality Criteria =
Any library should meet the quality criteria to get KDE Frameworks stamps (as
described in my previous email). The criteria in question are the following:
* the code should follow our license policy;
* the code should follow a consistent coding standard (it is encouraged to
follow the current kdelibs standard throughout our frameworks but is not
* the framework should have a scope (no dumping ground);
* the code should meet all the dependency criteria of its intended Tier and
Framework Type;
* the library should maintain binary compatibility until the next major
release of KDE Frameworks;
* the code should be unit tested with a "sufficient" coverage (the exact
number still needs to be determined);
* the developers of the library should comply to the "code contribution
quality criteria" described below.

= Code Contribution Quality Criteria =
Since we can expect all the libraries, old and new, to get code contributions,
the following rules will be in effect for the "stamped" frameworks:
* the "two apps rule" still applies and should be considered like a minimum;
* the added code should comply to the dependency policy for the library Tier
and Framework Type;
* the added code should fit in the library scope;
* the contributor has to commit to maintaining the contributed code or find
someone to take it over (social contract);
* all new features will be developed using the recommended git workflow
(pending publication; Cornelius is working on that one);
* automated tests should be provided in the same commit as a fix;
* commits meant to hit the master branch (bugfixes or merges) should contain
a "Reviewed by" or "REVIEW:" in their commit log.

= Conclusion =
Those rules might seem like a strong departure from what we're used to. On the
other hand, if you look at them closely, they are merely making explicit
changes to our habits which already happened a while ago during the Qt 3 to Qt
4 port. We're trying here to make them systematic to get even better
frameworks than before.



Re: Rules to be approved as part of KDE Frameworks

By Maksim Orlovich at 06/06/2011 - 18:41

These two things don't really go well together now, do they?

Re: Rules to be approved as part of KDE Frameworks

By Aaron J. Seigo at 06/06/2011 - 19:00

On Monday, June 6, 2011 19:41:15 Maksim Orlovich wrote:
a documented git workflow is new, but needed. ditto with the tier/type

the other items are as described in the second paragraph, however.

is this problematic for you in some way? if so, can you clarify what that
problem is so that we may understand and be able to address it?

Re: Rules to be approved as part of KDE Frameworks

By Alexander Neundorf at 06/07/2011 - 03:13

On Tuesday, June 07, 2011 02:00:20 AM Aaron J. Seigo wrote:
Yes, yes, yes. 100 %. We really need that. For git newbies (like me) and to
avoid total chaos. And so that it stays possible to contribute to any KDE
projects without having to figure out for each single project how they prefer
to use git and branches etc.


Re: Rules to be approved as part of KDE Frameworks

By Tom Albers at 06/07/2011 - 03:11

That's not what is happening. It's a workflow for the frameworks, the rest of KDE is invited to follow. So you still have to find out for each single project how they prefer to use git and branches. (afaics)


Re: Rules to be approved as part of KDE Frameworks

By Aaron J. Seigo at 06/07/2011 - 03:42

On Tuesday, June 7, 2011 08:11:59 Tom Albers wrote:
we're between a rock and a hard place.

if we just say "You will all use this workflow starting NOW!" people will
complain that they have not been involved in the process and are being told
how to work. fair enough.

if we say "Here's our recommendation and Frameworks and Workspaces will be
using it, we recommend all other projects in KDE git also move to this
workflow." then others will note that it still isn't consistent because we
aren't mandating it.


the workflow that will be proposed (i need to find Cornelius and get him to
press the send key on that email! :) should be palatable for projects of all
sizes. the workflow we will be using for Frameworks is not very complex, but
it is more complex than needed for smaller projects (e.g. single apps with 1-2
developers) and so there is a small set (3 iirc) of workflow suggestions
modeled on the one we will use for Frameworks but with some intermediary steps
in the workflow taken out.

once this proposal makes its way to k-c-d, i will be helping to get broad
adoption of it throughout KDE and then we can have the best of both worlds: no
project being forced to work a certain way without having been involved in the
discussion, but still have consistency.

it's a longer road, but one that i think is more fair and respectful of
others. it would indeed be far easier, in terms of effort required, to just
mandate something. probably wouldn't have great results though. :)

Re: Rules to be approved as part of KDE Frameworks

By Alexander Neundorf at 06/07/2011 - 03:32

On Tuesday, June 07, 2011 10:11:59 AM Tom Albers wrote:
I'd make that "the rest of KDE SC is strongly recommended to follow".
For me, as having to work everywhere a bit from time to time, it is not
manageble to figure out for each of the 50 or 100 repositories how these guys
prefer to use git.
This could be a thing which decides whether something wants to be in KDE SC or