linux-kernel - libata git repo guide (was Re: [PATCH 01/02] sata_mv: tidy up qc->tf usage in qc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Fri, 17 Apr 2009 18:59:51 -0400
From:	Jeff Garzik <jgarzik@...ox.com>
To:	IDE/ATA development list <linux-ide@...r.kernel.org>
CC:	Mark Lord <liml@....ca>, Stephen Rothwell <sfr@...b.auug.org.au>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Tejun Heo <htejun@...il.com>,
	Matthew Wilcox <willy@...ux.intel.com>
Subject: libata git repo guide (was Re: [PATCH 01/02] sata_mv: tidy up qc->tf
 usage in qc_prep() functions)

Mark Lord wrote:
> For upstream-linus, please.


Any volunteers wanna format and post this to the wiki? 
http://ata.wiki.kernel.org/

For what it's worth, upstream-linus is for Linus only, not for anyone else.

Relevant branches of libata-dev.git:

ALL		All libata code I consider acceptable for public
		testing.  Intended for Andrew Morton's -mm tree,
		but I am always looking for people to help test!

NEXT		libata code intended for current kernel + 1
		This is a subset of ALL, and is intended for
		the linux-next tree, and even more rigorous
		public testing.

upstream-fixes	This branch exists when the merge window is NOT open.
		Fixes queued for Linus go here, during -rc.  Generally
		I push to Linus pretty rapidly, though, so programmers
		are encouraged to send patches diff'd against Linus
		upstream during -rc.

upstream	libata code intended for current kernel + 1.  When the
		merge window is closed, patches are queued here.  When
		the merge window is open, fixes for Linus are also
		queued here.

		Generally upstream==NEXT, but this is not guaranteed.

		i.e. sometimes I will put a fix on a separate git
		branch, and then merge that into the mix, such that

			NEXT == upstream + fix-that-needs-testing

And then there are individual branches that pop in and out of existence, 
as I do my own work.  For example, currently active branches are

fixes-eh-freeze	  Freeze ordering fix recently discussed; needs some
		codepath review before I am sure it is safe. (NEXT)

libahci		libahci patchset recently posted (NEXT, ALL)

sectsize	Variable sector size patch.  Will not go into
		#upstream branch until I satisfy some request of
		willy's, which slips my mind at the moment (ALL)

sx4		sata_sx4 new EH conversion (ALL)

And last, but not least,

master		Vanilla Linux kernel, with no changes from me.

		Exists to indicate the root of all above branches,
		so that "git log master..libahci" or
		"git diff master..upstream" works as expected.


NOTE:  All of the branches except 'master' may be rebased.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/