Contribute/Send Patches - Revision history

Gallaecio: /* New Files */

2012-11-25T10:58:59Z

‎New Files

AnneW at 19:00, 12 July 2012

2012-07-12T19:00:54Z

Jstaniek: /* Preparing The Email */

2011-12-02T22:45:56Z

‎Preparing The Email

Odysseus: /* Reviewboard */

2011-03-18T11:51:01Z

‎Reviewboard

Odysseus: /* How To Share the Patch? */

2011-03-18T11:50:06Z

‎How To Share the Patch?

Odysseus: /* How To Share the Patch? */

2011-03-18T11:49:56Z

‎How To Share the Patch?

Odysseus: /* Reviewboard */

2011-03-18T11:47:43Z

‎Reviewboard

Odysseus: /* Reviewboard */

2011-03-18T11:47:10Z

‎Reviewboard

TMG: /* Reviewboard */ add link to Git instructions

2011-02-25T11:47:42Z

‎Reviewboard: add link to Git instructions

Cosoleto: fix 404

2010-04-14T16:32:46Z

fix 404

← Older revision		Revision as of 10:58, 25 November 2012
Line 64:		Line 64:

	Note that if you do '''svn revert''', for example, the files you created will NOT be deleted by svn - but svn will no longer care about them (so they won't show up when you do '''svn diff''', for example). You will have to '''rm''' them manually.		Note that if you do '''svn revert''', for example, the files you created will NOT be deleted by svn - but svn will no longer care about them (so they won't show up when you do '''svn diff''', for example). You will have to '''rm''' them manually.
−
−	~~(TODO: are there any other issues with adding new files if you don't have commit access?)~~

	== How To Share the Patch? ==		== How To Share the Patch? ==

← Older revision		Revision as of 19:00, 12 July 2012
Line 1:		Line 1:
−	~~{{Template:I18n/Language Navigation Bar\|Contribute/Send Patches}}~~
	This tutorial shows how to send modifications of code in the right way: '''by using patches'''.		This tutorial shows how to send modifications of code in the right way: '''by using patches'''.

@@ Line 122: / Line 122: @@
 Now you are ready to write the rest of the email. Please think of a title that matches your patch. (Think of having to find it again in [http://lists.kde.org the archives] in a few months or even years.) A good habit is to precede the title by <nowiki>[PATCH]</nowiki>. So for example a title could be <nowiki>[PATCH] Fix backup files</nowiki>.
-As for the body of the email, please tell to which file or directory your patch applies. For example for a file:
+As for the body of the email, please tell to which file or directory your patch applies. For example for a file: ''The attached patch applies to the file words/part/KWDocument.cpp'' or for a directory: ''The attached patch applies to the directory calligra/words''. This help the developers to have an overview of which code has been modified. Also tell for which branch it is meant, for example for trunk.
-''The attached patch applies to the file koffice/kword/kwdoc.cpp'' or for a directory: ''The attached patch applies to the directory koffice/kword''. This help the developers to have an overview of which code has been modified. Also tell for which branch it is meant, for example for trunk.
 Then tell what your patch does. If it fixes a bug, then please give the bug number too. If the bug was not registered in [http://bugs.kde.org KDE Bugs], then please describe instead the bug that is fixed. Similarly, if you know that the patch fixes a bug introduced from a precise SVN revision, please add the revision number.

@@ Line 133: / Line 133: @@
 === Reviewboard ===
-One popular way of submitting patches is [[Development/Review_Board|KDE's Review Board]]. Here you can upload a patch and request the KDE module team or individual maintainer review your code.  The Review Board provides tools for viewing diffs online, noting comments against code that needs changes, and granting approval to commit.  It is far easier to manage patches using Review Board than using e-mail or Bugzilla, so it is the recommended method to use.
+One popular way of submitting patches is [[Development/Review_Board|KDE's Review Board]]. Here you can upload a patch and request the KDE project team or individual maintainer review your code.  The Review Board provides tools for viewing diffs online, noting comments against code that needs changes, and granting approval to commit.  It is far easier to manage patches using Review Board than using e-mail or Bugzilla, so it is the recommended method to use.
 === And Now? ===

@@ Line 74: / Line 74: @@
 The main way of sharing a patch is to email to a mailing list. But be careful not to send big patches to a mailing list, a few 10KB is the limit.
-Some projects use [[Development/Review_Board|KDE's Review Board] for patch submitting. If a project is using the Review Board, that is usually their preferred way of receiving patches.  See the [[Contribute/Send_Patches#Reviewboard|section below]] for details.
+Some projects use [[Development/Review_Board|KDE's Review Board]] for patch submitting. If a project is using the Review Board, that is usually their preferred way of receiving patches.  See the [[Contribute/Send_Patches#Reviewboard|section below]] for details.
 If you find that the patch is too big to send to a mailing list, the best is to create a bug report in [http://bugs.kde.org KDE Bugs] and to attach the patch there, after having created the bug report.

@@ Line 133: / Line 133: @@
 === Reviewboard ===
-{{note|This section only describes how to use Reviewboard with SVN. To see how
+One popular way of submitting patches is [[Development/Review_Board|KDE's Review Board]]. Here you can upload a patch and request the KDE module team or individual maintainer review your code.  The Review Board provides tools for viewing diffs online, noting comments against code that needs changes, and granting approval to commit.  It is far easier to manage patches using Review Board than using Bugzilla, so it is the recommended method to use.
-to use it with Git, have a look at the [http://community.kde.org/Sysadmin/GitFAQ#Using_ReviewBoard_and_post-review git.kde.org manual].}}
-−
-One popular way of submitting patches is [http://reviewboard.kde.org KDE's reviewboard]. A big advantage over using the bugtracker of KDE is that the patches are less likely to be forgotten here. Also, the reviewboard allows inline review of diffs and other gimmicks.
-−
-First you need to check if the project you've created the patch for is actually using reviewboard. For this, go to the [http://reviewboard.kde.org/groups/ groups section] and see if the project's group is listed there. If it is listed there, you should use the reviewboard, otherwise send the patch by other means.
-−
-For sending a patch, you first need to register. Then simply click ''[http://reviewboard.kde.org/r/new/ New Review Request]'' and fill out the form. The most important parts of the form are:
-−
-* '''The actual patch'''. You need to upload the patch you've created earlier here
-* '''The SVN base path'''. This is needed for the inline patch display to work. This can be a bit tricky, if you are unfamiliar with KDE's SVN layout, check [http://websvn.kde.org WebSVN]. For example, if you're ''svn diff'ing'' from <tt>/path/to/your/copy/of/kdelibs/cmake/modules</tt>, the base path should be <tt>/trunk/KDE/kdelibs/cmake/modules</tt>. If you still don't know the correct base path, ask a developer on IRC. You can also edit the review request later.
-* '''A summary of the patch'''. This should be short, it will show up as subject of the notification emails.
-* '''A description of the patch'''. This can be longer.
-* '''The group(s)'''. Make sure you enter the correct group '''ID''' here, as seen earlier on the [http://reviewboard.kde.org/groups/ groups page].
-−
-After you completed the form, a notification mail will be sent to the developers and they will answer you.
-−
-/!\ You need to use svn diff in english, if your system is not english, please do LC_ALL=C svn diff
 === And Now? ===

← Older revision		Revision as of 11:47, 25 February 2011
Line 132:		Line 132:

	=== Reviewboard ===		=== Reviewboard ===
		+
		+	{{note\|This section only describes how to use Reviewboard with SVN. To see how
		+	to use it with Git, have a look at the [http://community.kde.org/Sysadmin/GitFAQ#Using_ReviewBoard_and_post-review git.kde.org manual].}}

	One popular way of submitting patches is [http://reviewboard.kde.org KDE's reviewboard]. A big advantage over using the bugtracker of KDE is that the patches are less likely to be forgotten here. Also, the reviewboard allows inline review of diffs and other gimmicks.		One popular way of submitting patches is [http://reviewboard.kde.org KDE's reviewboard]. A big advantage over using the bugtracker of KDE is that the patches are less likely to be forgotten here. Also, the reviewboard allows inline review of diffs and other gimmicks.

@@ Line 106: / Line 106: @@
 Assuming that you have chosen to send the patch to a mailing list, you might ask yourself: to which one?
-The best destination for patches is the [http://www.kde.org/mailinglists corresponding developer mailing list].
+The best destination for patches is the [http://www.kde.org/mailinglists/ corresponding developer mailing list].
 In case of doubt, you can send any patch for KDE to the [mailto:kde-devel@kde.org kde-devel mailing list]. (However with an increased risk that you would miss the right developer.)