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