HOW-TO:Submit a patch - Revision history

UNiversal: kodi.tv and XBMC -> Kodi and some final typos.

2015-04-29T12:24:09Z

kodi.tv and XBMC -> Kodi and some final typos.

← Older revision		Revision as of 12:24, 29 April 2015
Line 1:		Line 1:
	{{cleanup}}		{{cleanup}}

	Kodi is a non-profit open source hobby project that is developed by volunteers in their spare time without any monetary gain. The team of developers working on ~~XBMC~~ encourage anyone submit source code patches for bug-fixes, new features/functions or improvements to existing ones. Any and all contributions to the source code are appreciated, though please understand that there is no guarantee that your patch will be accepted and implemented into Kodi. If you wish to have input from Kodi developers prior to implementing a feature or improvement, please open a discussion on the [http://forum.~~xbmc~~.~~org~~ forums]. Lastly, understand that it may take us a little while to review your patch, so please be patient - clean and well documented code will most likely be looked at sooner than messy or undocumented code.		Kodi is a non-profit open source hobby project that is developed by volunteers in their spare time without any monetary gain.
			The team of developers working on Kodi encourage anyone submit source code patches for bug-fixes, new features/functions or improvements to existing ones.
			Any and all contributions to the source code are appreciated, though please understand that there is no guarantee that your patch will be accepted and implemented into Kodi.
			If you wish to have input from Kodi developers prior to implementing a feature or improvement, please open a discussion on the [http://forum.kodi.tv kodi forums]. Lastly, understand that it may take us a little while to review your patch, so please be patient - clean and well documented code will most likely be looked at sooner than messy or undocumented code.

	:'''~~Note~~!''' We know our rules place a burden on you the submitter, but rest assured that maintaining a large, complex software project is even harder, so please accept the rules that have been set before you here. These rules are there for a reason, we cannot afford to spend too much of our time fixing buggy, broken or outdated patches. The closer you follow our rules the higher is the likelihood that your patch will be accepted.
			{{Bluev\|'''NOTE!'''\|
			We know our rules place a burden on you the submitter, but rest assured that maintaining a large, complex software project is even harder, so please accept the rules that have been set before you here. These rules are there for a reason, we cannot afford to spend too much of our time fixing buggy, broken or outdated patches. The closer you follow our rules the higher is the likelihood that your patch will be accepted.}}

	= Code submissions =		= Code submissions =
	Please submit all code submissions as a "''pull request''" to the [https://github.com/xbmc/xbmc/pulls Kodi Github ] - see the section below for information on how to create a pull request. Then to get some attention please also post a new thread in the development-section of our [http://forum.~~xbmc~~.~~org~~ forums] describing the patch. Doing so allows for a more open discussion with the whole Kodi community including non-developers about possible improvements/enhancements or additions and bugs/fixes. Note that any code you submit will be (c) Team XBMC.		Please submit all code submissions as a "''pull request''" to the [https://github.com/xbmc/xbmc/pulls Kodi Github ] - see the section below for information on how to create a pull request. Then to get some attention please also post a new thread in the development-section of our [http://forum.kodi.tv forums] describing the patch. Doing so allows for a more open discussion with the whole Kodi community including non-developers about possible improvements/enhancements or additions and bugs/fixes. Note that any code you submit will be (c) Team XBMC.

	== Minimum requirements ==		== Minimum requirements ==
Line 12:		Line 17:

	== Code documentation ==		== Code documentation ==
	Though not yet a standard in all Kodi source code, please try and document at least the "public" portions of your code using [http://www.doxygen.org doxygen] inline comments. If you are submitting a new feature or function, please also add a small "''readme.txt''" to the the patch describing the use of feature that may be used as a basis for user documentation in the wiki later. You are most welcome to format this up for the wiki after the patch is submitted.		Though not yet a standard in all Kodi source code, please try and document at least the "public" portions of your code using [http://www.doxygen.org doxygen] inline comments.
			If you are submitting a new feature or function, please also add a small "''readme.txt''" to the the patch describing the use of feature that may be used as a basis for user documentation in the wiki later. You are most welcome to format this up for the wiki after the patch is submitted.

	== Code guide-lines and formatting conventions ==		== Code guide-lines and formatting conventions ==
			:;Please consult:
			{{main\|Official:Code guidelines and formatting conventions}}

	~~Consult {{main\|Official:Code guidelines and formatting conventions}}~~		All code should strive to be platform agnostic - Kodi is multi-platform software, thus any single platform-specific features should be discussed with Kodi team members before being implemented.
			Major features should ideally be developed in a separate branch or in small increments so that other members have the opportunity to review the code and comment on it during development.
	All code should strive to be platform agnostic - Kodi is multi-platform software, thus any single platform-specific features should be discussed with Kodi team members before being implemented. Major features should ideally be developed in a separate branch or in small increments so that other members have the opportunity to review the code and comment on it during development.

	== Patch format ==		== Patch format ==
	Please do not send complete files. These need to be diffed by hand to see the changes, which makes reviews harder and less likely to occur. Besides as soon as one of the files changes, your version becomes harder to apply, thus reducing its chances of being accepted. Please follow these simple rules when making patch for Kodi:		Please do not send complete files. These need to be diffed by hand to see the changes, which makes reviews harder and less likely to occur. Besides as soon as one of the files changes, your version becomes harder to apply, thus reducing its chances of being accepted. Please follow these simple rules when making patch for Kodi:

	:'''1.''' Use git to its full potential. The best thing is to fork the Kodi project on [https://github.com/xbmc/xbmc github], branch from there, and develop your patch on top of HEAD. See the [https://help.github.com excellent documentation at github] for help with this.		:'''1.''' Use git to its full potential. The best thing is to fork the Kodi project on [https://github.com/xbmc/xbmc Kodi github], branch from there, and develop your patch on top of HEAD. See the [https://help.github.com excellent documentation at github] for help with this.

	:'''2.''' Make sure you keep each commit as simple as possible as well as self-contained. i.e. a commit series that builds at each commit and builds up the functionality required is much nicer than a single huge commit that changes lots of things at once.		:'''2.''' Make sure you keep each commit as simple as possible as well as self-contained. i.e. a commit series that builds at each commit and builds up the functionality required is much nicer than a single huge commit that changes lots of things at once.
Line 35:		Line 42:
	:'''6.''' Make sure you maintain const'ness where reasonable.		:'''6.''' Make sure you maintain const'ness where reasonable.

	:'''7.''' If you implement new features or modify the ~~behavior~~ of existing features, please do not forget to also point out whether any changes are required in the wiki documentation, and ideally perform these changes once your patch series is accepted.		:'''7.''' If you implement new features or modify the behaviour of existing features, please do not forget to also point out whether any changes are required in the wiki documentation, and ideally perform these changes once your patch series is accepted.

	:'''8.''' When you're done, push to your github repo and do a pull request against the main Kodi repository. See the [https://help.github.com excellent documentation at github] for more information.		:'''8.''' When you're done, push to your github repo and do a pull request against the main Kodi repository. See the [https://help.github.com excellent documentation at github] for more information.

UNiversal at 12:12, 29 April 2015

2015-04-29T12:12:32Z

← Older revision		Revision as of 12:12, 29 April 2015
Line 1:		Line 1:
	{{cleanup}}		{{cleanup}}

	~~XBMC~~ is a non-profit open source hobby project that is developed by volunteers in their spare time without any monetary gain. The team of developers working on XBMC encourage anyone submit source code patches for bug-fixes, new features/functions or improvements to existing ones. Any and all contributions to the source code are appreciated, though please understand that there is no guarantee that your patch will be accepted and implemented into ~~XBMC~~. If you wish to have input from ~~XBMC~~ developers prior to implementing a feature or improvement, please open a discussion on the [http://forum.xbmc.org forums]. Lastly, understand that it may take us a little while to review your patch, so please be patient - clean and well documented code will most likely be looked at sooner than messy or undocumented code.		Kodi is a non-profit open source hobby project that is developed by volunteers in their spare time without any monetary gain. The team of developers working on XBMC encourage anyone submit source code patches for bug-fixes, new features/functions or improvements to existing ones. Any and all contributions to the source code are appreciated, though please understand that there is no guarantee that your patch will be accepted and implemented into Kodi. If you wish to have input from Kodi developers prior to implementing a feature or improvement, please open a discussion on the [http://forum.xbmc.org forums]. Lastly, understand that it may take us a little while to review your patch, so please be patient - clean and well documented code will most likely be looked at sooner than messy or undocumented code.

	:'''Note!''' We know our rules place a burden on you the submitter, but rest assured that maintaining a large, complex software project is even harder, so please accept the rules that have been set before you here. These rules are there for a reason, we cannot afford to spend too much of our time fixing buggy, broken or outdated patches. The closer you follow our rules the higher is the likelihood that your patch will be accepted.		:'''Note!''' We know our rules place a burden on you the submitter, but rest assured that maintaining a large, complex software project is even harder, so please accept the rules that have been set before you here. These rules are there for a reason, we cannot afford to spend too much of our time fixing buggy, broken or outdated patches. The closer you follow our rules the higher is the likelihood that your patch will be accepted.

	= Code submissions =		= Code submissions =
	Please submit all code submissions as a "''pull request''" to the [https://github.com/xbmc/xbmc/pulls ~~XBMC~~ Github ] - see the section below for information on how to create a pull request. Then to get some attention please also post a new thread in the development-section of our [http://forum.xbmc.org forums] describing the patch. Doing so allows for a more open discussion with the whole ~~XBMC~~ community including non-developers about possible improvements/enhancements or additions and bugs/fixes. Note that any code you submit will be (c) Team XBMC.		Please submit all code submissions as a "''pull request''" to the [https://github.com/xbmc/xbmc/pulls Kodi Github ] - see the section below for information on how to create a pull request. Then to get some attention please also post a new thread in the development-section of our [http://forum.xbmc.org forums] describing the patch. Doing so allows for a more open discussion with the whole Kodi community including non-developers about possible improvements/enhancements or additions and bugs/fixes. Note that any code you submit will be (c) Team XBMC.

	== Minimum requirements ==		== Minimum requirements ==
Line 12:		Line 12:

	== Code documentation ==		== Code documentation ==
	Though not yet a standard in all ~~XBMC~~ source code, please try and document at least the "public" portions of your code using [http://www.doxygen.org doxygen] inline comments. If you are submitting a new feature or function, please also add a small "''readme.txt''" to the the patch describing the use of feature that may be used as a basis for user documentation in the wiki later. You are most welcome to format this up for the wiki after the patch is submitted.		Though not yet a standard in all Kodi source code, please try and document at least the "public" portions of your code using [http://www.doxygen.org doxygen] inline comments. If you are submitting a new feature or function, please also add a small "''readme.txt''" to the the patch describing the use of feature that may be used as a basis for user documentation in the wiki later. You are most welcome to format this up for the wiki after the patch is submitted.

	== Code guide-lines and formatting conventions ==		== Code guide-lines and formatting conventions ==
	This is still under discussion, so for now please follow or add to the discussion [http://forum.xbmc.org/showthread.php?t=5238 here]. Of course, modular designs (like dynamic or static libraries) are preferred.

	All code should strive to be platform agnostic - ~~XBMC~~ is multi-platform software, thus any single platform-specific features should be discussed with ~~XBMC~~ team members before being implemented. Major features should ideally be developed in a separate branch or in small increments so that other members have the opportunity to review the code and comment on it during development.		Consult {{main\|Official:Code guidelines and formatting conventions}}

			All code should strive to be platform agnostic - Kodi is multi-platform software, thus any single platform-specific features should be discussed with Kodi team members before being implemented. Major features should ideally be developed in a separate branch or in small increments so that other members have the opportunity to review the code and comment on it during development.

	== Patch format ==		== Patch format ==
	Please do not send complete files. These need to be diffed by hand to see the changes, which makes reviews harder and less likely to occur. Besides as soon as one of the files changes, your version becomes harder to apply, thus reducing its chances of being accepted. Please follow these simple rules when making patch for ~~XBMC~~:		Please do not send complete files. These need to be diffed by hand to see the changes, which makes reviews harder and less likely to occur. Besides as soon as one of the files changes, your version becomes harder to apply, thus reducing its chances of being accepted. Please follow these simple rules when making patch for Kodi:

	:'''1.''' Use git to its full potential. The best thing is to fork the ~~xbmc~~ project on [https://github.com/xbmc/xbmc github], branch from there, and develop your patch on top of HEAD. See the [https://help.github.com excellent documentation at github] for help with this.		:'''1.''' Use git to its full potential. The best thing is to fork the Kodi project on [https://github.com/xbmc/xbmc github], branch from there, and develop your patch on top of HEAD. See the [https://help.github.com excellent documentation at github] for help with this.

	:'''2.''' Make sure you keep each commit as simple as possible as well as self-contained. i.e. a commit series that builds at each commit and builds up the functionality required is much nicer than a single huge commit that changes lots of things at once.		:'''2.''' Make sure you keep each commit as simple as possible as well as self-contained. i.e. a commit series that builds at each commit and builds up the functionality required is much nicer than a single huge commit that changes lots of things at once.
Line 36:		Line 37:
	:'''7.''' If you implement new features or modify the behavior of existing features, please do not forget to also point out whether any changes are required in the wiki documentation, and ideally perform these changes once your patch series is accepted.		:'''7.''' If you implement new features or modify the behavior of existing features, please do not forget to also point out whether any changes are required in the wiki documentation, and ideally perform these changes once your patch series is accepted.

	:'''8.''' When you're done, push to your github repo and do a pull request against the main ~~XBMC~~ repository. See the [https://help.github.com excellent documentation at github] for more information.		:'''8.''' When you're done, push to your github repo and do a pull request against the main Kodi repository. See the [https://help.github.com excellent documentation at github] for more information.

	:'''9.''' Give us a few days to react. We try to review patches as quickly as possible, but unfortunately we are constantly overloaded with work, be it ~~XBMC~~-related or from our day to day lives. If your patch seems to be ignored, post a reminder asking for opinions in the forum's development section or as a reply to the original patch ticket, mentioning that you got ignored - we are interested in your work and will eventually either accept it or reject it with an explanation of what we liked and disliked about your patch. Note that we will often ask you to make changes to your patch to make it acceptable before we commit it, so please implement those changes, and update your branch with the changes made as you go. Some of these changes may seem trivial, but the less work we need to do, the faster it'll hit GIT.		:'''9.''' Give us a few days to react. We try to review patches as quickly as possible, but unfortunately we are constantly overloaded with work, be it Kodi-related or from our day to day lives. If your patch seems to be ignored, post a reminder asking for opinions in the forum's development section or as a reply to the original patch ticket, mentioning that you got ignored - we are interested in your work and will eventually either accept it or reject it with an explanation of what we liked and disliked about your patch. Note that we will often ask you to make changes to your patch to make it acceptable before we commit it, so please implement those changes, and update your branch with the changes made as you go. Some of these changes may seem trivial, but the less work we need to do, the faster it'll hit GIT.

	:'''10.''' Enjoy developing for ~~XBMC~~ :)		:'''10.''' Enjoy developing for Kodi :)

	= External Links =		= External Links =

Ned Scott: /* External Links */

2013-04-09T03:30:52Z

External Links

← Older revision		Revision as of 03:30, 9 April 2013
Line 47:		Line 47:
	[[Category:How-to\|Submit a Patch]]		[[Category:How-to\|Submit a Patch]]
	[[Category:Development]]		[[Category:Development]]
	~~[[Category:Trac]]~~

Ned Scott at 03:29, 9 April 2013

2013-04-09T03:29:44Z

← Older revision		Revision as of 03:29, 9 April 2013
Line 1:		Line 1:
			{{cleanup}}

	XBMC is a non-profit open source hobby project that is developed by volunteers in their spare time without any monetary gain. The team of developers working on XBMC encourage anyone submit source code patches for bug-fixes, new features/functions or improvements to existing ones. Any and all contributions to the source code are appreciated, though please understand that there is no guarantee that your patch will be accepted and implemented into XBMC. If you wish to have input from XBMC developers prior to implementing a feature or improvement, please open a discussion on the [http://forum.xbmc.org forums]. Lastly, understand that it may take us a little while to review your patch, so please be patient - clean and well documented code will most likely be looked at sooner than messy or undocumented code.		XBMC is a non-profit open source hobby project that is developed by volunteers in their spare time without any monetary gain. The team of developers working on XBMC encourage anyone submit source code patches for bug-fixes, new features/functions or improvements to existing ones. Any and all contributions to the source code are appreciated, though please understand that there is no guarantee that your patch will be accepted and implemented into XBMC. If you wish to have input from XBMC developers prior to implementing a feature or improvement, please open a discussion on the [http://forum.xbmc.org forums]. Lastly, understand that it may take us a little while to review your patch, so please be patient - clean and well documented code will most likely be looked at sooner than messy or undocumented code.

>Jmarshall: /* Patch format */

2012-10-13T09:35:49Z

Patch format

← Older revision		Revision as of 09:35, 13 October 2012
Line 20:		Line 20:
	Please do not send complete files. These need to be diffed by hand to see the changes, which makes reviews harder and less likely to occur. Besides as soon as one of the files changes, your version becomes harder to apply, thus reducing its chances of being accepted. Please follow these simple rules when making patch for XBMC:		Please do not send complete files. These need to be diffed by hand to see the changes, which makes reviews harder and less likely to occur. Besides as soon as one of the files changes, your version becomes harder to apply, thus reducing its chances of being accepted. Please follow these simple rules when making patch for XBMC:

	:'''1.''' ~~Always make patches for GIT~~ HEAD. ~~We do not accept patches~~ for ~~releases or outdated GIT revisions~~.		:'''1.''' Use git to its full potential. The best thing is to fork the xbmc project on [https://github.com/xbmc/xbmc github], branch from there, and develop your patch on top of HEAD. See the [https://help.github.com excellent documentation at github] for help with this.

	:'''2.''' Make ~~unified diff created using e~~.g. ~~git diff against head ('git diff' or 'git diff --unified=n')~~. ~~Unified diffs can be applied easily with 'patch'. This~~ is much ~~harder with other diff types. Unified diffs are more readable and thus easier to review~~.		:'''2.''' Make sure you keep each commit as simple as possible as well as self-contained. i.e. a commit series that builds at each commit and builds up the functionality required is much nicer than a single huge commit that changes lots of things at once.

	::'''~~NOTE!~~''' ~~Please make each patch per feature~~, ~~(not~~ one ~~patch per source file~~ with ~~multiple features in it)~~.		:'''3.''' When you're changing functions that require re-indenting, it's best to do the functionality change in one commit, with a second commit for the cosmetic re-indenting.

	:'''3.''' ~~Please create the diff from the root of the XBMC GIT source tree~~, ~~this makes the diff easier to apply as it saves the step~~ of ~~searching for and changing to the correct directory~~.		:'''4.''' Check your commits for unnecessary cosmetic changes such as whitespace changes, particularly for whitespace at end of line.

	:'''4.''' ~~Test~~ the ~~functionality~~ of ~~your patch~~. ~~We'll refuse it~~ if ~~it breaks something~~, ~~even if it extends other features!~~		:'''5.''' Doxy and new functions added, particularly if they're to the public API of a class. Doxy classes as well if necessary. The important thing is what the function is supposed to do, what parameter values are (plus any default values) and what the return code is.

	:'''5.''' ~~Read your patch~~. ~~We may refuse it if it changes indentation of the code or if it does tab/space conversion or other cosmetic changes!~~		:'''6.''' Make sure you maintain const'ness where reasonable.

	::'''~~TIP!~~''' If you ~~already wrote some code and did cosmetic changes~~, ~~you can use 'diff -uwbBE' to help you remove them. Do~~ not forget to ~~check~~ the patch ~~to make sure diff did not ignore some important change and remove any remaining cosmetics!~~		:'''7.''' If you implement new features or modify the behavior of existing features, please do not forget to also point out whether any changes are required in the wiki documentation, and ideally perform these changes once your patch series is accepted.

	:'''6.''' ~~Comment parts that really need it (tricky side-effects etc). Always document string operations! Comment on what~~ you ~~are doing~~ and ~~why it is safe~~. ~~This makes it easy to review and change your code if needed~~. ~~Do not comment trivial code~~. ~~Comments must be English!~~		:'''8.''' When you're done, push to your github repo and do a pull request against the main XBMC repository. See the [https://help.github.com excellent documentation at github] for more information.

	:'''7.''' If you ~~implement new features~~ or ~~modify the behavior~~ of ~~existing features~~, please ~~do not forget to also point out whether any~~ changes ~~are required in the wiki documentation~~, and ~~ideally perform~~ these changes ~~once your patch is accepted~~.		:'''9.''' Give us a few days to react. We try to review patches as quickly as possible, but unfortunately we are constantly overloaded with work, be it XBMC-related or from our day to day lives. If your patch seems to be ignored, post a reminder asking for opinions in the forum's development section or as a reply to the original patch ticket, mentioning that you got ignored - we are interested in your work and will eventually either accept it or reject it with an explanation of what we liked and disliked about your patch. Note that we will often ask you to make changes to your patch to make it acceptable before we commit it, so please implement those changes, and update your branch with the changes made as you go. Some of these changes may seem trivial, but the less work we need to do, the faster it'll hit GIT.

	:'''8.''' If you make independent changes, please submit them as separate patches in separate patch-tracker item to our XBMC patch-tracker. Likewise, if your patch is very large, try splitting it into several self-contained pieces, so that each part can then be reviewed and committed separately.		:'''10.''' Enjoy developing for XBMC :)

	:'''9.''' Upload the patch file directly as an attachment to the [http://trac.xbmc.org Trac ticket] rather than using some other web hosting facility. The fewer steps it takes us to get at the patch, the higher the likelihood of it geting reviewed and applied. If your patch is so large that you cannot upload it, try splitting it into smaller pieces first, and only if it is absolutely unavoidable use zip to compress it.

	:'''10.''' ~~Use a clear title and description in the ticket detailing what the patch is~~ for and (if necessary) why it was done the way it was. If the patch fixes a bug, include the bug number (eg fixes #8479) in the title or description, and add a comment to the bug ticket linking back to the patch.

	~~:'''11.''' Give us a few days to react. We try to review patches as quickly as possible, but unfortunately we are constantly overloaded with work, be it~~ XBMC-related or from our day to day lives. If your patch seems to be ignored, post a reminder asking for opinions in the forum's development section or as a reply to the original patch ticket, mentioning that you got ignored - we are interested in your work and will eventually either accept it or reject it with an explanation of what we liked and disliked about your patch. Note that we will often ask you to make changes to your patch to make it acceptable before we commit it, so please implement those changes, and attach an updated patch to the ticket. Some of these changes may seem trivial, but the less work we need to do, the faster it'll hit GIT.

	:~~'''11.''' Do not immediately ask for GIT write access. If you have contributed one or more nice, acceptable patches and they need maintaining, we'll come to you.~~

	:'''12.''' If you send a modified or updated version of your patch, resend the complete patch. It is very time-consuming and error-prone to piece together patches that are distributed over several files and/or tickets. Please always resend patches as replies to the original trac ticket to keep the thread with the discussion together.

	= External Links =		= External Links =

>DonJ at 17:15, 17 May 2012

2012-05-17T17:15:45Z

← Older revision		Revision as of 17:15, 17 May 2012
Line 4:		Line 4:

	= Code submissions =		= Code submissions =
	Please submit all code submissions as a "''~~unified diff~~''" to the [~~http~~://~~trac~~.xbmc~~.org~~ XBMC ~~Tracker (Trac)~~] - see the section below for information on how to create a ~~unified diff - and please avoid compressing it prior to uploading unless absolutely necessary~~. Then to get some attention please also post a new thread in the development-section of our [http://forum.xbmc.org forums] describing the patch. Doing so allows for a more open discussion with the whole XBMC community including non-developers about possible improvements/enhancements or additions and bugs/fixes. Note that any code you submit will be (c) Team XBMC.		Please submit all code submissions as a "''pull request''" to the [https://github.com/xbmc/xbmc/pulls XBMC Github ] - see the section below for information on how to create a pull request. Then to get some attention please also post a new thread in the development-section of our [http://forum.xbmc.org forums] describing the patch. Doing so allows for a more open discussion with the whole XBMC community including non-developers about possible improvements/enhancements or additions and bugs/fixes. Note that any code you submit will be (c) Team XBMC.

	== Minimum requirements ==		== Minimum requirements ==

>Jleonardw9: /* Patch format */

2012-03-25T16:43:02Z

Patch format

Ned Scott at 02:18, 27 November 2011

2011-11-27T02:18:02Z

← Older revision		Revision as of 02:18, 27 November 2011
Line 55:		Line 55:
	[[Category:How-to\|Submit a Patch]]		[[Category:How-to\|Submit a Patch]]
	[[Category:Development]]		[[Category:Development]]
			[[Category:Trac]]

>NedBot: Bot: Removing from Category:Inner Workings

2011-11-26T22:37:33Z

Bot: Removing from Category:Inner Workings

← Older revision		Revision as of 22:37, 26 November 2011
Line 55:		Line 55:
	[[Category:How-to\|Submit a Patch]]		[[Category:How-to\|Submit a Patch]]
	[[Category:Development]]		[[Category:Development]]
	~~[[Category:Inner Workings]]~~

>NedBot: moved How-to-TEMP:Submit a patch to HOW-TO:Submit a patch: Bot: Moved page

2011-10-03T15:06:41Z

moved How-to-TEMP:Submit a patch to HOW-TO:Submit a patch: Bot: Moved page

← Older revision	Revision as of 15:06, 3 October 2011
(No difference)

← Older revision		Revision as of 16:43, 25 March 2012
Line 20:		Line 20:
	Please do not send complete files. These need to be diffed by hand to see the changes, which makes reviews harder and less likely to occur. Besides as soon as one of the files changes, your version becomes harder to apply, thus reducing its chances of being accepted. Please follow these simple rules when making patch for XBMC:		Please do not send complete files. These need to be diffed by hand to see the changes, which makes reviews harder and less likely to occur. Besides as soon as one of the files changes, your version becomes harder to apply, thus reducing its chances of being accepted. Please follow these simple rules when making patch for XBMC:

	:'''1.''' Always make patches for ~~Subversion~~ HEAD. We do not accept patches for releases or outdated ~~Subversion~~ revisions.		:'''1.''' Always make patches for GIT HEAD. We do not accept patches for releases or outdated GIT revisions.

	:'''2.''' Make unified diff created using e.g. ~~svn~~ diff against head ('~~svn~~ diff' or 'diff -~~Naur~~'). Unified diffs can be applied easily with 'patch'. This is much harder with other diff types. Unified diffs are more readable and thus easier to review.		:'''2.''' Make unified diff created using e.g. git diff against head ('git diff' or 'git diff --unified=n'). Unified diffs can be applied easily with 'patch'. This is much harder with other diff types. Unified diffs are more readable and thus easier to review.

	::'''NOTE!''' Please make each patch per feature, (not one patch per source file with multiple features in it).		::'''NOTE!''' Please make each patch per feature, (not one patch per source file with multiple features in it).

	:'''3.''' Please create the diff from the root of the XBMC ~~SVN~~ source tree, this makes the diff easier to apply as it saves the step of searching for and changing to the correct directory.		:'''3.''' Please create the diff from the root of the XBMC GIT source tree, this makes the diff easier to apply as it saves the step of searching for and changing to the correct directory.

	:'''4.''' Test the functionality of your patch. We'll refuse it if it breaks something, even if it extends other features!		:'''4.''' Test the functionality of your patch. We'll refuse it if it breaks something, even if it extends other features!
Line 32:		Line 32:
	:'''5.''' Read your patch. We may refuse it if it changes indentation of the code or if it does tab/space conversion or other cosmetic changes!		:'''5.''' Read your patch. We may refuse it if it changes indentation of the code or if it does tab/space conversion or other cosmetic changes!

	::'''TIP!''' If you already wrote some code and did cosmetic changes, you can use 'diff -uwbBE' to help you remove them. Do not forget to check the patch to make sure diff did not ignore some important change and remove any remaining cosmetics! ~~To use these options directly with svn, use this command: ''svn diff --diff-cmd diff -x -uwbBE''~~		::'''TIP!''' If you already wrote some code and did cosmetic changes, you can use 'diff -uwbBE' to help you remove them. Do not forget to check the patch to make sure diff did not ignore some important change and remove any remaining cosmetics!

	:'''6.''' Comment parts that really need it (tricky side-effects etc). Always document string operations! Comment on what you are doing and why it is safe. This makes it easy to review and change your code if needed. Do not comment trivial code. Comments must be English!		:'''6.''' Comment parts that really need it (tricky side-effects etc). Always document string operations! Comment on what you are doing and why it is safe. This makes it easy to review and change your code if needed. Do not comment trivial code. Comments must be English!
Line 40:		Line 40:
	:'''8.''' If you make independent changes, please submit them as separate patches in separate patch-tracker item to our XBMC patch-tracker. Likewise, if your patch is very large, try splitting it into several self-contained pieces, so that each part can then be reviewed and committed separately.		:'''8.''' If you make independent changes, please submit them as separate patches in separate patch-tracker item to our XBMC patch-tracker. Likewise, if your patch is very large, try splitting it into several self-contained pieces, so that each part can then be reviewed and committed separately.

	:'''9.''' Upload the patch file directly as an attachment to the [http://trac.xbmc.org Trac ticket] rather than using some other web hosting facility. The fewer steps it takes us to get at the patch, the higher the likelihood of it ~~getingt~~ reviewed and applied. If your patch is so large that you cannot upload it, try splitting it into smaller pieces first, and only if it is absolutely unavoidable use zip to compress it.		:'''9.''' Upload the patch file directly as an attachment to the [http://trac.xbmc.org Trac ticket] rather than using some other web hosting facility. The fewer steps it takes us to get at the patch, the higher the likelihood of it geting reviewed and applied. If your patch is so large that you cannot upload it, try splitting it into smaller pieces first, and only if it is absolutely unavoidable use zip to compress it.

	:'''10.''' Use a clear title and description in the ticket detailing what the patch is for and (if necessary) why it was done the way it was. If the patch fixes a bug, include the bug number (eg fixes #8479) in the title or description, and add a comment to the bug ticket linking back to the patch.		:'''10.''' Use a clear title and description in the ticket detailing what the patch is for and (if necessary) why it was done the way it was. If the patch fixes a bug, include the bug number (eg fixes #8479) in the title or description, and add a comment to the bug ticket linking back to the patch.

	:'''11.''' Give us a few days to react. We try to review patches as quickly as possible, but unfortunately we are constantly overloaded with work, be it XBMC-related or from our day to day lives. If your patch seems to be ignored, post a reminder asking for opinions in the forum's development section or as a reply to the original patch ticket, mentioning that you got ignored - we are interested in your work and will eventually either accept it or reject it with an explanation of what we liked and disliked about your patch. Note that we will often ask you to make changes to your patch to make it acceptable before we commit it, so please implement those changes, and attach an updated patch to the ticket. Some of these changes may seem trivial, but the less work we need to do, the faster it'll hit ~~SVN~~.		:'''11.''' Give us a few days to react. We try to review patches as quickly as possible, but unfortunately we are constantly overloaded with work, be it XBMC-related or from our day to day lives. If your patch seems to be ignored, post a reminder asking for opinions in the forum's development section or as a reply to the original patch ticket, mentioning that you got ignored - we are interested in your work and will eventually either accept it or reject it with an explanation of what we liked and disliked about your patch. Note that we will often ask you to make changes to your patch to make it acceptable before we commit it, so please implement those changes, and attach an updated patch to the ticket. Some of these changes may seem trivial, but the less work we need to do, the faster it'll hit GIT.

	:'''11.''' Do not immediately ask for ~~Subversion~~ write access. If you have contributed one or more nice, acceptable patches and they need maintaining, we'll come to you.		:'''11.''' Do not immediately ask for GIT write access. If you have contributed one or more nice, acceptable patches and they need maintaining, we'll come to you.

	:'''12.''' If you send a modified or updated version of your patch, resend the complete patch. It is very time-consuming and error-prone to piece together patches that are distributed over several files and/or tickets. Please always resend patches as replies to the original trac ticket to keep the thread with the discussion together.		:'''12.''' If you send a modified or updated version of your patch, resend the complete patch. It is very time-consuming and error-prone to piece together patches that are distributed over several files and/or tickets. Please always resend patches as replies to the original trac ticket to keep the thread with the discussion together.