Reply to comment

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.