Maintaining Git trees - Revision history

Dbagnall: /* Example */ asalted patches is unmaintained and incompatible with current thunderbird

2012-07-07T10:10:45Z

Example: asalted patches is unmaintained and incompatible with current thunderbird

← Older revision		Revision as of 10:10, 7 July 2012
Line 301:		Line 301:
	The command will create a series of emails bodies, one file per email.		The command will create a series of emails bodies, one file per email.

-	Just send the email with the patch inlined for it to ge caught by patchwork.	+	Just send the email with the patch inlined for it to get caught by patchwork.

-	BE CAREFUL: several emailers including Thunderdird breaks long lines, causing patch corruption.	+	BE CAREFUL: several emailers including Thunderdird breaks long lines, causing patch corruption.
-	~~In the specific case of Thunderbird, an extension is needed to send the patches: [https://hg.mozilla.org/users/clarkbw_gnome.org/asalted-patches/\| Asalted Patches]~~.	+

Dbagnall: /* Example */

2012-07-07T10:07:23Z

Example

← Older revision		Revision as of 10:07, 7 July 2012
Line 277:		Line 277:
	Suppose that the -git tree were created with:		Suppose that the -git tree were created with:

-	git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux~~-2.6~~.git v4l-dvb	+	git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git v4l-dvb
	cd v4l-dvb		cd v4l-dvb
-	git remote add linuxtv git://linuxtv.org/~~v4l-dvb~~.git	+	git remote add linuxtv git://linuxtv.org/media_tree.git
	git remote update		git remote update
-	git checkout -b media-master linuxtv/~~master~~	+	git checkout -b media-master remotes/linuxtv/staging/for_v3.6
-		+
	Before start working, you need to create your work branch:		Before start working, you need to create your work branch:

Dbagnall: /* Obtaining the current v4l-dvb work tree */ replace version number example with algorithm for finding the version number

2012-07-07T09:25:54Z

Obtaining the current v4l-dvb work tree: replace version number example with algorithm for finding the version number

← Older revision		Revision as of 09:25, 7 July 2012
Line 1:		Line 1:
-	==Obtaining the current ~~v4l-dvb~~ work tree==	+	==Obtaining the current media work tree==

-	Up to date instructions can be found at http://git.linuxtv.org/media_tree.git. They currently read as follows (replace <tt>X.X</tt> with a future kernel version number, ~~e.g <tt>3.6</tt>~~):	+	Up to date instructions can be found at http://git.linuxtv.org/media_tree.git. They currently read as follows (replace <tt>X.X</tt> with a future kernel version number, typically two versions ahead of the current kernel):

	: To clone the master development repository, install git, and run:		: To clone the master development repository, install git, and run:

Dbagnall: /* KERNEL DEVELOPMENT PROCEDURES AT THE KERNEL UPSTREAM */ use numbered list, and some grammatical tweaks

2012-07-07T09:18:23Z

KERNEL DEVELOPMENT PROCEDURES AT THE KERNEL UPSTREAM: use numbered list, and some grammatical tweaks

← Older revision		Revision as of 09:18, 7 July 2012
Line 26:		Line 26:
	Kernel development has 2 phases:		Kernel development has 2 phases:

-	*1) a merge window typically ~~with~~ 2 weeks, starting with the release of a new kernel version;	+	# a merge window, typically 2 weeks long, starting with the release of a new kernel version;
		+	# the -rc period, where the new kernel is tested and receives fixes.

-	*2) the -rc period, where the Kernel is tested and receive fixes.	+	The length of the -rc period depends on the number and relevance of the fixes. There are usually between 6 and 9 -rc releases with a week between each, but it can vary. In general, the announcement of a new -rc kernel gives some hints when that -rc kernel may be the last one.
-		+
-	The length of the -rc period depends on the number and relevance of the fixes. ~~Usually there~~ are between 6 and 9 rc releases a week ~~apart from~~ each ~~other~~, but ~~this~~ can vary.	+
-		+
-	In general, the announcement of a new -rc kernel gives some hints when that -rc kernel may be the last one.	+

	====Subsystem procedures for merging patches upstream====		====Subsystem procedures for merging patches upstream====

Dbagnall: /* KERNEL DEVELOPMENT PROCEDURES AT THE KERNEL UPSTREAM */ s/2.6/3/ and remove table or 2.6 rc counts

2012-07-07T09:11:32Z

KERNEL DEVELOPMENT PROCEDURES AT THE KERNEL UPSTREAM: s/2.6/3/ and remove table or 2.6 rc counts

← Older revision		Revision as of 09:11, 7 July 2012
Line 26:		Line 26:
	Kernel development has 2 phases:		Kernel development has 2 phases:

-	*1) a merge window typically with 2 weeks ~~(although Linus is gave some indications that he may reduce it on 2.6.34)~~, starting with the release of a new kernel version;	+	*1) a merge window typically with 2 weeks, starting with the release of a new kernel version;

	*2) the -rc period, where the Kernel is tested and receive fixes.		*2) the -rc period, where the Kernel is tested and receive fixes.

-	The length of the -rc period depends on the number and relevance of the fixes. ~~Considering the recent history, it ranges from -rc6 to -rc8, where each -rc takes one week.~~	+	The length of the -rc period depends on the number and relevance of the fixes. Usually there are between 6 and 9 rc releases a week apart from each other, but this can vary.
-		+
-	~~Those~~ are ~~the latest -rc kernels since 2.~~6~~.12:~~	+
-	~~{\| border="1" cellpadding="2"~~	+
-	~~!kernel !!latest -~~rc ~~version~~	+
-	\|-	+
-	~~\|2.6.12 \|\|align="center" \| rc6~~	+
-	\|-	+
-	~~\|2.6.13 \|\|align="center" \| rc7~~	+
-	\|-	+
-	~~\|2.6.14 \|\|align="center" \| rc5~~	+
-	\|-	+
-	~~\|2.6.15 \|\|align="center" \| rc7~~	+
-	\|-	+
-	~~\|2.6.16 \|\|align="center" \| rc6~~	+
-	\|-	+
-	~~\|2.6.17 \|\|align="center" \| rc6~~	+
-	\|-	+
-	~~\|2.6.18 \|\|align="center" \| rc7~~	+
-	\|-	+
-	~~\|2.6.19 \|\|align="center" \| rc6~~	+
-	\|-	+
-	~~\|2.6.20 \|\|align="center" \| rc7~~	+
-	\|-	+
-	~~\|2.6.21 \|\|align="center" \| rc7~~	+
-	\|-	+
-	~~\|2.6.22 \|\|align="center" \| rc7~~	+
-	\|-	+
-	~~\|2.6.23 \|\|align="center" \| rc9~~	+
-	\|-	+
-	~~\|2.6.24 \|\|align="center" \| rc8~~	+
-	\|-	+
-	~~\|2.6.25 \|\|align="center" \| rc9~~	+
-	\|-	+
-	~~\|2.6.26 \|\|align="center" \| rc9~~	+
-	\|-	+
-	~~\|2.6.27 \|\|align="center" \| rc9~~	+
-	\|-	+
-	~~\|2.6.28 \|\|align="center" \| rc9~~	+
-	\|-	+
-	~~\|2.6.29 \|\|align="center" \| rc8~~	+
-	\|-	+
-	~~\|2.6.30 \|\|align="center" \| rc8~~	+
-	\|-	+
-	~~\|2.6.31 \|\|align="center" \| rc9~~	+
-	\|-	+
-	~~\|2.6~~.~~32 \|\|align="center" \| rc8~~	+
-	\|}	+

	In general, the announcement of a new -rc kernel gives some hints when that -rc kernel may be the last one.		In general, the announcement of a new -rc kernel gives some hints when that -rc kernel may be the last one.
Line 85:		Line 38:
	The required procedure on subsystem trees is that:		The required procedure on subsystem trees is that:

-	a) During -rc period (e.g. latest main kernel available is ~~2.6~~.x, the latest -rc kernel is ~~2.6~~.[x+1]-rc<y>):	+	a) During -rc period (e.g. latest main kernel available is 3.x, the latest -rc kernel is 3.[x+1]-rc<y>):

-	* fix patches for the -rc kernel (~~2.6~~.[x+1]) should be sent upstream, being a good idea to send them for some time at linux-next tree, allowing other people to test it, and check for potential conflicts with the other arch's;	+	* fix patches for the -rc kernel (3.[x+1]) should be sent upstream, being a good idea to send them for some time at linux-next tree, allowing other people to test it, and check for potential conflicts with the other arch's;
-	* patches for ~~2.6~~.[x+2] should be sent to linux-next.	+	* patches for 3.[x+2] should be sent to linux-next.

-	b) the release of ~~2.6~~.[x+1] kernel:	+	b) the release of 3.[x+1] kernel:

	* closes the -rc period and starts the merge window.		* closes the -rc period and starts the merge window.
Line 96:		Line 49:
	c) During the merge window:		c) During the merge window:

-	* the patch that were added on linux-next during the -rc period for ~~2.6~~.[x+2] should be sent upstream;	+	* the patch that were added on linux-next during the -rc period for 3.[x+2] should be sent upstream;
-	* new non-fix patches should be hold until the next -rc period starts, so, they'll be added on ~~2.6~~.[x+3];	+	* new non-fix patches should be hold until the next -rc period starts, so, they'll be added on 3.[x+3];
-	* fix patches for ~~2.6~~.[x+2] should go to linux-next, wait for a few days and then send upstream.	+	* fix patches for 3.[x+2] should go to linux-next, wait for a few days and then send upstream.

-	d) the release of ~~2.6~~.[x+2]-rc1 kernel:	+	d) the release of 3.[x+2]-rc1 kernel:

	* the merge window has closed. No new features are allowed.		* the merge window has closed. No new features are allowed.
Line 121:		Line 74:
	====Patches for stable====		====Patches for stable====

-	Sometimes, a fix patch corrects a problem that happens also on stable kernels (e. g. on kernel ~~2.6~~.x or even ~~2.6~~.y, where y < x). In this case, the patch should be sent to stable@kernel.org, in order to be added on stable kernels.	+	Sometimes, a fix patch corrects a problem that happens also on stable kernels (e. g. on kernel 3.x or even 3.y, where y < x). In this case, the patch should be sent to stable@kernel.org, in order to be added on stable kernels.

-	In the case of git-submitted patches with fixes, that also need to be send to stable, all the developer needs to do is to add~~, a~~ the patch description:	+	In the case of git-submitted patches with fixes, that also need to be send to stable, all the developer needs to do is to add to the patch description:
	CC: stable.kernel.org		CC: stable.kernel.org

-	At the moment the patch reaches upstream, a copy of the patch will be automatically be sent to the stable maintainer and will be considered for inclusion on the next stable kernel (~~2.6~~.x.y).	+	At the moment the patch reaches upstream, a copy of the patch will be automatically be sent to the stable maintainer and will be considered for inclusion on the next stable kernel (3.x.y).

	== KERNEL DEVELOPMENT PROCEDURES FOR V4L/DVB ==		== KERNEL DEVELOPMENT PROCEDURES FOR V4L/DVB ==

Dbagnall: /* Obtaining the current v4l-dvb work tree */ punctuation

2012-07-07T07:22:55Z

Obtaining the current v4l-dvb work tree: punctuation

← Older revision		Revision as of 07:22, 7 July 2012
Line 1:		Line 1:
	==Obtaining the current v4l-dvb work tree==		==Obtaining the current v4l-dvb work tree==

-	Up to date instructions can be found at http://git.linuxtv.org/media_tree.git. They currently read as follows (replace <tt>X.X</tt> with a future kernel version number, e.g <tt>3.6</tt>).	+	Up to date instructions can be found at http://git.linuxtv.org/media_tree.git. They currently read as follows (replace <tt>X.X</tt> with a future kernel version number, e.g <tt>3.6</tt>):

	: To clone the master development repository, install git, and run:		: To clone the master development repository, install git, and run:

Dbagnall: /* This page is misleading and out of date. */ generalise away from 3.6 to X.X; less scary heading

2012-07-07T07:22:08Z

This page is misleading and out of date.: generalise away from 3.6 to X.X; less scary heading

← Older revision		Revision as of 07:22, 7 July 2012
Line 1:		Line 1:
-	== ~~This page is misleading and out of date.~~==	+	==Obtaining the current v4l-dvb work tree==

-	~~The~~ instructions ~~you want~~ can be found at http://git.linuxtv.org/media_tree.git, ~~and go thus:~~	+	Up to date instructions can be found at http://git.linuxtv.org/media_tree.git. They currently read as follows (replace <tt>X.X</tt> with a future kernel version number, e.g <tt>3.6</tt>).

	: To clone the master development repository, install git, and run:		: To clone the master development repository, install git, and run:
Line 9:		Line 9:
	git remote add linuxtv git://linuxtv.org/media_tree.git		git remote add linuxtv git://linuxtv.org/media_tree.git
	git remote update		git remote update
-	git checkout -b media-master remotes/linuxtv/staging/~~for_v3~~.6	+	git checkout -b media-master remotes/linuxtv/staging/for_vX.X

	: If you want to clone a different repository, just replace the URL at the git remote add line above.		: If you want to clone a different repository, just replace the URL at the git remote add line above.
	: In order to update your repository, you should do:		: In order to update your repository, you should do:

-	git pull . remotes/linuxtv/staging/~~for_v3~~.6	+	git pull . remotes/linuxtv/staging/for_vX.X

	: And to put your work on the top of a stanging branch:		: And to put your work on the top of a stanging branch:

-	git rebase remotes/linuxtv/staging/~~for_v3~~.6	+	git rebase remotes/linuxtv/staging/for_vX.X

	== KERNEL DEVELOPMENT PROCEDURES AT THE KERNEL UPSTREAM ==		== KERNEL DEVELOPMENT PROCEDURES AT THE KERNEL UPSTREAM ==

Dbagnall: Warn against following the instructions here (without fixing them, due to ignorance)

2012-06-23T10:40:43Z

Warn against following the instructions here (without fixing them, due to ignorance)

← Older revision		Revision as of 10:40, 23 June 2012
Line 1:		Line 1:
		+	== This page is misleading and out of date.==
		+
		+	The instructions you want can be found at http://git.linuxtv.org/media_tree.git, and go thus:
		+
		+	: To clone the master development repository, install git, and run:
		+
		+	git clone git://github.com/torvalds/linux.git v4l-dvb
		+	cd v4l-dvb
		+	git remote add linuxtv git://linuxtv.org/media_tree.git
		+	git remote update
		+	git checkout -b media-master remotes/linuxtv/staging/for_v3.6
		+
		+	: If you want to clone a different repository, just replace the URL at the git remote add line above.
		+	: In order to update your repository, you should do:
		+
		+	git pull . remotes/linuxtv/staging/for_v3.6
		+
		+	: And to put your work on the top of a stanging branch:
		+
		+	git rebase remotes/linuxtv/staging/for_v3.6
		+
	== KERNEL DEVELOPMENT PROCEDURES AT THE KERNEL UPSTREAM ==		== KERNEL DEVELOPMENT PROCEDURES AT THE KERNEL UPSTREAM ==

CityK: fixed links

2012-02-20T19:02:46Z

fixed links

← Older revision		Revision as of 19:02, 20 February 2012
Line 294:		Line 294:
	==Patches submitted via email==		==Patches submitted via email==

-	All valid patches submitted via email to [[mailto:linux-media@vger.kernel.org Linux Media ML]] are automatically stored at [[http://patchwork.~~kernel~~.org/project/linux-media/list/ ~~Kernel~~ Patchwork]]. A patch, to be valid, should be in diff unified format. If you're using a -git tree, the simplest way to generate unified diff patches is to run:	+	All valid patches submitted via email to [mailto:linux-media@vger.kernel.org Linux Media ML] are automatically stored at [http://patchwork.linuxtv.org/project/linux-media/list/ Patchwork]. A patch, to be valid, should be in diff unified format. If you're using a -git tree, the simplest way to generate unified diff patches is to run:
	git diff		git diff

Mauro Carvalho Chehab: /* How to solve those issues? */

2010-01-30T11:29:27Z

How to solve those issues?

← Older revision		Revision as of 11:29, 30 January 2010
Line 118:		Line 118:
	Unfortunately, sometimes people mark the driver with the wrong tag. For example, a patch got merged on Jan, 22 2010 that marked with "high". However, that patch didn't apply at the fixes tree, because it fix a regression introduced by a driver that weren't merged upstream yet.		Unfortunately, sometimes people mark the driver with the wrong tag. For example, a patch got merged on Jan, 22 2010 that marked with "high". However, that patch didn't apply at the fixes tree, because it fix a regression introduced by a driver that weren't merged upstream yet.

-	====== How to solve those issues? ======	+	==== How to solve those issues? ====

	Well, basically, the subsystem should work with more than one tree (or branch), on upstream submission:		Well, basically, the subsystem should work with more than one tree (or branch), on upstream submission: