Policies/Commit Policy - Revision history

Bcooksley: Bcooksley moved page Policies/SVN Commit Policy to Policies/Commit Policy

2013-02-08T19:57:43Z

Bcooksley moved page Policies/SVN Commit Policy to Policies/Commit Policy

AnneW: /* Special keywords in SVN log messages */

2011-07-09T15:26:09Z

‎Special keywords in SVN log messages

Mpyne: Document the FIXED-IN keyword

2010-07-28T22:52:05Z

Document the FIXED-IN keyword

Josef: /* Respect commit policies set by the Release Plans */ monday bic policy

2009-12-07T09:55:48Z

‎Respect commit policies set by the Release Plans: monday bic policy

Toma: /* Special keywords in SVN log messages */

2009-06-26T21:43:40Z

‎Special keywords in SVN log messages

Toma: SVN_MERGE documented

2009-06-26T21:43:15Z

SVN_MERGE documented

Ossi: /* Make "atomic" commits */ clarification on atomic vs. changeset

2009-01-05T10:06:36Z

‎Make "atomic" commits: clarification on atomic vs. changeset

Ossi: /* Special keywords in SVN log messages */ keyword clarifications

2009-01-05T09:42:20Z

‎Special keywords in SVN log messages: keyword clarifications

Winterz: /* Test your changes before committing */

2008-08-16T20:16:56Z

‎Test your changes before committing

Winterz: spelling

2008-08-16T20:15:55Z

spelling

@@ Line 102: / Line 102: @@
 ** '''FIXED-IN:''' ''<version>''<br/>If the '''BUG''' keyword is used to close a bug, this keyword will update the bug's ''release version'' that the fix appears in. You can only select one version, so prefer the lowest release version that will actually have the fix.
 * '''CCBUG:''' ''<bugnumber>''<br/>CC's to the bugreport by sending mail to <bugnumber>@bugs.kde.org
-* '''CCMAIL:''' <email-address><br/>CC's to the given e-mail address.
+* '''CCMAIL:''' ''<email-address>''<br/>CC's to the given e-mail address.
 * '''GUI:'''<br/>Indicates a user visible change in the user interface. This is used to make the documentation team aware of such changes.

@@ Line 100: / Line 100: @@
 * '''FEATURE:''' [''<bugnumber>'']<br/>Marks the feature as implemented by CC'ing the commit message to <bugnumber>-done@bugs.kde.org. This keyword will also be used to automatically extract entries for the release changelog, so it makes sense to use it for new features even if you don't have a bugnumber for the feature.
 * '''BUG:''' ''<bugnumber>''<br/>Marks the bug as fixed by CC'ing the commit message to <bugnumber>-done@bugs.kde.org. This keyword will also be used to automatically extract entries for the release changelog.
 * '''CCBUG:''' ''<bugnumber>''<br/>CC's to the bugreport by sending mail to <bugnumber>@bugs.kde.org
 * '''CCMAIL:''' <email-address><br/>CC's to the given e-mail address.

← Older revision		Revision as of 09:55, 7 December 2009
Line 32:		Line 32:

	=== Respect commit policies set by the Release Plans ===		=== Respect commit policies set by the Release Plans ===
		+
		+	Among other things, it means that binary-incompatible changes (BIC) to unreleased APIs in trunk should only happen on Mondays.

	=== Respect other developer's code ===		=== Respect other developer's code ===

@@ Line 105: / Line 105: @@
 * '''SVN_SILENT'''<br/>Marks the commit message "silent" by adding "(silent)" to the subject of the mail to allow filtering out trivial commits. Use this tag carefully and only for really uninteresting, uncontroversial commits.
-* '''SVN_MERGE'''<br/>Special keyword for people that use the svnmerge script.
+* '''SVN_MERGE'''<br/>Special keyword for people that use the svnmerge script. Marks the commit message as being a merge commit by adding "(merge)" to the subject of the mail. This way receivers can filter out mails that are caused by merging the same patch from one branch to another branch. Reviews of those mails is usually not needed. This keyword filters out the endless property changes used by this script.
 Marks the commit message as being a merge commit by adding "(merge)" to the subject of the mail. This way receivers can filter out mails that are caused by merging the same patch from one branch to another branch. Reviews of those mails is usually not needed. This keyword filters out the endless property changes used by this script.
 == Contact ==

@@ Line 104: / Line 104: @@
 This keyword can appear anywhere on a line:
 * '''SVN_SILENT'''<br/>Marks the commit message "silent" by adding "(silent)" to the subject of the mail to allow filtering out trivial commits. Use this tag carefully and only for really uninteresting, uncontroversial commits.
 == Contact ==

@@ Line 80: / Line 80: @@
 SVN keywords like <tt>Id</tt> or <tt>Log</tt> cause unnecessary conflicts when merging branches and don't contain any information which wouldn't be available in the SVN repository anyway.
-=== Make "atomic" commits ===
+=== Commit complete changesets ===
-SVN has the ability to commit more than one file at a time. Therefore, please commit all related changes in multiple files, even if they span over multiple directories at the same time in the same commit. This way, you ensure that SVN stays in a compileable state before and after the commit.
+SVN has the ability to commit more than one file at a time. Therefore, please commit all related changes in multiple files, even if they span over multiple directories at the same time in the same commit. This way, you ensure that SVN stays in a compileable state before and after the commit, that the commit history (svn log) is more helpful and that the kde-commits mailing list is not flooded with useless mails.
 === Don't mix formatting changes with code changes ===

@@ Line 90: / Line 90: @@
 == Special keywords in SVN log messages ==
-When you commit changes to SVN you will be asked for a description of your commit. There are several special keywords defined that you can use in this description. These keywords are always uppercase and followed by a colon. Each keyword should be placed on a line of its own. The following keywords can be used.
+When you commit changes to SVN you will be asked for a description of your commit. There are several special keywords defined that you can use in this description. These keywords are always uppercase.
-* '''BUG:''' ''<bugnumber>''<br/>Marks the bug as closed by CC'ing the commit message to <bugnumber>-done@bugs.kde.org This keyword will also be used to automatically extract entries for the release changelog.
 * '''CCBUG:''' ''<bugnumber>''<br/>CC's to the bugreport by sending mail to <bugnumber>@bugs.kde.org
 * '''CCMAIL:''' <email-address><br/>CC's to the given e-mail address.
 * '''GUI:'''<br/>Indicates a user visible change in the user interface. This is used to make the documentation team aware of such changes.
 == Contact ==

@@ Line 16: / Line 16: @@
 Start the application affected by your change and make sure that the changed code behaves as desired.
-Run unit and regression tests, if available (<tt>make test</tt>).
+Run unit and regression tests, if available (KDE4: <tt>make test</tt>, KDE3: <tt>make check</tt>).
 === Double check what you commit ===

@@ Line 7: / Line 7: @@
 === Never commit code that doesn't compile ===
-Compile the code and correct all errors before committing. Make sure that newly added files are comitted. If they are missing your local compile will work fine but everybody else won't be able to compile.
+Compile the code and correct all errors before committing. Make sure that newly added files are committed. If they are missing your local compile will work fine but everybody else won't be able to compile.
 You certainly should make sure that the code compiles with your local setup. You should also consider what consequences your commit will have for compiling with the source directory being different from the build directory. It would also be nice if it would compile with the <tt>--enable-final</tt> option, but we don't explicitly support that.
@@ Line 39: / Line 39: @@
 === Announce changes in advance ===
-When you plan to make changes which affect a lot of different code in SVN, announce them on the mailing list in advance. For instance, changes in libraries might break other code even if they look trivial, e.g., because an application must also compile with older versions of the librariy for some reasons. By announcing the changes in advance, developers are prepared, and can express concerns before something gets broken.
+When you plan to make changes which affect a lot of different code in SVN, announce them on the mailing list in advance. For instance, changes in libraries might break other code even if they look trivial, e.g., because an application must also compile with older versions of the library for some reasons. By announcing the changes in advance, developers are prepared, and can express concerns before something gets broken.
 === Code review by other developers ===
 Don't commit changes to the public API of libraries without prior review by other developers. There are certain special requirements for the public APIs of the KDE libraries, e.g., source and binary compatibility issues. Changes to the public APIs affect many other KDE developers including third party developers, so requiring a review for these changes is intended to avoid problems for the users of the APIs and to improve the quality of the APIs.
-=== Take responsibilty for your commits ===
+=== Take responsibility for your commits ===
 If your commit breaks something or has side effects on other code, take the responsibility to fix or help fix the problems.
 === Don't commit code you don't understand ===
-Avoid things like "I don't know why it crashes, but when I do this, it does not crash anymore." or "I'm not completely sure if thats right, but at least it works for me.".
+Avoid things like "I don't know why it crashes, but when I do this, it does not crash anymore." or "I'm not completely sure if that's right, but at least it works for me.".
 If you don't find a solution to a problem, discuss it with other developers.
@@ Line 84: / Line 84: @@
 === Don't mix formatting changes with code changes ===
-Changing formatting like indenting or white spaces blows up the diff, so that it is hard to find code changes if they are mixed with reindenting commits or similar things when looking at the logs and diffs later. Committing formatting changes separately solves this problem.
+Changing formatting like indenting or white spaces blows up the diff, so that it is hard to find code changes if they are mixed with re-indenting commits or similar things when looking at the logs and diffs later. Committing formatting changes separately solves this problem.
 === GUI Changes ===