Updates for release process
[devwiki.git] / branches.mdwn
index 36734fe..65588d5 100644 (file)
@@ -9,20 +9,19 @@ branches. This might look like:
     git checkout -b master origin/master #create local copy of master
     git checkout origin/feature # check out with no plan to commit
 
-However, Moonshot also has a number of submodules. These include
-libradsec, Shibboleth, and libeap.
-Each commit to the main Moonshot repository includes a reference to the
+However, Moonshot's source is distributed as a master repository  with  a number of [submodules](http://git-scm.com/book/en/Git-Tools-Submodules). These include
+libradsec, Shibboleth, and the moonshot GSS-API mechanism itself.
+Each commit to the master Moonshot repository includes a reference to the
 appropriate commit of a sub project to use. This is a *commit*, not a
 *branch*. That is, a Moonshot developer needs to make a explicit
 decision to update what version of a subproject is being used on a given
-moonshot branch.
+moonshot branch.  A commit of the master repository describes all the Moonshot software in use including every version of the submodules.
 
 However, git does not automatically adjust the version of subprojects
 you have checked out. After updating, either by pulling, checking out a new branch, merging or
 rebasing, it is a good idea to run 'git submodule update'. This command
 will set every subproject to the expected commit stored in the Moonshot
-branch you have checked out. See [[submodules]] for information on what
-to do if you need to work with one of these subprojects.
+branch you have checked out. 
 
 ## Master ##
 
@@ -36,22 +35,32 @@ master.
 At least until we have stable releases, new users should be directed to
 master.
 
-## meeting/moonshot2 ##
+[[Centos packaging|release/centos]] is built directly from the master branch.  However, while master is always built on Centos, the version numbers of Centos packages need to be incremented before new Centos packages are installed.
 
-This is a [[integration branch]] for the second moonshot meeting. As the
-meeting approaches it is desirable to slow down the pace of change in
-code that participants will be using. It would be unfortunate to get
-into a situation where a change breaking master disrupted the
-meeting. This branch is managed by Sam Hartman; ask before committing to
-this branch.
+The Ubuntu automated builds merge the changes from master together with the changes from the Debian branch below to generate packaging.
 
-Participants at the second moonshot meeting are likely to find a build
-of this branch helpful.
-However during the meeting we will likely update this branch or
-sometimes work from master once we get basic functionality working.
+## Debian
 
-## tlv-mic ##
+The Debian branch includes [[Debian packaging|release/debian]] which is used for Debian and Ubuntu builds.
 
-This branch is a [[feature branch]] under development. The intent is to
-add a cryptographic checksum to Moonshot exchanges as part of
-extensibility.
+
+# Working with Submodules
+
+Whenever you run "git submodule update", all submodules end up in a [detached head](http://eclipsesource.com/blogs/2011/05/29/life-lesson-be-mindful-of-a-detached-head/) state.  This produces very confusing behavior if you commit changes.  It's easy to lose track of changes.  Prior to changing a submodule, check out a branch.  Typically the same branch as the master repository, although for projects imported from other sources we often use the moonshot branch for our local change.  As of early 2014,, we're using the tr-integ branch for freeradius.
+
+In all cases, we're using the debian branch for debian packaging.
+
+## When you have something worth saving.
+
+If you have something working well enough to include in the master repository then:
+
+1. commit to the subproject
+
+2. push the branch containing the commit in the submodule.
+
+3. Run "git log origin/branchname" in the submodule and make sure your commit is there
+4. Run "git add submodule_directory" in the master repostiory
+
+4. Commit the master repository
+
+5. Push the branch in the master repository