[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]