From kde-commits Sat Jan 31 20:42:25 2015 From: Yury G. Kudryashov Date: Sat, 31 Jan 2015 20:42:25 +0000 To: kde-commits Subject: [kate] /: Move commit policy to techbase Message-Id: X-MARC-Message: https://marc.info/?l=kde-commits&m=142273695523321 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 @@ -=3D=3D THIS IS A DRAFT =3D=3D - -This document is a work in progress, and may be incomplete and / or inaccu= rate. - -Please help improve it! - -=3D=3D About this document =3D=3D - So you want to participate in developing kate? Great! The project is alway= s in need of helping hands. = -However, trying to help, and being helpful is not always the same thing. T= herefore, we would like to ask -you to read through this document, '''before''' you start comitting to thi= s 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. '''Co= mmon 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. - -=3D=3D General rules =3D=3D - -# If you have the slightest doubt, '''ask'''! -#* This is probably the most important rule. Communicate, discuss, ask que= stions. -#* For small technical questions, the fatest way to get an answer is typic= ally 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@k= de.org . In fact, if you plan to contribute more than just once, it is high= ly 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/Schedul= es 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=3Dkwrite-devel&r=3D1&w=3D2 mailing list archive],= to see if there may be any reasons against committing certain changes at t= hat 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 permit= ted. But please make sure you have checked and understood the applicable te= rms, 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, probabl= y others have noted it before, too. If you think the feature you're about t= o implement is a must have, then others might have had the same idea. Pleas= e 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 ha= s been fixed / feature committed, in order to keep bug database managable. = Taking some time for bookkeeping is an important part of developing in a co= mmunity project. - -=3D=3D Coding style =3D=3D - -# Respect coding conventions and style, kate.git follows the kdelibs codin= g style: http://techbase.kde.org/Policies/Kdelibs_Coding_Style -#* Don't just write in your personal style. Tastes differ, and if we mix a= ll sorts of styles, the code just gets harder to read. -#* In general, please try to follow the coding style of the surrounding co= de. -# Use four spaces to indent. -# Whenever possible use title case includes without directory, e.g. '''#in= clude ''' - -=3D=3D Kate specific rules =3D=3D - -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. - -=3D=3D=3D kate / kwrite =3D=3D=3D - -These directories hold code that is specific to the stand-alone applicatio= ns 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 kw= rite, 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 t= hought about, or use features, which even -core contributors may not be aware of. Please be careful that you don't br= eak 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 whethe= r they be limited to kate, or whether they -should be implemented in the kate part, in order to make them accessible t= o all applications using katepart. As a -generic rule of thumb: If the feature (or a similar feature) could be usef= ul in kwrite, then it should probably = -go into katepart. If the feature might be useful in applications such as k= develop, 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