Master git tree maintenance

= OEM Master Meeting =
== Thoughts prior to session [ikepanhc] ==
* Have another branch for developing build scripts for oem branches
  * why: usually there are only one flavour kernel built and we only need one header deb. Its different from distro branch.
  * why: Separate the source of each kernel into three parts: config, kernel source and build scripts, so that someone can take the major responsibility of the build script.
  * need to do: sync with distro branch, apply changes for oem branches, send feedback to distro branch.
  * advantage: easy to initial a new branch, easy to sync with distro and build server.
* Rebase when developing
  * distro will rebase kernel when a new tag available on upstream kernel
  * At least one rebase needed before final freeze. Usually it shall be 2-3 uploads before final upload.
  * Rebase on every new distro tags or wait for several distro releases?

== ATTENDEES ==
 * rtg, jk, ike, colin, vanhoof, keng-yu, hugh, dannf

== OVERVIEW ==
 * Ike and Jeremy provide a general overview of oem-master.git and process

== NOTES ==
 * The Kernel team maintains a separate git repo w/ debian rules, which are rarely changed, and changes can be applied to all builds, rather than having to maintain these changes individually to each build.

 * ABI must continue to change for OEM Projects as general updates and security updates need application. By cherry-picking only, we'll diverge too far from the distro kernel.

 * Some projects (typically ARM based), can take a couple months to release an update kernel depending on rebase complexity.

 * rtg brought up the idea of using a master-next to do incremental updates, rather than bulk rebases, which have been burdensome at times.

 * rtg also brought up the fact that the kernel team provides daily builds of master-next. Throughout the dev cycle. This helps ensure the build continues to compile, giving additional time to correct issues much earlier.

 * Does OEM know about everything and how it works? (action)

 * DannF would like a bit of information on how to properly interact w/ git, various tasks.

 * jk would like to ensure that branch pushes from private -> public are done with his script he wrote to ensure everyone is using the same process. Which should make this process a bit less prone to potential mistakes.

Work items:
[jk-ozlabs] compare oneiric debian rules tree to older releases (hardy) to see how new and legacy behaviour compares: TODO
[jk-ozlabs] check out potentially using $branch-next to ease our rebase pains: DONE
[vanhoof] check w/ OEMS to ensure they're up to speed on how to work within our build process(es): DONE