This document will outline some common scenarios the Fedora kernel
developers face in day to day maintenance.  It will walk through how to
do these tasks with a git tree based workflow and hopefully illustrate
how things will work.

Git tree setup
--------------

These tools require an exploded source git tree based on Linus' upstream
tree.  The following setup is required:

1) Clone Linus' tree

  git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

2) Add the upstream stable tree as a remote

  git remote add stable git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

3) Add the Fedora tree as a remote

  git remote add fedora git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git 

4) Fetch the stable and fedora trees/tags

  git remote update

5) Create local tracking branches for each of the Fedora releases

  git checkout -b rawhide --track fedora/rawhide
  git checkout -b f22 --track fedora/f22
  git checkout -b f21 --track fedora/f21

In this setup, the 'master' branch in your local tree always follows
Linus' upstream tree and does not deviate from it.  This is common git
practice and shouldn't cause issues.  The fedora release are tracked in
your local 'f<num>' branches, or in the case of rawhide, the 'rawhide'
branch.

There are two other directories in play.

PKG_GIT_DIR is the location of the Fedora pkg-git kernel checkout.
This is where the scripts will copy things to and what will be pushed
to Fedora's pkg-git SCM which is still used to build in koji.

The WORKDIR is a staging location for all the various files and sources
we will be splatting into pkg-git.  By default it is created as ./tmp
under the fedora script directory in the local git tree.

WORKFLOWS
=========

New -rcX or stable rebase
-------------------------

When a new upstream stable release is done, we rebase that branch to the new
release.  Here are the steps to do this

  # Make sure you have the new tag in your local tree
  git remote update

  # Checkout your local fedora branch and make sure it's updated
  git checkout f22

  # If the remote command refreshed the fedora/rawhide or f<n> branches,
  # then someone pushed stuff out.  Since our branches rebase, we need to
  # reset it to the lastest commit
  git reset --hard fedora/f22
  cd fedora
  make rebase tag=v4.0.5
  make configs
  make sources
  make patches upstream=v4.0.5 or make patches upstream=`cat upstream-tag`
  make changelog
  make spec

  # At this point, you have all the sources, patches, and a fully prepped
  # kernel.spec file in the workdir.  Look it over, make sure it isn't
  # totally horked, etc.
  # Then it's time to copy it to pkg-git
  make pkg-git

  # Now your local pkg-git tree has a staged set of patches, configs,
  # and kernel.spec.  Review the diff and if things look good, commit.
  make pkg-git-commit

  # Then commit your rebase in the exploded tree
  make commit

  # Push the results out
  make push

  # Now things should be committed locally in both the git tree and pkg-git
  # If you want to build it, tag and build
  make tag-build

  # When the build completes, push the tag too
  make push-tag
 
  
Rebase rawhide
--------------

Rawhide is rebased daily on Linus' tree upstream.  We'll walk through
how to do this in the git tree setup.

  # Check if there are new commits on Linus' tree
  git checkout master
  git remote update
  # If there are new commits, merge them into your master branch.
  # This should always be a fast-forward merge
  git merge origin/master

  #Rebase the rawhide branch to a random git snapshot
  git checkout rawhide

  # If the remote command refreshed the fedora/rawhide branch, then
  # someone pushed stuff out.  Since rawhide rebases, we need to
  # reset it to the lastest commit
  git reset --hard fedora/rawhide
  cd fedora
  make rebase upstream=master
  make git-snapshot
  make debug
  make configs
  make sources
  make patches upstream=master
  make changelog
  make spec

  # At this point, you have all the sources, patches, and a fully prepped
  # kernel.spec file in the workdir.  Look it over, make sure it isn't
  # totally horked, etc.
  # Then it's time to copy it to pkg-git
  make pkg-git

  # Now your local pkg-git tree has a staged set of patches, configs,
  # and kernel.spec.  Review the diff and if things look good, commit.
  make pkg-git-commit

  # Then commit your rebase in the exploded tree
  make commit

  # Push the results out
  make push

  # Now things should be committed locally in both the git tree and pkg-git
  # If you want to build it, tag and build
  make tag-build

  # When the build completes, push the tag too
  make push-tag


Add a patch or change a config option
-------------------------------------

  git checkout rawhide
  # If the remote command refreshed the fedora/rawhide branch, then
  # someone pushed stuff out.  Since rawhide rebases, we need to
  # reset it to the lastest commit
  git reset --hard fedora/rawhide
  
  # Use git am or git cherry-pick to commit your patch.  Or edit local
  # files to make your own patch, etc.  This is your normal typical
  # exploded source tree stuff
  < get your patch applied >

  # Now create your RPM changelog
  make changelog

  # Repeat the above two steps for however many bugs/patches you're doing
  < repeat >

  # Get the working dir updated
  make configs
  make sources

  # When we create the patches, we need to generate them based on whatever
  # the latest upstream tag we're based on is.  Since we aren't actually
  # modifying that in this step, we can rely on the upstream-tag file.
  make patches upstream=`cat upstream-tag`

  # And the spec
  make spec

  # Stage it to pkg-git, review, and commit it out
  make pkg-git
  make pkg-git-commit

  # Commit the local changes so the spec template stays update
  make commit

  # Push out the changes
  make push

  # Tag and build if you want
  make tag-build

  # Push the tag when the build completes
  make push-tag