Development: Code Review - Revision history

CityK: add link

2009-09-19T03:08:53Z

add link

← Older revision		Revision as of 03:08, 19 September 2009
Line 1:		Line 1:
-	We define a "code reviewer" as somebody who carefully looks over submitted source code, checking it for correctness and considers areas in which it could potentially be optimized, and then reports or provides such feedback to the original authour.	+	We define a "code reviewer" as somebody who carefully looks over [[Development: How to submit patches\|submitted source code]], checking it for correctness and considers areas in which it could potentially be optimized, and then reports or provides such feedback to the original authour.

	== Why have a Code Review? ==		== Why have a Code Review? ==

CityK: fixed link; chopped up a sprawling sentence, etc

2009-09-19T03:06:46Z

fixed link; chopped up a sprawling sentence, etc

← Older revision		Revision as of 03:06, 19 September 2009
Line 2:		Line 2:

	== Why have a Code Review? ==		== Why have a Code Review? ==
-	Nobody is perfect; we are all human and, hence, despite even the most rigorous attempts not to, we can potentially err somewhere along the way. In development, it is often the case that an unrecognized bug makes its way into ~~the~~ code, ~~and then remains~~ latent until it manifests itself in some more obvious way and, only after which, its presence is finally realized (i.e an end user encounters and [[Bug Report\|reports an error]] ~~that~~ is ultimately traced as to being derived from a bug that has been present in the code all along). The only way to make the Linux v4l-dvb code as stable and robust as possible is, in by itself, by having as many developers as possible analyze the source code, watching out for potential bugs and weaknesses.	+	Nobody is perfect; we are all human and, hence, despite even the most rigorous attempts not to, we can potentially err somewhere along the way. This is particularly true in software development, as it is often the case that an unrecognized bug makes its way into production code. Therein, the bug will remain latent until it manifests itself in some more obvious way and then, only after which time, its presence is finally realized (i.e an end user encounters and [[Bug Report\|reports an error]] which is ultimately traced to being derived from a bug that has been present in the source code all along).

	== When should you have a Code Review? ==		== When should you have a Code Review? ==
-	~~Consequently~~, having a code review is an integral part of the process for new [[Development: How to submit patches\|driver and patch submissions]] to the V4L-DVB code base.	+	Consequent to the above question as to why have a code review, having a code review is an integral part of the process for new [[Development: How to submit patches\|driver and patch submissions]] to the V4L-DVB code base. The only way to make the [[What is V4L or DVB?\|V4L-DVB]] code as stable and robust as possible is, in by itself, by having as many developers as possible analyze the source code, watching out for potential bugs and weaknesses.

	==Similar Concepts to a Code Review==		==Similar Concepts to a Code Review==
-	When you get a good idea on how to improve the existing code base, such as by introducing [[Development: ~~DVB~~ Driver Performance Optimisations\|performance optimisations]], or wish to introduce something entirely new to its feature set, please start a RFC (review for consideration) thread on the [mailto:majordomo@vger.kernel.org?body=subscribe%20linux-media Linux-Media Mailing List] (like this, [http://www.mail-archive.com/linux-media@vger.kernel.org/msg09831.html for example]) and let's discuss this/these idea(s).	+	When you get a good idea on how to improve the existing code base, such as by introducing [[Development: Driver Performance Optimisations\|performance optimisations]], or wish to introduce something entirely new to its feature set, please start a RFC (review for consideration) thread on the [mailto:majordomo@vger.kernel.org?body=subscribe%20linux-media Linux-Media Mailing List] (like this, [http://www.mail-archive.com/linux-media@vger.kernel.org/msg09831.html for example]) and let's discuss this/these idea(s).

	Also note that when you encounter a point where you see that it would make much more sense to completely rewrite portions of the V4L-DVB source code, you are now dealing with the much deeper process of '''refactoring'''; please have a look at the "[[Development: Hints for Refactoring Existing Drivers\|Hints for Refactoring Existing drivers]]" article for more information.		Also note that when you encounter a point where you see that it would make much more sense to completely rewrite portions of the V4L-DVB source code, you are now dealing with the much deeper process of '''refactoring'''; please have a look at the "[[Development: Hints for Refactoring Existing Drivers\|Hints for Refactoring Existing drivers]]" article for more information.

CityK: some reworking, removed a link

2009-09-19T02:22:38Z

some reworking, removed a link

← Older revision		Revision as of 02:22, 19 September 2009
Line 2:		Line 2:

	== Why have a Code Review? ==		== Why have a Code Review? ==
-	Nobody is perfect; we are all human and, hence, despite even the most rigorous attempts not to, we can potentially err somewhere along the way. In development, it is often the case that an unrecognized bug makes its way into the code, and then remains latent until it manifests itself in some more obvious way and, only after which, its presence is finally realized (i.e end user reports an error that is ultimately traced as being derived from a bug ~~in the code~~ that has been present all along). The only way to make the Linux v4l-dvb code as stable and robust as possible is, in by itself, by having as many developers as possible analyze the source code, watching out for potential bugs and weaknesses.	+	Nobody is perfect; we are all human and, hence, despite even the most rigorous attempts not to, we can potentially err somewhere along the way. In development, it is often the case that an unrecognized bug makes its way into the code, and then remains latent until it manifests itself in some more obvious way and, only after which, its presence is finally realized (i.e an end user encounters and [[Bug Report\|reports an error]] that is ultimately traced as to being derived from a bug that has been present in the code all along). The only way to make the Linux v4l-dvb code as stable and robust as possible is, in by itself, by having as many developers as possible analyze the source code, watching out for potential bugs and weaknesses.

-	== When should you have a ~~code review~~? ==	+	== When should you have a Code Review? ==
-	~~If you encounter a bug please file a [[Bug Report]] or~~, ~~even better, send in~~ a [[~~Bugfix~~]] !	+	Consequently, having a code review is an integral part of the process for new [[Development: How to submit patches\|driver and patch submissions]] to the V4L-DVB code base.

-	When you get a good idea on how to ~~make something better or wish to introduce~~ [[Development: DVB Driver Performance Optimisations\|performance optimisations]], please start a thread on the [mailto:majordomo@vger.kernel.org?body=subscribe%20linux-media linux-media ~~mailing list~~] and let's discuss this/these idea(s).	+	==Similar Concepts to a Code Review==
		+	When you get a good idea on how to improve the existing code base, such as by introducing [[Development: DVB Driver Performance Optimisations\|performance optimisations]], or wish to introduce something entirely new to its feature set, please start a RFC (review for consideration) thread on the [mailto:majordomo@vger.kernel.org?body=subscribe%20linux-media Linux-Media Mailing List] (like this, [http://www.mail-archive.com/linux-media@vger.kernel.org/msg09831.html for example]) and let's discuss this/these idea(s).

-	~~As soon~~ you encounter a point where you see that it would make much more sense to rewrite portions of the V4L-DVB source code, you are now dealing with the deeper process of '''refactoring'''; please have a look at the "[[Development: Hints for Refactoring Existing Drivers\|Hints for Refactoring Existing drivers]]" article for more information.	+	Also note that when you encounter a point where you see that it would make much more sense to completely rewrite portions of the V4L-DVB source code, you are now dealing with the much deeper process of '''refactoring'''; please have a look at the "[[Development: Hints for Refactoring Existing Drivers\|Hints for Refactoring Existing drivers]]" article for more information.


	[[Category:Development]]		[[Category:Development]]

CityK: some changes in wording

2009-01-18T00:33:31Z

some changes in wording

← Older revision		Revision as of 00:33, 18 January 2009
Line 9:		Line 9:
	When you get a good idea on how to make something better or wish to introduce [[Development: DVB Driver Performance Optimisations\|performance optimisations]], please start a thread on the [mailto:majordomo@vger.kernel.org?body=subscribe%20linux-media linux-media mailing list] and let's discuss this/these idea(s).		When you get a good idea on how to make something better or wish to introduce [[Development: DVB Driver Performance Optimisations\|performance optimisations]], please start a thread on the [mailto:majordomo@vger.kernel.org?body=subscribe%20linux-media linux-media mailing list] and let's discuss this/these idea(s).

-	As soon you encounter a point where you see that it would make sense to rewrite portions of the code, ~~to get into a~~ deeper ~~refactoring~~ process, please have a look at the "[[Development: Hints for Refactoring Existing Drivers\|Hints for Refactoring Existing drivers]]" article.	+	As soon you encounter a point where you see that it would make much more sense to rewrite portions of the V4L-DVB source code, you are now dealing with the deeper process of '''refactoring'''; please have a look at the "[[Development: Hints for Refactoring Existing Drivers\|Hints for Refactoring Existing drivers]]" article for more information.


	[[Category:Development]]		[[Category:Development]]

CityK: fixed link

2009-01-17T23:48:57Z

fixed link

← Older revision		Revision as of 23:48, 17 January 2009
Line 9:		Line 9:
	When you get a good idea on how to make something better or wish to introduce [[Development: DVB Driver Performance Optimisations\|performance optimisations]], please start a thread on the [mailto:majordomo@vger.kernel.org?body=subscribe%20linux-media linux-media mailing list] and let's discuss this/these idea(s).		When you get a good idea on how to make something better or wish to introduce [[Development: DVB Driver Performance Optimisations\|performance optimisations]], please start a thread on the [mailto:majordomo@vger.kernel.org?body=subscribe%20linux-media linux-media mailing list] and let's discuss this/these idea(s).

-	As soon you encounter a point where you see that it would make sense to rewrite portions of the code, to get into a deeper refactoring process, please have a look at the "[[Development: Hints for Refactoring ~~existing DVB drivers~~\|Hints for Refactoring ~~existing DVB~~ drivers]]" article.	+	As soon you encounter a point where you see that it would make sense to rewrite portions of the code, to get into a deeper refactoring process, please have a look at the "[[Development: Hints for Refactoring Existing Drivers\|Hints for Refactoring Existing drivers]]" article.


	[[Category:Development]]		[[Category:Development]]

CityK: minor changes

2009-01-15T23:22:11Z

minor changes

← Older revision		Revision as of 23:22, 15 January 2009
Line 1:		Line 1:
-	We define a "~~Code Reviewer~~" as somebody who carefully looks over submitted source code, checking it for correctness~~, thinks about~~ areas ~~for potential optimization~~, and then reports or provides such feedback to the original authour.	+	We define a "code reviewer" as somebody who carefully looks over submitted source code, checking it for correctness and considers areas in which it could potentially be optimized, and then reports or provides such feedback to the original authour.

	== Why have a Code Review? ==		== Why have a Code Review? ==
-
	Nobody is perfect; we are all human and, hence, despite even the most rigorous attempts not to, we can potentially err somewhere along the way. In development, it is often the case that an unrecognized bug makes its way into the code, and then remains latent until it manifests itself in some more obvious way and, only after which, its presence is finally realized (i.e end user reports an error that is ultimately traced as being derived from a bug in the code that has been present all along). The only way to make the Linux v4l-dvb code as stable and robust as possible is, in by itself, by having as many developers as possible analyze the source code, watching out for potential bugs and weaknesses.		Nobody is perfect; we are all human and, hence, despite even the most rigorous attempts not to, we can potentially err somewhere along the way. In development, it is often the case that an unrecognized bug makes its way into the code, and then remains latent until it manifests itself in some more obvious way and, only after which, its presence is finally realized (i.e end user reports an error that is ultimately traced as being derived from a bug in the code that has been present all along). The only way to make the Linux v4l-dvb code as stable and robust as possible is, in by itself, by having as many developers as possible analyze the source code, watching out for potential bugs and weaknesses.

	== When should you have a code review? ==		== When should you have a code review? ==
		+	If you encounter a bug please file a [[Bug Report]] or, even better, send in a [[Bugfix]] !

-	~~If you encounter a bug please file a [[Bug Report]] or even better, send in a [[Bugfix]]!~~	+	When you get a good idea on how to make something better or wish to introduce [[Development: DVB Driver Performance Optimisations\|performance optimisations]], please start a thread on the [mailto:majordomo@vger.kernel.org?body=subscribe%20linux-media linux-media mailing list] and let's discuss this/these idea(s).
-		+
-	When you get a ~~nice~~ idea how to make ~~things~~ better or to introduce [[Development: DVB Driver Performance Optimisations\|performance optimisations]] ~~then~~ please start a thread on the * The [mailto:majordomo@vger.kernel.org?body=subscribe%20linux-media linux-media] mailing list and let's discuss it.	+

	As soon you encounter a point where you see that it would make sense to rewrite portions of the code, to get into a deeper refactoring process, please have a look at the "[[Development: Hints for Refactoring existing DVB drivers\|Hints for Refactoring existing DVB drivers]]" article.		As soon you encounter a point where you see that it would make sense to rewrite portions of the code, to get into a deeper refactoring process, please have a look at the "[[Development: Hints for Refactoring existing DVB drivers\|Hints for Refactoring existing DVB drivers]]" article.

CityK: some minor changes re: mail list

2009-01-15T01:08:40Z

some minor changes re: mail list

← Older revision		Revision as of 01:08, 15 January 2009
Line 7:		Line 7:
	== When should you have a code review? ==		== When should you have a code review? ==

-	If you encounter a bug please file a [[Bug Report]] ~~to the linux-dvb Mailing List~~ or even better, send a [[Bugfix]] ~~in unified diff format created with ''cvs -q diff -pu > patchname.diff'' to the mailing list.~~	+	If you encounter a bug please file a [[Bug Report]] or even better, send in a [[Bugfix]]!

-	When you get a nice idea how to make things better or to introduce [[Development: DVB Driver Performance Optimisations\|performance optimisations]] then please start a thread on the linux-~~dvb Mailing List~~ and let's discuss it.	+	When you get a nice idea how to make things better or to introduce [[Development: DVB Driver Performance Optimisations\|performance optimisations]] then please start a thread on the * The [mailto:majordomo@vger.kernel.org?body=subscribe%20linux-media linux-media] mailing list and let's discuss it.

	As soon you encounter a point where you see that it would make sense to rewrite portions of the code, to get into a deeper refactoring process, please have a look at the "[[Development: Hints for Refactoring existing DVB drivers\|Hints for Refactoring existing DVB drivers]]" article.		As soon you encounter a point where you see that it would make sense to rewrite portions of the code, to get into a deeper refactoring process, please have a look at the "[[Development: Hints for Refactoring existing DVB drivers\|Hints for Refactoring existing DVB drivers]]" article.

CityK: /* Why have a Code Review? */ minor edit

2008-01-19T15:45:14Z

Why have a Code Review?: minor edit

← Older revision		Revision as of 15:45, 19 January 2008
Line 3:		Line 3:
	== Why have a Code Review? ==		== Why have a Code Review? ==

-	Nobody is perfect; we are all human and, hence, despite even the most rigorous attempts not to, we can potentially err somewhere along the way. In development, it is often the case that an unrecognized bug makes its way into the code, and then remains latent until it manifests itself in some more obvious way and, only after which, its presence is finally realized (i.e end user reports an error that is ultimately traced as being derived from a bug in the code that has been present all along). The only way to make the ~~linux~~-dvb code as stable and robust as possible is, in by itself, by having as many developers as possible analyze the source code, watching out for potential bugs and weaknesses.	+	Nobody is perfect; we are all human and, hence, despite even the most rigorous attempts not to, we can potentially err somewhere along the way. In development, it is often the case that an unrecognized bug makes its way into the code, and then remains latent until it manifests itself in some more obvious way and, only after which, its presence is finally realized (i.e end user reports an error that is ultimately traced as being derived from a bug in the code that has been present all along). The only way to make the Linux v4l-dvb code as stable and robust as possible is, in by itself, by having as many developers as possible analyze the source code, watching out for potential bugs and weaknesses.

	== When should you have a code review? ==		== When should you have a code review? ==

CityK: /* Why have a Code Review? */ minor

2008-01-07T19:08:50Z

Why have a Code Review?: minor

← Older revision		Revision as of 19:08, 7 January 2008
Line 3:		Line 3:
	== Why have a Code Review? ==		== Why have a Code Review? ==

-	Nobody is perfect; we are all human and, hence, despite even the most rigorous attempts not to, we can potentially err somewhere along the way. In development, it is often the case that an unrecognized bug makes its way into the code, and then remains latent until it manifests itself in some more obvious way and, after which, its presence is finally realized (i.e end user reports an error that is ultimately traced as being derived from a bug in the code that has been present all along). The only way to make the linux-dvb code as stable and robust as possible is, in by itself, by having as many developers as possible analyze the source code, watching out for potential bugs and weaknesses.	+	Nobody is perfect; we are all human and, hence, despite even the most rigorous attempts not to, we can potentially err somewhere along the way. In development, it is often the case that an unrecognized bug makes its way into the code, and then remains latent until it manifests itself in some more obvious way and, only after which, its presence is finally realized (i.e end user reports an error that is ultimately traced as being derived from a bug in the code that has been present all along). The only way to make the linux-dvb code as stable and robust as possible is, in by itself, by having as many developers as possible analyze the source code, watching out for potential bugs and weaknesses.

	== When should you have a code review? ==		== When should you have a code review? ==

CityK: /* Why have a Code Review? */ minor

2008-01-07T19:05:55Z

Why have a Code Review?: minor

← Older revision		Revision as of 19:05, 7 January 2008
Line 3:		Line 3:
	== Why have a Code Review? ==		== Why have a Code Review? ==

-	Nobody is perfect; we are all human and, hence, despite even the most rigorous attempts not to, we can potentially err somewhere along the way. In development, it is often the case that an unrecognized bug makes its way into the code, and then remains latent until it manifests itself in some more obvious way and its presence is finally realized (i.e end user reports an error that is ultimately traced to being derived from ~~the~~ bug in the code that ~~was~~ present all along). The only way to make the linux-dvb code as stable and robust as possible is by having as many developers as possible analyze the source ~~and watch~~ out for potential bugs and weaknesses.	+	Nobody is perfect; we are all human and, hence, despite even the most rigorous attempts not to, we can potentially err somewhere along the way. In development, it is often the case that an unrecognized bug makes its way into the code, and then remains latent until it manifests itself in some more obvious way and, after which, its presence is finally realized (i.e end user reports an error that is ultimately traced as being derived from a bug in the code that has been present all along). The only way to make the linux-dvb code as stable and robust as possible is, in by itself, by having as many developers as possible analyze the source code, watching out for potential bugs and weaknesses.

	== When should you have a code review? ==		== When should you have a code review? ==