Rules to be approved as part of KDE Frameworks

[Kevin Ottens]

Hello lists,

<disclaimer>
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.
</disclaimer>

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 
mandatory.

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 
mandatory);
 * 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.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110607/41a7bc26/attachment.sig>