[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    [kate] /: Move commit policy to techbase
From:       Yury G. Kudryashov <urkud () urkud ! name>
Date:       2015-01-31 20:42:25
Message-ID: E1YHes5-0002w8-Oj () scm ! kde ! org
[Download RAW message or body]

Git commit b27501c1c7da151dab6edad5f497fad685a986ff by Yury G. Kudryashov.
Committed on 26/01/2015 at 20:48.
Pushed by kudryashov into branch 'master'.

Move commit policy to techbase

It is much easier to read rendered wiki markup than the source file.

REVIEW: 122265

M  +2    -65   CommitPolicy.txt

http://commits.kde.org/kate/b27501c1c7da151dab6edad5f497fad685a986ff

diff --git a/CommitPolicy.txt b/CommitPolicy.txt
index 05ff82d..1a8b70b 100644
--- a/CommitPolicy.txt
+++ b/CommitPolicy.txt
@@ -1,67 +1,4 @@
-== THIS IS A DRAFT ==
-
-This document is a work in progress, and may be incomplete and / or inaccurate.
-
-Please help improve it!
-
-== About this document ==
-
 So you want to participate in developing kate? Great! The project is always in need of helping hands.
 
-However, trying to help, and being helpful is not always the same thing. Therefore, we would like to ask
-you to read through this document, '''before''' you start comitting to this repository. We try to keep
-this text short, and limit it to some of the most important pitfalls, only, and we will focus mostly on
-issues which are specific to kate, as opposed to generic guidelines. '''Common sense applies.'''
-
-In writing this document, we will assume that you have developer access to the repository. However, if
-you don't, the same basic rules apply for sending patches, too.
-
-== General rules ==
-
-# If you have the slightest doubt, '''ask'''!
-#* This is probably the most important rule. Communicate, discuss, ask questions.
-#* For small technical questions, the fatest way to get an answer is typically IRC \
(irc://irc.kde.org/kate for the kate specific channel; often irc://irc.kde.org/kde-devel is also a good \
                place to ask).
-#* For questions that may need a broader discussion, or some time to think about, the mailing list is \
generally the best place to ask: kwrite-devel@kde.org . In fact, if you plan to contribute more than just \
                once, it is highly recommended that you subscribe.
-#* For feedback on a concrete patch, reviewboard.kde.org is suited, best.
-# Understand what you are doing.
-#* Do not commit code that you don't understand, even if it appears to fix problems. '''Ask''' instead \
                (see above).
-# Test you code.
-#* Test your code to make sure it really does what you think it does. Then test that it doesn't break \
                anything. Then test again.
-# Respect schedules and agreements.
-#* Make sure you are aware of the current [http://techbase.kde.org/Schedules Release Schedules], and the \
                associated freezes in the different branches.
-#* Generally it is a good idea to have a look at the last few weeks of the \
[http://lists.kde.org/?l=kwrite-devel&r=1&w=2 mailing list archive], to see if there may be any reasons \
                against committing certain changes at that time.
-#* If in any doubt: Ask.
-# Respect copyright and licences.
-#* In the open source world, a lot of copying and re-use of code is permitted. But please make sure you \
                have checked and understood the applicable terms, in each case.
-#* If in any doubt: Ask.
-# Use bugs.kde.org
-#* If the bug you are about to fix has been annoying you for ages, probably others have noted it before, \
too. If you think the feature you're about to implement is a must have, then others might have had the \
same idea. Please be sure to check bugs.kde.org for existing reports / requests. This might contain \
important considerations that you did not think about, yet. And of course it is important to close the \
corresponding reports after the bug has been fixed / feature committed, in order to keep bug database \
                managable. Taking some time for bookkeeping is an important part of developing in a \
                community project.
-
-== Coding style ==
-
-# Respect coding conventions and style, kate.git follows the kdelibs coding style: \
                http://techbase.kde.org/Policies/Kdelibs_Coding_Style
-#* Don't just write in your personal style. Tastes differ, and if we mix all sorts of styles, the code \
                just gets harder to read.
-#* In general, please try to follow the coding style of the surrounding code.
-# Use four spaces to indent.
-# Whenever possible use title case includes without directory, e.g. '''#include <QLabel>'''
-
-== Kate specific rules ==
-
-The main sub-directories of this repository are "kate" and "kwrite". Very
-differnt guidelines apply to these, so make sure you understand what is or is not allowed in each \
                sub-project.
-
-=== kate / kwrite ===
-
-These directories hold code that is specific to the stand-alone applications kate and kwrite. As such it \
                is
-application code, and this means that, generally, there is no need to care about source or binary \
                compatibility.
-Changes in this directory do not affect applications other than kate or kwrite, and thus they are \
                ''relatively''
-safe. However, please be aware that both kate and kwrite are productivity tools, used extensively by a \
                large userbase.
-Often, these users will use kate/kwrite in ways that you have never even thought about, or use features, \
                which even
-core contributors may not be aware of. Please be careful that you don't break existing features and \
                workflows, unless
-you have very good reason to do so. If in any doubt: Ask.
-
-When implementing new features, please take a moment to think about whether they be limited to kate, or \
                whether they
-should be implemented in the kate part, in order to make them accessible to all applications using \
                katepart. As a
-generic rule of thumb: If the feature (or a similar feature) could be useful in kwrite, then it should \
                probably 
-go into katepart. If the feature might be useful in applications such as kdevelop, kile, quanta, rkward, \
                etc. then it
-should probably be implemented in katepart. If in any doubt: Ask.
+However, before you start comitting to this repository, read
+https://techbase.kde.org/Projects/Kate/Commit_Policy
\ No newline at end of file


[prev in list] [next in list] [prev in thread] [next in thread]