Main Page | Recent changes | Edit this page | Page history Printable version | Disclaimers | Privacy policy

Not logged in Log in | Help

Development Policy

From KDevelop

Contents 1 The KDevelop Development Policy 1.1 The purpose of this document 1.2 CVS Commit Policy 1.2.1 What is necessary to get a CVS account and become KDevelop developer 1.2.2 Commit Power Level 1.2.2.1 CPL=0 1.2.2.2 CPL=1 1.2.2.3 CPL=2 1.2.2.4 CPL=3 1.2.3 CPL Assignment 1.2.4 CPL Verification 1.3 Rights and Duties of Developers 1.3.1 Maintaining a KDevelop plugin 1.3.1.1 Author and Maintainer 1.3.1.2 Transferring Maintainer Rights 1.3.1.3 When Plugin Becomes Unmaintained 1.3.1.4 Why Plugin Can Be Considered As Unmaintained 1.3.1.5 Plugin Maintainer Rights 1.3.1.6 Plugin Maintainer Duties

[edit] The KDevelop Development Policy

[edit] The purpose of this document

This document covers common questions of KDevelop project management such as:

• cvs commit policy
• rights and duties of developers
• organization of development process

[edit] CVS Commit Policy

[edit] What is necessary to get a CVS account and become KDevelop developer

After having a set of approved and committed patches to KDevelop source code a developer can ask for KDE CVS account. Steps to get KDE CVS account:

• read the join the team page
• get an email from one of KDevelop maintainers with an invitation to the KDevelop team;
• write email to sysadmin@kde.org asking for KDE CVS account with an email from KDevelop maintainer attached.

Any developer with KDE CVS account is welcome to join KDevelop team and proceed with development according to commit power levels (see below).

[edit] Commit Power Level

For each directory in KDevelop cvs the Commit Power Level (CPL) can be assigned.

[edit] CPL=0

By default, directories in cvs have CPL=0 which indicate that each KDE (KDevelop) developer with KDE CVS account is allowed to commit without any notice. Work on new features can be started without notice. Exception: when KDevelop CVS is in "deep freeze" (after RC1 is released) CPL=0 works equally to CPL=1.

[edit] CPL=1

Each KDE (KDevelop) developer with KDE CVS account is allowed to commit after maintainer confirmation in kdevelop-devel mailing list or #kdevelop irc channel. Work on new features can be started without notice. This level is implied for directories with CPL=0 during CVS "deep freeze" but in this case new features are not allowed.

[edit] CPL=2

Each KDE (KDevelop) developer with KDE CVS account is allowed to commit after maintainer confirmation in kdevelop-devel mailing list. Work on new features should be started only after they are announced and acknowledged in kdevelop-devel mailing list.

[edit] CPL=3

Each KDE (KDevelop) developer with KDE CVS account is allowed to commit after maintainer confirmation in kdevelop-devel mailing list. Any work (modifications, new features) should be started only after it is announced and acknowledged in kdevelop-devel mailing list.

[edit] CPL Assignment

CPL is assigned by KDevelop maintainers. Each maintainer should approve CPL change in order to proceed the change. List of current CPL for KDevelop should be kept in "Current CPL for KDevelop" (CCFK) document. Only directories with CPL > 0 are listed in CCFK document. Also CPL is not recursive - subdirectories have either CPL=0 (default) or other CPL as stated in the CCFK document. New directories in CVS have CPL=0 by default. CPL from parent directory is not inherited unless inheritance is stated. CCFK document should have not only a list of directories with their CPL's but also reasons why that level was set.

[edit] CPL Verification

KDevelop maintainers are obliged to verify the conformance of each commit to CPL. Non-conformant commits should be reverted by one of the maintainers.

[edit] Rights and Duties of Developers

[edit] Maintaining a KDevelop plugin

[edit] Author and Maintainer

Author of KDevelop plugin which resides in KDevelop CVS is automatically considered as a maintainer of that plugin. All rights and duties are automatically applied to the author.

[edit] Transferring Maintainer Rights

At any time maintainership can be transferred to another person.

[edit] When Plugin Becomes Unmaintained

Unmaintained KDevelop plugin is a subject to removing from KDevelop CVS. KDevelop maintainer has the right to assign maintainership of unmaintained plugin to another developer if this plugin is considered as important part of KDevelop project.

[edit] Why Plugin Can Be Considered As Unmaintained

Plugin is considered to be unmaintained if it does not compile/work/has important unfinished functionality at the time of preparing beta 2 release of next KDevelop version and no reasonable amount of work has been done on it since first alpha release.

[edit] Plugin Maintainer Rights

Maintainer of a plugin has the right of reverting any modification to a plugin which:

• breaks important functionality;
• adds redundant functionality;
• can not be a part of a plugin (does not fit).

Developer which code was reverted has the right to ask KDevelop maintainer about appellation.

[edit] Plugin Maintainer Duties

Plugin maintainer is obliged to keep plugin:

• compilable;
• working (all functionality should work at the time of beta2 release of next KDevelop version).

Edit this page | Discuss this page | Page history | What links here | Related changes Main Page | About KDevelop | Recent changes |   This page has been accessed 3,942 times. This page was last modified 19:19, 2 June 2005. Content is available under GNU Free Documentation License 1.2.