OMAP patch merging process

= Various branches in linux-omap tree =


 * master branch is the current snapshot of various topic branches
 * omap-fixes branch contains fixes queued up for Linus during the -rc cycle
 * for-next branch contains patches queued up for the next merge window
 * topic branches, such as dss2, dspbridge, and cbus contain patches not yet ready for merging

= Patch submission checklist =


 * Read Documentation/Submit* files in your kernel directory first
 * Run scripts/checkpatch.pl --strict on your patches
 * Make sure all patches compile (this is needed for git bisect to work)
 * Make sure other omaps don't break and keep compiling
 * Send driver code to the right subsystem maintainer in MAINTAINERS file
 * Cc linux-omap@vger.kernel.org list for all the patches
 * Send arch/arm/*omap*/ in separate patches
 * Send what can be sent as fixes during the -rc cycle
 * Prepare code for the next merge window early, the deadline for new code is -rc7

= Merging patch sets using git =

If you have several patches, the preferred way of merging them is to provide a git branch to pull from. If you provide a git branch, please use the following checklist:


 * Your branch is against the current mainline Linux tree, not linux-omap master, or the PM branch
 * If there are merge conflicts, you may need to rebase on the current omap-for-linus branch in the linux-omap tree
 * Your git is configured so the committer and author show up correctly
 * Each patch has a descriptive commit message
 * Each patch passes checkpatch.pl --strict
 * Each patch builds to avoid breaking git bisect
 * Each patch boots with at least the omap3_defconfig
 * All patches have been posted to the relevant mailing lists for several days. For arch/arm/*omap*/* patches, you need to post to both linux-omap and linux-arm-kernel mailing lists
 * When your patchset is ready to be pulled, please post a pull request generated with git request-pull