[Pkg-puppet-devel] [facter] 272/352: (maint) Update docs to reflect use of facter-2 branch

Stig Sandbeck Mathisen ssm at debian.org
Sun Apr 6 22:21:52 UTC 2014


This is an automated email from the git hooks/post-receive script.

ssm pushed a commit to branch master
in repository facter.

commit 2600f04211d6316f78416ff1bfedcbb70a6f0bfd
Author: Kylo Ginsberg <kylo at puppetlabs.com>
Date:   Sun Feb 16 08:18:26 2014 -0800

    (maint) Update docs to reflect use of facter-2 branch
    
    As we prepared for the release of Facter 2.0, we decided
    to do that development on a facter-2 branch rather than
    master. For details on this decision, see:
    
    https://groups.google.com/forum/#!msg/puppet-dev/Q24GLe6s1_4/hPwHgvVhnpIJ
    
    This commit reflects this change into the COMMITTERS.md and
    CONTRIBUTING.md documents. It's mostly replacing 'master' with
    'facter-2' in the appropriate places, but it also removes some
    old assumptions, e.g. about per-release branches.
---
 COMMITTERS.md   | 59 +++++++++++++++++++++++++++++++++------------------------
 CONTRIBUTING.md | 10 +++++-----
 2 files changed, 39 insertions(+), 30 deletions(-)

diff --git a/COMMITTERS.md b/COMMITTERS.md
index 6f81846..91e2ba0 100644
--- a/COMMITTERS.md
+++ b/COMMITTERS.md
@@ -5,7 +5,7 @@ We would like to make it easier for community members to contribute to facter
 using pull requests, even if it makes the task of reviewing and committing
 these changes a little harder.  Pull requests are only ever based on a single
 branch, however, we maintain more than one active branch.  As a result
-contributors should target their changes at the master branch. This makes the
+contributors should target their changes at the facter-2 branch. This makes the
 process of contributing a little easier for the contributor since they don't
 need to concern themselves with the question, "What branch do I base my changes
 on?"  This is already called out in the [CONTRIBUTING.md](http://goo.gl/XRH2J).
@@ -37,8 +37,7 @@ making the decision what base branch to merge the change set into.
 
 **base branch** - A branch in Git that contains an active history of changes
 and will eventually be released using semantic version guidelines.  The branch
-named master will always exist as a base branch.  All other base branches will
-be associated with a specific released version of facter, e.g. 1.6.x and 1.7.x.
+named master will always exist as a base branch.
 
 Committer Guide
 ====
@@ -97,7 +96,7 @@ branch:
    documentation being kept up to date?
  * Does the change set include clean code?  (software code that is formatted
    correctly and in an organized manner so that another coder can easily read
-   or modify it.)  HINT: `git diff master --check`
+   or modify it.)  HINT: `git diff --check`
  * Does the change set conform to the contributing guide?
 
 
@@ -113,9 +112,9 @@ paying attention to our automated build tools.
  * Watch the build until your changes have gone through green
  * Update the ticket status and target version.  The target version field in
    our issue tracker should be updated to be the next release of facter.  For
-   example, if the most recent release of facter is 1.6.17 and you merge a
-   backwards compatible change set into master, then the target version should
-   be 1.7.0 in the issue tracker.)
+   example, if the most recent release of facter is 2.0.1 and you merge a
+   backwards compatible change set into facter-2, then the target version should
+   be 2.1.0 in the issue tracker.)
  * Ensure the pull request is closed (Hint: amend your merge commit to contain
    the string `closes #123` where 123 is the pull request number.
 
@@ -126,11 +125,11 @@ This section helps a committer rebase a contribution onto an earlier base
 branch, then merge into the base branch and up through all active base
 branches.
 
-Suppose a contributor submits a pull request based on master.  The change set
-fixes a bug reported against facter 1.7.1 which is the most recently released
+Suppose a contributor submits a pull request based on facter-2.  The change set
+fixes a bug reported against facter 2.0.1 which is the most recently released
 version of facter.
 
-In this example the committer should rebase the change set onto the 1.7.x
+In this example the committer should rebase the change set onto the stable
 branch since this is a bug rather than new functionality.
 
 First, the committer pulls down the branch using the `hub` gem.  This tool
@@ -141,45 +140,55 @@ branch to track the remote branch.
     Branch jeffmccune-fix_foo_error set up to track remote branch fix_foo_error from jeffmccune.
     Switched to a new branch 'jeffmccune-fix_foo_error'
 
-At this point the topic branch is a descendant of master, but we want it to
-descend from 1.7.x.  The committer creates a new branch then re-bases the
+At this point the topic branch is a descendant of facter-2, but we want it to
+descend from stable.  The committer creates a new branch then re-bases the
 change set:
 
-    $ git branch bug/1.7.x/fix_foo_error
-    $ git rebase --onto 1.7.x master bug/1.7.x/fix_foo_error
+    $ git branch bug/stable/fix_foo_error
+    $ git rebase --onto stable master bug/stable/fix_foo_error
     First, rewinding head to replay your work on top of it...
-    Applying: (#23456) Fix FooError that always bites users in 1.7.1
+    Applying: (#23456) Fix FooError that always bites users in 2.0.1
 
 The `git rebase` command may be interpreted as, "First, check out the branch
-named `bug/1.7.x/fix_foo_error`, then take the changes that were previously
-based on `master` and re-base them onto `1.7.x`.
+named `bug/stable/fix_foo_error`, then take the changes that were previously
+based on `facter-2` and re-base them onto `stable`.
 
 Now that we have a topic branch containing the change set based on the correct
 release branch, the committer merges in:
 
-    $ git checkout 1.7.x
-    Switched to branch '1.7.x'
-    $ git merge --no-ff --log bug/1.7.x/fix_foo_error
+    $ git checkout stable
+    Switched to branch 'stable'
+    $ git merge --no-ff --log bug/stable/fix_foo_error
     Merge made by the 'recursive' strategy.
      foo | 0
      1 file changed, 0 insertions(+), 0 deletions(-)
      create mode 100644 foo
 
-Once merged into the first base branch, the committer merges up:
+Once merged into the first base branch, the committer merges up to facter-2:
+
+    $ git checkout facter-2
+    Switched to branch 'facter-2'
+    $ git merge --no-ff --log stable
+    Merge made by the 'recursive' strategy.
+     foo | 0
+     1 file changed, 0 insertions(+), 0 deletions(-)
+     create mode 100644 foo
+
+And then merges up to master:
 
     $ git checkout master
     Switched to branch 'master'
-    $ git merge --no-ff --log 1.7.x
+    $ git merge --no-ff --log stable
     Merge made by the 'recursive' strategy.
      foo | 0
      1 file changed, 0 insertions(+), 0 deletions(-)
      create mode 100644 foo
 
 Once the change set has been merged "in and up." the committer pushes.  (Note,
-the checklist should be complete at this point.)  Note that both the 1.7.x and
-master branches are being pushed at the same time.
+the checklist should be complete at this point.)  Note that the stable,
+facter-2 and master branches are being pushed at the same time.
 
-    $ git push puppetlabs master:master 1.7.x:1.7.x
+    $ git push puppetlabs master:master facter-2:facter-2 stable:stable
 
 That's it!  The committer then updates the pull request, updates the issue in
 our issue tracker, and keeps an eye on the build status.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 91ac321..d7626e9 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -19,13 +19,13 @@ top of things.
 ## Making Changes
 
 * Create a topic branch from where you want to base your work.
-  * This is usually the master branch.
+  * This is usually the facter-2 branch.
   * Only target release branches if you are certain your fix must be on that
     branch.
-  * To quickly create a topic branch based on master; `git branch
-    fix/master/my_contribution master` then checkout the new branch with `git
-    checkout fix/master/my_contribution`.  Please avoid working directly on the
-    `master` branch.
+  * To quickly create a topic branch based on facter-2; `git branch
+    fix/facter-2/my_contribution facter-2` then checkout the new branch with `git
+    checkout fix/facter-2/my_contribution`.  Please avoid working directly on the
+    `facter-2` branch.
 * Make commits of logical units.
 * Check for unnecessary whitespace with `git diff --check` before committing.
 * Make sure your commit messages are in the proper format.

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-puppet/facter.git



More information about the Pkg-puppet-devel mailing list