Projects/KAuth/Polkit-KDE development guidelines: Difference between revisions
No edit summary |
|
(No difference)
|
Latest revision as of 23:41, 26 March 2011
This page serves as a guideline for developing and contributing to the polkit-KDE project.
Interested repositories
This guidelines are valid for:
- Polkit-Qt-1
- KDE's polkit authentication agent
- KDE's polkit configuration modules
- KAuth components (kdelibs/kdecore/kauth)
We will assume all of the repositories are using git: this is not obviously true for KAuth - for which you can skip the branch/merge phase described below.
How to contribute
Guidelines
IMPORTANT: Those guidelines apply to project managers theirselves as well!
Contribution to these projects should happen by following those very simple guidelines:
- Trivial patches, typo fixes, etc (you get the point) may be committed straight into master without authorization - but be sure to notify (CCMAIL is your friend) at least one of the project managers.
- Anything else should be submitted for review to ReviewBoard, and get the approval of at least one of the project managers.
Workflow
You should always prepare your patches in a separate branch. Once your branch is ready, post your review to ReviewBoard, where it will eventually be accepted.
Once accepted, if you don't have a KDE identity account with developer access, use git-format-patch to generate your set of commits and send it to one of the project managers (possibly the one who approved your changes) so that he can merge it.
If you have an account instead, do the following (on an updated git tree):
git checkout master git reset --hard origin/master # Where origin should be the remote pointing to the upstream repository git checkout your-branch-to-be-integrated git rebase master git checkout master git merge --no-ff git commit --amend
This command assures that your branch is fully rebased on top of the upstream master, and creates a merge commit. Once you enter the last command, you will be prompted to edit the merge commit's message. Add "Reviewed-By: Name Surname <mail@address>" for each one of the project managers who reviewed and approved your patch. After doing that, push your changes to master.
Coding style policy
KDELibs Coding style (Policies/Kdelibs_Coding_Style) should be used.