You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@brooklyn.apache.org by tb...@apache.org on 2018/02/16 10:26:57 UTC
[18/25] brooklyn-docs git commit: Move website content up a level and
simplify config
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/code/git-more.md
----------------------------------------------------------------------
diff --git a/website/developers/code/git-more.md b/website/developers/code/git-more.md
deleted file mode 100644
index 6b5c814..0000000
--- a/website/developers/code/git-more.md
+++ /dev/null
@@ -1,295 +0,0 @@
----
-title: Get the Code
-layout: website-normal
-children:
-- { section: Set Up Forks }
-- { section: Multi-Project Changes }
-- { section: How We Use Branches, title: Branches }
-- { section: About Submodules, title: Submodules }
-- { section: Not Using Submodules }
-- { section: Useful Aliases and Commands, title: Git Aliases }
-- { section: Legacy Incubator Pull Requests, title: Incubator PRs }
----
-
-## Set Up Forks
-
-If you're contributing or working a lot on a feature,
-you'll probably want your own forks and a slightly different git remote setup.
-
-You can create forks of each Brooklyn repo [in the GitHub UI](https://github.com/apache?query=brooklyn)
-or, if you have the command-line tool `hub` ([described here](https://github.com/github/hub), or `sudo npm install -g hub`),
-by running this command:
-
-{% highlight bash %}
-hub fork; git submodule foreach 'hub fork'
-{% endhighlight %}
-
-The [Get the Code: Basics](index.html) page described how to retrieve the upstream repos,
-but it gave those remotes the name `origin`.
-When using forks, `upstream` is a more accurate name.
-You can rename the origin remotes with:
-
-{% highlight bash %}
-git remote rename origin upstream; git submodule foreach 'git remote rename origin upstream'
-{% endhighlight %}
-
-You'll now likely want to add the remote `origin` for your fork:
-
-{% highlight bash %}
-if [ -z "$GITHUB_ID" ] ; then echo -n "Enter your GitHub ID id: " ; read GITHUB_ID ; fi
-git remote add origin git@github.com:${GITHUB_ID}/brooklyn
-git submodule foreach 'git remote add origin git@github.com:${GITHUB_ID}/${name}'
-{% endhighlight %}
-
-And if you created the fork in the GitHub UI, you may want to create a remote named by your
-GitHub ID as well (if you used `hub` it will have done it for you):
-
-{% highlight bash %}
-if [ -z "$GITHUB_ID" ] ; then echo -n "Enter your GitHub ID id: " ; read GITHUB_ID ; fi
-git remote add ${GITHUB_ID} git@github.com:${GITHUB_ID}/brooklyn
-git submodule foreach 'git remote add ${GITHUB_ID} git@github.com:${GITHUB_ID}/${name}'
-{% endhighlight %}
-
-You probably also want the default `push` target to be your repo in the `origin` remote:
-
-{% highlight bash %}
-git config remote.pushDefault origin; git submodule foreach 'git config remote.pushDefault origin'
-{% endhighlight %}
-
-Optionally, if you're interested in reviewing pull requests,
-you may wish to have `git` automatically check out PR branches:
-
-{% highlight bash %}
-git config --local --add remote.upstream.fetch '+refs/pull/*/head:refs/remotes/upstream/pr/*'
-git submodule foreach "git config --local --add remote.upstream.fetch '+refs/pull/*/head:refs/remotes/upstream/pr/*'"
-git pull ; git submodule foreach 'git pull'
-{% endhighlight %}
-
-And also optionally, to set up the official Apache repo as a remote ---
-useful if GitHub is slow to update (and required if you're a committer):
-
-{% highlight bash %}
-git remote add apache-git https://git-wip-us.apache.org/repos/asf/brooklyn
-git submodule foreach 'git remote add apache-git https://git-wip-us.apache.org/repos/asf/${name}'
-{% endhighlight %}
-
-
-**That's it.** Test that it's all working by browsing the submodules and issuing `git remote -v` and `git pull` commands. Also see the aliases below.
-
-To work on code in a branch, in any of the submodules, you can simply do the following:
-
-{% highlight bash %}
-% git branch my-new-feature-branch upstream/master
-% git checkout my-new-feature-branch
-(make some commits)
-% git push
-To https://github.com/your_account/brooklyn.git
- * [new branch] my-new-feature-branch -> my-new-feature-branch
-{% endhighlight %}
-
-Note how the branch is tracking `upstream/master` for the purpose of `git pull`,
-but a `git push` goes to the fork.
-When you're finished, don't forget to go to the UI of your repo to open a pull request.
-
-
-## Multi-Project Changes
-
-Cross-project changes will require multiple PRs:
-try to minimise these, especially where one depends on another,
-and especially especially where two depend on each other -- that is normally a sign of broken backwards compatibility!
-Open the PRs in dependency order and assist reviewers by including the URLs of any upstream dependency PRs
-in the dependent PR to help reviewers
-(dependency PRs will then include a "mention" comment of the dependent PR).
-
-For information on reviewing and committing PRs, see [the committer's guide]({{site.path.website}}/developers/committers/merging-contributed-code.html).
-
-
-## How We Use Branches
-
-### History, Tags, and Workflow
-
-There are branches for each released version and tags for various other milestones.
-
-As described in more detail [here](git-more.html#how-we-use-branches),
-we primarily use submodule remote branch tracking
-rather than submodule SHA1 ID's.
-
-The history prior to `0.9.0` is imported from the legacy `incubator-brooklyn` repo for reference and history only.
-Visit that repo to build those versions; they are not intended to build here.
-(Although this works:
-`mkdir merged ; for x in brooklyn-* ; do pushd $x ; git checkout 0.8.0-incubating ; cp -r * ../merged ; popd ; cd merged ; mvn clean install`.)
-
-
-### Tracking Branches
-
-Our submodules track **branches**, rather than specific commits,
-although due to the way `git` works there are still references to specific commits.
-
-We track `master` for the master branch and the version branch for other official branches,
-starting with `0.9.0`.
-We update the uber-project recorded SHA reference to subprojects on releases but not regularly --
-that just creates noise and is unnecessary with the `--remote` option on `submodule update`.
-In fact, `git submodule update --remote --merge` pretty much works well;
-the `git sup` alias (below) makes it even easier.
-
-On the other hand, `git status` is not very nice in the uber-project:
-it will show a "new commits" message for submodules,
-unless you're exactly at the uber-project's recorded reference.
-Ignore these.
-It will tell you if you have uncommitted changes,
-but it's not very useful for telling whether you're up to date or if you have newer changes committed
-in the subproject or in your push branch.
-If you go in to each sub-project, `git status` works better, but it can be confusing
-to track which branch each subproject is one.
-A `summary` script is provided below which solves these issues,
-showing useful status across all subprojects.
-
-
-## About Submodules
-
-Submodules can be confusing; if you get stuck the info and references in this section may be useful.
-You can also work [without submodules](#not-using-submodules).
-
-
-### Pitfalls of Submodules
-
-Some of the things to be careful of are:
-
-* **Don't copy submodule directories.** This doesn't act as you'd expect;
- its `.git` record simply points at the parent project's `.git` folder,
- which in turn points back at it. So if you copy it and make changes in the copy,
- it's rather surprising where those changes actually get made.
- Worse, `git` doesn't report errors; you'll only notice it when you see files change bizarrely.
-
-* **Be careful committing in the uber-project.**
- You can update commit IDs, but if these accidentally point to an ID that isn't committed,
- everyone else sees errors.
- It's useful to do this on release (and update the target branch then also)
- and maybe occasionally at other milestones but so much at other times as these ID's
- very quickly become stale on `master`.
-
-
-### Git Submodule References
-
-* [1] [Git SCM Book](https://git-scm.com/book/en/v2/Git-Tools-Submodules)
-* [2] [Medium blog: Mastering Git Submodules](https://medium.com/@porteneuve/mastering-git-submodules-34c65e940407#.r7677prhv)
-* [3] `git submodule --help` section on `update`
-* [4] [StackOverflow: Git Submodules Branch Tag](http://stackoverflow.com/questions/1777854/git-submodules-specify-a-branch-tag/18797720#18797720)
-
-
-## Not Using Submodules
-
-If you don't want to use submodules, you can clone everything as top-level projects with the following:
-
-{% highlight bash %}
-mkdir apache-brooklyn
-cd apache-brooklyn
-git clone http://github.com/apache/brooklyn/
-git clone http://github.com/apache/brooklyn-ui/
-git clone http://github.com/apache/brooklyn-server/
-git clone http://github.com/apache/brooklyn-client/
-git clone http://github.com/apache/brooklyn-docs/
-git clone http://github.com/apache/brooklyn-library/
-git clone http://github.com/apache/brooklyn-dist/
-{% endhighlight %}
-
-
-With one symbolic link in the root `apache-brooklyn/` dir, you can then use a normal `mvn` workflow:
-
-{% highlight bash %}
-ln -s brooklyn/pom.xml .
-mvn clean install
-{% endhighlight %}
-
-
-With minor changes you can follow the instructions for creating forks and getting all updates
-elsewhere on this page.
-
-
-
-## Useful Aliases and Commands
-
-This sets up variants of `pull`, `diff`, and `push` -- called `sup`, `sdiff`, and `spush` -- which act across submodules:
-
-{% highlight bash %}
-# update all modules
-git config --global alias.sup '!git pull && git submodule update --remote --merge --recursive'
-# show diffs across all modules
-git config --global alias.sdiff '!git diff && git submodule foreach "git diff"'
-# return to master in all modules
-git config --global alias.smaster '!git checkout master && echo && git submodule foreach "git checkout master && echo"'
-# push in all modules
-git config --global alias.spush '!git push && git submodule foreach "git push"'
-# show issues in all projects (only works if upstream configured properly for current branch)
-git config --global alias.si '!hub issue && git submodule foreach "hub issue"'
-{% endhighlight %}
-
-
-#### Getting a Summary of Submodules
-
-The `git-summary` script [in the brooklyn-dist/scripts](https://github.com/apache/brooklyn-dist/tree/master/scripts) makes
-working with submodules much more enjoyable.
-Follow the `README` in that directory to add those scripts to your path, and then set up the following git aliases:
-
-{% highlight bash %}
-curl https://gist.githubusercontent.com/ahgittin/6399a29df1229a37b092/raw/208cf4b3ec2ede77297d2f6011821ae62cf9ac0c/git-summary.sh \
- | sudo tee /usr/local/bin/git-summary
-sudo chmod 755 /usr/local/bin/git-summary
-git config --global alias.ss '!git-summary -r'
-git config --global alias.so '!git-summary -r -o'
-{% endhighlight %}
-
-Then `git ss` will give output such as:
-
-{% highlight bash %}
-brooklyn: master <- upstream/master (up to date)
-
-brooklyn-client: master <- upstream/master (up to date)
-
-brooklyn-dist: master <- upstream/master (up to date)
-
-brooklyn-docs: master <- upstream/master (uncommitted changes only)
- M guide/dev/code/submodules.md
-
-brooklyn-library: master <- upstream/master (up to date)
-
-brooklyn-server: master <- upstream/master (up to date)
-
-brooklyn-ui: test <- origin/test (upstream 2 ahead of master)
- > 62c553e Alex Heneveld, 18 minutes ago: WIP 2
- > 22cd0ad Alex Heneveld, 62 minutes ago: WIP 1
- ?? wip-local-untracked-file
-{% endhighlight %}
-
-The command `git so` does the same thing without updating remotes.
-Use it if you want it to run fast, or if you're offline.
-For more information un `git-summary --help`.
-
-
-#### Other Handy Commands
-
-{% highlight bash %}
-# run a git command (eg pull) in each submodule
-git submodule foreach 'git pull'
-
-# iterate across submodules in bash, e.g. doing git status
-for x in brooklyn-* ; do pushd $x ; git status ; popd ; done
-{% endhighlight %}
-
-
-## Legacy Incubator Pull Requests
-
-If you need to apply code changes made pre-graduation, against the incubator repository,
-splitting it up into submodules, it's fairly straightforward:
-
-1. In the incubator codebase, start at its final state: `cd .../incubator-brooklyn && git checkout master && git pull`
-2. Make a branch for your merged changes: `git checkout -b my-branch-merged-master`
-3. Merge or rebase the required commits (resolving conflicts; but don't worry about commit messages): `git merge my-branch`
-4. Create a patch file: `git diff > /tmp/diff-for-my-branch`
-5. Go to the new `brooklyn` uber-project directory.
- Ensure you are at master and all subprojects updated: `cd .../brooklyn/ && git sup`
-6. Apply the patch: `patch -p1 < /tmp/diff-for-my-branch`
-7. Inspect the changes: `git ss`
-8. Test it, commit each changed project on a branch and create pull requests.
- Where applicable, record the original author(s) and message(s) in the commit.
-
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/code/index.md
----------------------------------------------------------------------
diff --git a/website/developers/code/index.md b/website/developers/code/index.md
deleted file mode 100644
index 4cf8391..0000000
--- a/website/developers/code/index.md
+++ /dev/null
@@ -1,83 +0,0 @@
----
-title: Get the Code
-layout: website-normal
-children:
-- { path: git-more.md, title: "Forks, Git-Fu, and More" }
----
-
-## The Basics
-
-The Apache Brooklyn source code is available at [GitHub apache/brooklyn](http://github.com/apache/brooklyn),
-together with many [`brooklyn-*` sub-module projects](https://github.com/apache?query=brooklyn).
-Checkout and build all the submodules with:
-
-{% highlight bash %}
-git clone http://github.com/apache/brooklyn/
-cd brooklyn
-git submodule init
-git submodule update --remote --merge --recursive
-git submodule foreach 'git checkout master'
-
-mvn clean install
-{% endhighlight %}
-
-This will produce an artifact in `brooklyn-dist/dist/brooklyn-dist-1.0.0-SNAPSHOT-dist.tar.gz` <!-- BROOKLYN_VERSION -->
-which you can use [in the usual way]({{ site.path.guide }}/start/running.html).
-Some options which may be useful:
-
-* Use `--depth 1` with `git clone` to skip the history (much faster but your `git log` will be incomplete)
-* Use `-DskipTests` with `mvn` to skip tests (again much faster but it won't catch failures)
-* See below if you don't want to use submodules
-
-Thereafter to update the code in submodules, we strongly recommend doing this:
-
- git pull && git submodule update --remote --merge --recursive
-
-This merges the latest upstream changes into the current branch of each sub-module on your local machine,
-giving nice errors on conflicts.
-It's fine also to do branching and pulling in each submodule,
-but running `update` without these parameters can cause chaos!
-This [page](git-more.html) elaborates on potential chaos and pitfalls,
-and it provides instructions for setting up an alias `git sup` for this command.
-
-
-### If You Can't Stand Submodules
-
-[These instructions](git-more.html#not-using-submodules) can help setting up a local environment
-which does not rely on submodules.
-
-
-### Contributing a Small Change
-
-If you're making a small change in one project, consider just using that project.
-Whether you use this uber-project or not, to [contribute](../how-to-contribute.html)
-you'll need to follow the usual fork->work->push->pull-request process.
-
-To understand where you might want to make your change,
-look at the [code structure]({{ site.path.guide }}/dev/code/structure.html).
-
-
-### Bigger and Regular Changes
-
-Regular contributors will typically have their own fork for each of the submodule projects,
-and will probably want some other settings and tips [as described here](git-more.html).
-
-
-## Next Steps
-
-* See the [detailed Brooklyn & Git guide](git-more.html) to
- [set up forks](git-more.html#set-up-forks) or [handy git aliases](git-more.html#useful-aliases-and-commands)
-
-* Visit the [Developer Guide]({{ site.path.guide }}/dev/) has information on
- [project structure]({{ site.path.guide }}/dev/code/structure.html),
- [Maven setup]({{ site.path.guide }}/dev/env/maven-build.html) and more
-
-* Review [How to Contribute](../how-to-contribute.html)
- to [file your CLA](../how-to-contribute.html#contributor-license-agreement)
- or
- [project structure]({{ site.path.guide }}/dev/code/structure.html),
- [Maven setup]({{ site.path.guide }}/dev/env/maven-build.html) and more
-
-Where things aren't documented **please ask us** at
-[the brooklyn mailing list](https://mail-archives.apache.org/mod_mbox/brooklyn-dev/)
-so we can remedy this!
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/committers/index.md
----------------------------------------------------------------------
diff --git a/website/developers/committers/index.md b/website/developers/committers/index.md
deleted file mode 100644
index a37f7c0..0000000
--- a/website/developers/committers/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-layout: website-normal
-title: Committer Guide
-children:
-- merging-contributed-code.md
-- release-process/index.md
----
-
-These pages contain information that is relevant to people with "committer" status in our project.
-
-{% include list-children.html %}
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/committers/merging-contributed-code.md
----------------------------------------------------------------------
diff --git a/website/developers/committers/merging-contributed-code.md b/website/developers/committers/merging-contributed-code.md
deleted file mode 100644
index a21170a..0000000
--- a/website/developers/committers/merging-contributed-code.md
+++ /dev/null
@@ -1,108 +0,0 @@
----
-layout: website-normal
-title: Merging Contributed Code
----
-
-The Apache Brooklyn Git repositories are hosted in the ASF infrastructure and mirrored to Github. This is the current
-repository layout:
-
-- [Apache](https://git-wip-us.apache.org/repos/asf?s=brooklyn) - the main and official repository
-- [GitHub](https://github.com/apache/brooklyn) - mirror of the ASF repository, used to accept contributions
- and do code reviews
-
-
-Before
-------
-
-For everything except the most trivial changes, the submitter must have a CLA on file. Check the [list of Apache
-committers, and non-commiters with ICLAs on record](https://people.apache.org/committer-index.html) and prompt the
-contributor to file an appropriate CLA if required.
-
-For all significant changes, there must be a Jira issue. If a Jira issue is not referenced in the PR and/or commit
-messages, prompt the contributor to open a Jira issue.
-
-
-Rules of thumb
---------------
-
-1. Every contribution is a piece of intellectual property. This is the precious sustenance that nourishes our
- project. Please treat it with respect.
-2. Always give credit where it is due, ensure every merged commit reflects properly the individual who authored that
- commit. Preserve both the name and email address.
-3. Ensure your name and email address are there as the committer prior to pushing it to the Apache repositories.
-4. Always strive for linear commit history, avoid merge commits while pulling in contributor's changes.
-
-
-Setting up your repository
---------------------------
-
-Follow [these instructions](../code/git-more.html) to configure your local repositories.
-Make sure the canonical ASF repo is enabled as that is where you'll need to push to merge changes,
-and that you are able to fetch pull-requests.
-
-Once that is done, run `git fetch --all` to update from all remote repositories - you will see all the pull requests appear:
-
- * [new ref] refs/pull/98/head -> upstream/pr/1234
- * [new ref] refs/pull/99/head -> upstream/pr/1235
-
-
-Merging a pull request
-----------------------
-
-Fetch the latest remote branches, which will cause a remote branch for the PR to become available to you.
-
- git fetch --all
-
-If you want to inspect a particular PR and/or run tests, check out the branch:
-
- git checkout upstream/pr/1234
-
-To perform the merge, first update your master branch to the latest:
-
- git checkout master
- git pull --rebase
-
-Then merge and push:
-
- git merge --no-ff -m 'This closes #1234' upstream/pr/1234
- git push apache-git master
-
-Note that this commit message is important, as this is what will trigger the
-pull request to be automatically closed, and the `--no-ff` means that a merge
-commit will always be created.
-
-
-Alternative options
--------------------
-
-### Adding the remote reference to the contributor's repository
-
-Fetch the branch of the user you want to merge from (replacing `-PROJECT` as appropriate):
-
- git fetch https://github.com/user-to-merge-from/brooklyn-PROJECT.git branch-to-merge-from
-
-If you commonly merge from a particular user, you'll want to add their repo as a remote to make fetching branches easier:
-
- git remote add user-to-merge-from https://github.com/user-to-merge-from/brooklyn-PROJECT.git
- git fetch user-to-merge-from
-
-
-### Merging from a patch file
-
-Save the patch from the Github patch link (just append '.patch' to the pull request link to get it). This patch will
-keep the authorship of the commit, so we should use it instead of the diff.
-
-Apply the patch preserving the original author:
-
- git am pull-request-9876.patch
-
-
-Additional information
-----------------------
-
-Particularly for new committers, you may find the following ASF information useful:
-
-* [Guide for new project committers](https://www.apache.org/dev/new-committers-guide.html)
-* [Committers FAQ](https://www.apache.org/dev/committers.html)
-* [Git at Apache](https://git-wip-us.apache.org/)
-
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/committers/release-process/announce.md
----------------------------------------------------------------------
diff --git a/website/developers/committers/release-process/announce.md b/website/developers/committers/release-process/announce.md
deleted file mode 100644
index 128fa7d..0000000
--- a/website/developers/committers/release-process/announce.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-layout: website-normal
-title: Announce the release
-navgroup: developers
----
-
-After svnpubsub has updated, the artifacts will be visible at https://www.apache.org/dist/brooklyn/, and distributed to Apache mirrors around the world shortly after.
-
-An announcement email can then be made:
-
-### Subject: [ANNOUNCE] Apache Brooklyn 0.9.0 released
-{% highlight text %}
-The Apache Brooklyn team is proud to announce the latest release of Apache
-Brooklyn 0.9.0.
-
-Apache Brooklyn is a framework for modelling, deploying, and managing
-applications through autonomic blueprints. More details on Apache Brooklyn
-can be found at https://brooklyn.apache.org/
-
-Version 0.9.0 is a major step for Apache Brooklyn, including many new features
-and fixes.
-
-Thanks go to our community for their improvements, feedback and guidance, and
-to Brooklyn’s commercial users for funding much of this development.
-
-As well as a source code release, we offer a full binary distribution
-download, and a full set of Maven artifacts for developers.
-
-Release notes:
-https://brooklyn.apache.org/v/0.9.0/misc/release-notes.html
-
-Download:
-https://brooklyn.apache.org/download/
-
-User guide:
-https://brooklyn.apache.org/v/0.9.0/
-
-Maven artifacts have also been made available on repository.apache.org and
-Maven Central.
-
-Thanks
-Richard Downer
-release manager for 0.9.0
-on behalf of the Brooklyn PPMC
-{% endhighlight %}
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/committers/release-process/environment-variables.md
----------------------------------------------------------------------
diff --git a/website/developers/committers/release-process/environment-variables.md b/website/developers/committers/release-process/environment-variables.md
deleted file mode 100644
index d99473b..0000000
--- a/website/developers/committers/release-process/environment-variables.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-layout: website-normal
-title: Environment variables for the release
-navgroup: developers
----
-
-Many example commands in this section using variable names as placeholders for information that will vary between
-releases. To allow these example commands to run unmodified, set these environment variables appropriately.
-
-{% highlight bash %}
-# The version currently set on the master branch (BROOKLYN_VERSION_BELOW)
-OLD_MASTER_VERSION=1.0.0-SNAPSHOT
-# The next version to be set on the master branch
-NEW_MASTER_VERSION=1.1.0-SNAPSHOT
-
-# The version we are releasing now.
-VERSION_NAME=1.0.0
-
-# The release candidate number we are making now.
-RC_NUMBER=1
-
-# Modules and submodules - these will come in handy later
-SUBMODULES="$( perl -n -e 'if ($_ =~ /path += +(.*)$/) { print $1."\n" }' < .gitmodules )"
-MODULES=". ${SUBMODULES}"
-{% endhighlight %}
-
-Alternatively, use the command `eval $( ./brooklyn-dist/release/environment.sh )` to set these values automatically.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/committers/release-process/fix-release.md
----------------------------------------------------------------------
diff --git a/website/developers/committers/release-process/fix-release.md b/website/developers/committers/release-process/fix-release.md
deleted file mode 100644
index 254d906..0000000
--- a/website/developers/committers/release-process/fix-release.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-layout: website-normal
-title: Fix on the release branch
-navgroup: developers
----
-
-Make whatever changes are necessary on the release branch, supported by discussions on the mailing list.
-
-Repeat the instructions to [make release artifacts](make-release-artifacts.html).
-
-Remember that after the release is done, you should cherry-pick the changes to a new feature branch based on `master`
-and open a pull request, so that the next version will incorporate the bug fixes.
-
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/committers/release-process/index.md
----------------------------------------------------------------------
diff --git a/website/developers/committers/release-process/index.md b/website/developers/committers/release-process/index.md
deleted file mode 100644
index 782e462..0000000
--- a/website/developers/committers/release-process/index.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-layout: website-normal
-title: Release Process
-navgroup: developers
-children:
-- { path: prerequisites.md }
-- { path: environment-variables.md }
-- { path: release-version.md }
-- { path: make-release-artifacts.md }
-- { path: verify-release-artifacts.md }
-- { path: publish-temp.md }
-- { path: vote.md }
-- { path: fix-release.md }
-- { path: publish.md }
-- { path: announce.md }
----
-1. [Preparing for a release](prepare-for-release.html) - How to prepare the project for a release
-2. [Prerequisites](prerequisites.html) - steps that a new release manager must do (but which only need to be done once)
-3. [Set environment variables](environment-variables.html) - many example snippets here use environment variables to
- avoid repetition - this page describes what they are
-4. [Create a release branch and set the version](release-version.html)
-5. [Make the release artifacts](make-release-artifacts.html)
-6. [Verify the release artifacts](verify-release-artifacts.html)
-7. [Publish the release artifacts to the staging area](publish-temp.html)
-8. [Vote on the dev@brooklyn list](vote.html)
- 1. If the vote fails - [fix the release branch](fix-release.html) and resume from step 4
-9. [Publish the release artifacts to the public location](publish.html)
-10. [Announce the release](announce.html)
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/committers/release-process/make-release-artifacts.md
----------------------------------------------------------------------
diff --git a/website/developers/committers/release-process/make-release-artifacts.md b/website/developers/committers/release-process/make-release-artifacts.md
deleted file mode 100644
index 730a7cb..0000000
--- a/website/developers/committers/release-process/make-release-artifacts.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-layout: website-normal
-title: Make the release artifacts
-navgroup: developers
----
-
-A release script is provided in `brooklyn-dist/release/make-release-artifacts.sh`. This script will prepare all the release artifacts.
-It is written to account for several Apache requirements, so you are strongly advised to use it rather than "rolling your own".
-
-The release script will:
-
-- **Create source code and binary distribution artifacts** and place them in a temporary staging directory on your workstation, usually `brooklyn-dist/release/tmp/`.
-- **Create Maven artifacts and upload them to a staging repository** located on the Apache Nexus server.
-
-The script has a single required parameter `-r` which is given the release candidate number - so `-r1` will create
-release candidate 1 and will name the artifacts appropriately.
-
-The script takes a `-n` parameter to work in *dry run* mode; in this mode, the script will NOT upload Maven artifacts
-or commit the release to the Subversion repository. This speeds up the process (the Maven deploy in particular slows
-down the build) and will catch any problems such as PGP or javadoc problems much sooner.
-
-{% highlight bash %}
-# A dry run to test everything is OK
-./brooklyn-dist/release/make-release-artifacts.sh -r$RC_NUMBER -n
-
-# The real build, which will publish artifacts
-./brooklyn-dist/release/make-release-artifacts.sh -r$RC_NUMBER
-{% endhighlight %}
-
-It will show you the release information it has deduced, and ask yes-or-no if it can proceed. Then you will be prompted
-for the passphrase to your GnuPG private key. You should only be asked this question once; the GnuPG agent will cache
-the password for the remainder of the build.
-
-Please note that the script will thoroughly clean the Git workspace of all uncommitted and unadded files **even in dry
-run mode**. Therefore **you really want to run this against a secondary checkout.** It will wipe `.project` files and
-other IDE metadata, and bad things can happen if an IDE tries to write while the script is running. Consider using the
-Vagrant configuration provided.
-
-Please note that uploading to the Nexus staging repository is a slow process. Expect this stage of the build to take
-2 hours.
-
-The release script will:
-
-1. Prepare a staging directory for the source code release
-2. Create .tar.gz and .zip artifacts of the source code
-3. Invoke Maven to build the source code (including running unit tests), and deploy artifacts to a Maven remote
- repository
-4. Save the .tar.gz and .zip artifacts produced by the build of `brooklyn-dist`
-5. For each of the produced files, produce MD5, SHA1, SHA256 and GnuPG signatures
-
-At the end of the script, it will show you the files it has produced and their location.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/committers/release-process/prepare-for-release.md
----------------------------------------------------------------------
diff --git a/website/developers/committers/release-process/prepare-for-release.md b/website/developers/committers/release-process/prepare-for-release.md
deleted file mode 100644
index 36bbf98..0000000
--- a/website/developers/committers/release-process/prepare-for-release.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-layout: website-normal
-title: Prepare the project for a release
-navgroup: developers
----
-
-1. Make sure all unit and integration tests are passing.
-2. Follow the [classic](https://github.com/apache/brooklyn-dist/blob/master/dist/licensing/README.md#update-license-information)
- and [karaf](https://github.com/apache/brooklyn-dist/pull/63) instructions to
- update the licenses of source and binary dependencies.
-3. Update the [release notes](https://github.com/apache/brooklyn-docs/blob/master/guide/misc/release-notes.md). To help
- in the process [list merged PRs](https://gist.github.com/sjcorbett/72ed944b06ce3a138fbe516e8d36f624) after a ceratin date.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/committers/release-process/prerequisites.md
----------------------------------------------------------------------
diff --git a/website/developers/committers/release-process/prerequisites.md b/website/developers/committers/release-process/prerequisites.md
deleted file mode 100644
index 0323428..0000000
--- a/website/developers/committers/release-process/prerequisites.md
+++ /dev/null
@@ -1,150 +0,0 @@
----
-layout: website-normal
-title: Release Prerequisites
-navgroup: developers
----
-
-Subversion repositories for release artifacts
----------------------------------------------
-
-Apache releases are posted to dist.apache.org, which is a Subversion repository.
-
-We have two directories here:
-
-- https://dist.apache.org/repos/dist/release/brooklyn - this is where PMC approved releases go. Do not upload
- here until we have a vote passed on dev@brooklyn. Check out this folder and name it
- `apache-dist-release-brooklyn`
-- https://dist.apache.org/repos/dist/dev/brooklyn - this is where releases to be voted on go. Make the release
- artifact, and post it here, then post the [VOTE] thread with links here. Check out this folder and name it
- `apache-dist-dev-brooklyn`.
-
-Example:
-
-{% highlight bash %}
-svn co https://dist.apache.org/repos/dist/release/brooklyn apache-dist-release-brooklyn
-svn co https://dist.apache.org/repos/dist/dev/brooklyn apache-dist-dev-brooklyn
-{% endhighlight %}
-
-When working with these folders, **make sure you are working with the correct one**, otherwise you may be publishing
-pre-release software to the global release mirror network!
-
-
-Software packages
------------------
-
-The following software packages are required during the build. Make sure you have them installed.
-
-- A Java Development Kit, version 1.8
-- `maven` and `git`
-- Go Language 1.6 - usually provided by the `golang` package on popular distributions
-- The `rpmbuild` command - usually provided by the `rpm` package on popular distributions
-- `xmlstarlet` is required by the release script to process version numbers in `pom.xml` files;
- on mac, `port install xmlstarlet` should do the trick.
-- `zip` and `unzip`
-- `gnupg2`, and `gnupg-agent` if it is packaged separately (it is on Ubuntu Linux)
-- `pinentry` for secure entry of GPG passphrases. If you are building remotely on a Linux machine, `pinentry-curses` is
- recommended; building on a mac, `port install pinentry-mac` is recommended.
-- `md5sum` and `sha1sum` - these are often present by default on Linux, but not on Mac;
- `port install md5sha1sum` should remedy that.
-- if `gpg` does not resolve (it is needed for maven), create an alias or script pointing at `gpg2 "$@"`
-- the `mmv` command (usually in a package named `mmv`) will help with the final steps of the release process
-
-
-GPG keys
---------
-
-The release manager must have a GPG key to be used to sign the release. See below to install `gpg2`
-(with a `gpg` alias). The steps here also assume you have the following set
-(not using `whoami` if that's not appropriate):
-
-{% highlight bash %}
-ASF_USERNAME=`whoami`
-GPG_KEY=$ASF_USERNAME@apache.org
-SVN_USERNAME=$ASF_USERNAME
-{% endhighlight %}
-
-If you have an existing GPG key, but it does not include your Apache email address, you can add your email address as
-described [in this Superuser.com posting](https://superuser.com/a/293283). Otherwise, create a new GPG key giving your
-Apache email address, using `gpg2 --gen-key` then `gpg2 --export-key $GPG_KEY > my-apache.key` and
-`gpg2 --export-secret-key -a $GPG_KEY > my-apache.private.key` in the right directory (`~/.ssh` is a good one).
-
-Upload your GPG public key (complete with your Apache email address on it) to a public keyserver - e.g. run
-`gpg2 --export --armor $GPG_KEY` and paste it into the “submit” box on http://pgp.mit.edu/
-
-Look up your key fingerprint with `gpg2 --fingerprint $GPG_KEY` - it’s the long sequence of hex numbers
-separated by spaces. Log in to [https://id.apache.org/](https://id.apache.org/) then copy-and-paste the fingerprint into
-“OpenPGP Public Key Primary Fingerprint”. Submit.
-
-Now add your key to the `apache-dist-release-brooklyn/KEYS` file:
-
-{% highlight bash %}
-cd apache-dist-release-brooklyn
-(gpg2 --list-sigs $ASF_USERNAME@apache.org && gpg2 --armor --export $ASF_USERNAME@apache.org) >> KEYS
-svn --username $SVN_USERNAME --no-auth-cache commit -m "Update brooklyn/KEYS for $GPG_KEY"
-{% endhighlight %}
-
-References:
-
-* [Post on the general@incubator list](https://mail-archives.apache.org/mod_mbox/incubator-general/201410.mbox/%3CCAOGo0VawupMYRWJKm%2Bi%2ByMBqDQQtbv-nQkfRud5%2BV9PusZ2wnQ%40mail.gmail.com%3E)
-* [GPG cheatsheet](http://irtfweb.ifa.hawaii.edu/~lockhart/gpg/gpg-cs.html)
-
-We recommend the use of the `gpg-agent`, as the release process invokes gpg to sign a large number of artifacts, one at
-a time. The agent stores its configuration in `~/.gnupg/gpg-agent.conf`. A sample configuration is shown below; it uses
-the Mac OSX `pinentry-mac` program which can be obtained through MacPorts or other sources. For other platforms you will
-need to change this; sometimes you can omit it completely and your OS will pick a suitable alternative. The following
-two lines cause your passphrase to be cached in memory for a limited period; it will expire from the cache 30 minutes
-after it was most recently accessed, or 4 hours after it was first cached.
-
-~~~
-pinentry-program /Applications/MacPorts/pinentry-mac.app/Contents/MacOS/pinentry-mac
-default-cache-ttl 1800
-max-cache-ttl 14400
-~~~
-
-If you experience trouble with PGP subsequently (when running maven):
-
-* See [GnuPG/Pinentry Enigmail debugging](https://www.enigmail.net/support/gnupg2_issues.php) for tips on diagnosing gpg-agent communication (from the process to this agent and from this agent to the pinentry program)
-* See [GnuPG Agent Options](https://www.gnupg.org/documentation/manuals/gnupg/Agent-Options.html) for extended gpg-agent debug
-
-
-Maven configuration
--------------------
-
-The release will involve uploading artifacts to Apache's Nexus instance - therefore you will need to configure your
-Maven install with the necessary credentials.
-
-You will need to add something like this to your `~/.m2/settings.xml` file:
-
-{% highlight xml %}
-<?xml version="1.0"?>
-<settings xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd"
- xmlns="http://maven.apache.org/SETTINGS/1.1.0"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
-
- <!-- ... -->
-
- <servers>
-
- <!-- ... -->
-
- <!-- Required for uploads to Apache's Nexus instance. These are LDAP credentials - the same credentials you
- - would use to log in to Git and Jenkins (but not JIRA) -->
- <server>
- <id>apache.snapshots.https</id>
- <username>xxx</username>
- <password>xxx</password>
- </server>
- <server>
- <id>apache.releases.https</id>
- <username>xxx</username>
- <password>xxx</password>
- </server>
-
- <!-- ... -->
-
- </servers>
-
- <!-- ... -->
-
-</settings>
-{% endhighlight %}
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/committers/release-process/publish-temp.md
----------------------------------------------------------------------
diff --git a/website/developers/committers/release-process/publish-temp.md b/website/developers/committers/release-process/publish-temp.md
deleted file mode 100644
index 278ce73..0000000
--- a/website/developers/committers/release-process/publish-temp.md
+++ /dev/null
@@ -1,57 +0,0 @@
----
-layout: website-normal
-title: Publish to the staging area
-navgroup: developers
----
-
-Update the canonical Git repository
------------------------------------
-
-Make a signed tag for this release candidate:
-
-{% highlight bash %}
-for m in ${MODULES}; do ( cd $m && git tag -s -m "Tag release ${VERSION_NAME} release candidate ${RC_NUMBER}" rel/apache-brooklyn-${VERSION_NAME}-rc${RC_NUMBER} ); done
-{% endhighlight %}
-
-Now push the release branch and release candidate tag:
-
-{% highlight bash %}
-for m in ${MODULES}; do ( cd $m && git push apache-git $VERSION_NAME && git push apache-git rel/apache-brooklyn-${VERSION_NAME}-rc${RC_NUMBER} ); done
-{% endhighlight %}
-
-
-Publish the source and binary distributions to the pre-release area
--------------------------------------------------------------------
-
-You will need to have checked out the Apache distribution Subversion repository located at
-https://dist.apache.org/repos/dist/dev/brooklyn. Please refer to [Prerequisites](prerequisites.html) for
-information.
-
-In your workspace for the `dist.apache.org` repo, create a directory with the artifact name and version:
-
-{% highlight bash %}
-mkdir apache-brooklyn-${VERSION_NAME}-rc${RC_NUMBER}
-{% endhighlight %}
-
-Copy into this directory all of the artifacts from the previous step - `-src` and `-bin`, `.tar.gz`, `.zip` and `.rpm`,
-and all associated `.md5`, `.sha1`, `.sha256` and `.asc` signatures. Then commit:
-
-{% highlight bash %}
-svn add apache-brooklyn-${VERSION_NAME}-rc${RC_NUMBER}
-svn commit --username $SVN_USERNAME --no-auth-cache --message "Add apache-brooklyn-${VERSION_NAME}-rc${RC_NUMBER} to dist/dev/brooklyn"
-{% endhighlight %}
-
-These steps can be performed as part of the `make-release-artifacts.sh` script used earlier
-if `${APACHE_DIST_SVN_DIR}` points to the appropriate subversion directory.
-
-
-Close the staging repository on Apache's Nexus server
------------------------------------------------------
-
-*Closing* the staging repository locks it from further changes, and provides a public URL for the repository that can
-be used for downloading the artifacts.
-
-Go to the Apache Nexus server at [https://repository.apache.org/](https://repository.apache.org/) and log in using the
-link in the top right (the credentials are the same as your Git and Jenkins credentials). Go to the "Staging
-Repositories" page, and tick the repository with the name starting `orgapachebrooklyn`. Click the **Close** button.
-Provide a description which includes the version and release candidate, e.g. `Apache Brooklyn 0.10.0-rc1`.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/committers/release-process/publish.md
----------------------------------------------------------------------
diff --git a/website/developers/committers/release-process/publish.md b/website/developers/committers/release-process/publish.md
deleted file mode 100644
index 86211e8..0000000
--- a/website/developers/committers/release-process/publish.md
+++ /dev/null
@@ -1,174 +0,0 @@
----
-layout: website-normal
-title: Publish to the public
-navgroup: developers
----
-
-Update the canonical Git repository
------------------------------------
-
-Make a signed tag for this release:
-
-{% highlight bash %}
-for m in ${MODULES}; do ( cd $m && git tag -s -m "Tag release ${VERSION_NAME}" rel/apache-brooklyn-${VERSION_NAME} rel/apache-brooklyn-${VERSION_NAME}-rc${RC_NUMBER} ); done
-{% endhighlight %}
-
-Now push the release tag:
-
-{% highlight bash %}
-for m in ${MODULES}; do ( cd $m && git push apache-git rel/apache-brooklyn-${VERSION_NAME} ); done
-{% endhighlight %}
-
-Publish the source and binary distributions to the pre-release area
--------------------------------------------------------------------
-
-You will need to have checked out the Apache distribution Subversion repository located at
-https://dist.apache.org/repos/dist/release/brooklyn. Please refer to [Prerequisites](prerequisites.html) for
-information.
-
-In your workspace for the `dist.apache.org` repo, create a directory with the artifact name and version:
-
-{% highlight bash %}
-mkdir apache-brooklyn-${VERSION_NAME}
-{% endhighlight %}
-
-Refer back to the pre-release area Subversion (see [Publish to the staging area](publish-temp.html)), and copy all of
-the release candidate artifacts - `-src` and `-bin`, `.tar.gz` and `.zip`, and all associated `.md5`, `.sha1`, `.sha256`
-and `.asc` signatures - into this new folder.
-
-Rename all of the files to remove the `-rcN` designation:
-
-{% highlight bash %}
-for f in *; do mv $f ${f//-rc${RC_NUMBER}/}; done
-{% endhighlight %}
-
-The hash files will need patching to refer to the filenames without the `-rcN` designation:
-
-{% highlight bash %}
-sed -i.bak 's/-rc'$RC_NUMBER'-/-/' *.md5 *.sha1 *.sha256
-rm -f *.bak
-{% endhighlight %}
-
-Note that the PGP signatures do not embed the filename so they do not need to be modified
-
-As a final check, re-test the hashes and signatures:
-
-{% highlight bash %}
-for artifact in $(find * -type f ! \( -name '*.asc' -o -name '*.md5' -o -name '*.sha1' -o -name '*.sha256' \) ); do
- md5sum -c ${artifact}.md5 && \
- shasum -a1 -c ${artifact}.sha1 && \
- shasum -a256 -c ${artifact}.sha256 && \
- gpg2 --verify ${artifact}.asc ${artifact} \
- || { echo "Invalid signature for $artifact. Aborting!"; break; }
-done
-{% endhighlight %}
-
-(You may get warnings such as: `gpg: WARNING: This key is not certified with a trusted signature!`
-and `There is no indication that the signature belongs to the owner.` This happens if you have not trusted
-the person's key. A key-signing party is a good way to extend this web of trust).
-
-
-Then, add them to Subversion and commit.
-
-{% highlight bash %}
-svn add apache-brooklyn-${VERSION_NAME}
-svn commit --message "Add apache-brooklyn-${VERSION_NAME} to dist/release/brooklyn"
-{% endhighlight %}
-
-
-Publish the staging repository on Apache's Nexus server
--------------------------------------------------------
-
-*Releasing* the staging repository causes its contents to be copied to the main Apache Nexus repository. This in turn
-is propagated to Maven Central, meaning all of our users can access the artifacts using a default Maven configuration
-(there's no need to add a `<repository>` to their `pom.xml` or `~/.m2/settings.xml`).
-
-Go to the Apache Nexus server at [https://repository.apache.org/](https://repository.apache.org/) and log in using the
-link in the top right (the credentials are the same as your Git and Jenkins credentials). Go to the "Staging
-Repositories" page, and tick the repository with the name starting `orgapachebrooklyn`. Click the **Release** button.
-Provide a description which includes the version, e.g. `Apache Brooklyn 0.7.0-incubating`.
-
-Note there is only one orgapachebrooklyn staging repository at a time; this will be the one created for the release
-candidate with whatever name was used there (e.g. it might include "rc" in the name). If you really want, you can
-double-check under the "content" that brooklyn-dist has artifacts without rc in the name.
-
-
-Update the website
-------------------
-
-*Instructions on uploading to the website are beyond the scope of these instructions. Refer to the
-[appropriate instructions](https://github.com/apache/brooklyn-docs/tree/master/README.md).*
-
-### Publish documentation for the new release
-
-Go to the release branch and perform a build:
-
-{% highlight bash %}
-git checkout ${VERSION_NAME}
-mvn clean install -DskipTests
-{% endhighlight %}
-
-Ensure the SVN repo is up-to-date (very painful otherwise!)
-
-{% highlight bash %}
-cd ${BROOKLYN_SITE_DIR-../brooklyn-site-public}
-svn up
-cd -
-{% endhighlight %}
-
-Generate the permalink docs for the release:
-
-{% highlight bash %}
-cd brooklyn-docs
-./_build/build.sh guide-version --install
-{% endhighlight %}
-
-Now publish _site/v/*${VERSION_NAME}* to the public website.
-
-Update the "latest" docs to this release:
-
-{% highlight bash %}
-./_build/build.sh guide-latest --install
-{% endhighlight %}
-
-Now publish _site/v/latest to the public website:
-
-{% highlight bash %}
-cd ${BROOKLYN_SITE_DIR-../../brooklyn-site-public}
-svn add * --force
-export DELETIONS=$( svn status | sed -e '/^!/!d' -e 's/^!//' )
-if [ ! -z "${DELETIONS}" ] ; then svn rm ${DELETIONS} ; fi
-{% endhighlight %}
-
-
-### Update the main website to link to the new release
-
-This should be done on the `master` branch:
-
-{% highlight bash %}
-git checkout master
-{% endhighlight %}
-
-1. Edit the file `brooklyn-docs/_config.yml` - change `brooklyn-stable-version` to be the newly-release version, and
- `brooklyn-version` to be the current SNAPSHOT version on the master branch.
-2. Edit the file `brooklyn-docs/website/download/verify.md` to add links to the MD5/SHA1/SHA256 hashes and PGP signatures for the
- new version.
-3. Edit the file `brooklyn-docs/website/meta/versions.md` to add the new version.
-4. Build the updated site with `./_build/build.sh website-root --install`.
-5. Publish to the public website.
-6. Commit your changes to master, e.g. with a message like "Update latest docs to 0.8.0-incubating"
-
-
-Tag the release in git
-----------------------
-
-Make a signed tag for this release, based on the tag for the release candidate, and then push the tag:
-
-{% highlight bash %}
-git tag -s -m "Tag release ${VERSION_NAME}" apache-brooklyn-${VERSION_NAME} apache-brooklyn-${VERSION_NAME}-rc${RC_NUMBER}
-git push apache apache-brooklyn-${VERSION_NAME}
-{% endhighlight %}
-
-Note the tag `apache-brooklyn-${VERSION_NAME}-rc${RC_NUMBER}` should have been created as part of the
-RC creation - see [make-release-artifacts](make-release-artifacts.html).
-
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/committers/release-process/release-version.md
----------------------------------------------------------------------
diff --git a/website/developers/committers/release-process/release-version.md b/website/developers/committers/release-process/release-version.md
deleted file mode 100644
index 36bbc40..0000000
--- a/website/developers/committers/release-process/release-version.md
+++ /dev/null
@@ -1,94 +0,0 @@
----
-layout: website-normal
-title: Release branch and set version
-navgroup: developers
----
-
-This will allow development to continue on master without affecting the release; it also allows quick-fixes to the
-release branch to address last-minute problems (which must of course be merged/cherry-picked back into master later).
-
-Do not use -rc1, -rc2 etc. in version strings. Use the version that will be the actual published version. (The artifacts
-that get uploaded to the dist.apache.org/dev will include “-rc1” etc. in the folder name, but the contents will be *as
-final*. Therefore, turning the rc into the final is simply a case of taking the rc file and publishing it to the release
-folder with the correct name.)
-
-References:
-
-- [Post on general@incubator](https://mail-archives.apache.org/mod_mbox/incubator-general/201409.mbox/%3CCAK2iWdS1H9dkJcSdohky6hFqJdP0XyuhAG%2B%3D1Aspxcjt5RmnJw%40mail.gmail.com%3E)
-- [Post on general@incubator](https://mail-archives.apache.org/mod_mbox/incubator-general/201409.mbox/%3CCAOGo0VaEz4cEUbgMgqhh3hiiiubnspiGkQ%3DQv08bOwPqRtzAvQ%40mail.gmail.com%3E)
-
-
-Create the release branch and set the release version number
-------------------------------------------------------------
-
-Create a branch with the same name as the version, based off master:
-
-{% highlight bash %}
-git checkout master
-git pull --rebase # assumes that the Apache canonical repository is the default upstream for your master - amend if necessary
-git submodule update --remote --merge --recursive
-for m in $MODULES; do ( cd $m && git checkout master && git checkout -b $VERSION_NAME ); done
-{% endhighlight %}
-
-Now change the version numbers in this branch throughout the project using the script `brooklyn-dist/release/change-version.sh` and commit it:
-
-{% highlight bash %}
-./brooklyn-dist/release/change-version.sh BROOKLYN $OLD_MASTER_VERSION $VERSION_NAME
-# Now inspect the changes and ensure there are no surprises
-find . -name "*.bak" -delete
-for m in $SUBMODULES; do ( cd $m && git add . && git commit -m "Change version to $VERSION_NAME" ); done
-git add $SUBMODULES && git commit -m "Update submodules to $VERSION_NAME"
-git add . && git commit -m "Change version to $VERSION_NAME"
-{% endhighlight %}
-
-If you are happy with the changes, push them:
-
-{% highlight bash %}
-for m in $MODULES; do ( cd $m && git push apache-git $VERSION_NAME ); done
-{% endhighlight %}
-
-
-Update the version on master
-----------------------------
-
-The `master` branch will now need updating to refer to the next planned version. (This step is not required if making
-a "milestone" release or similar.)
-
-The release notes should be cleared out and the version history augmented with the new version.
-
-Example:
-
-{% highlight bash %}
-for m in $MODULES; do ( cd $m && git checkout master ); done
-./brooklyn-dist/release/change-version.sh BROOKLYN $OLD_MASTER_VERSION $NEW_MASTER_VERSION
-# Now inspect the changes and ensure there are no surprises
-{% endhighlight %}
-
-Open `brooklyn-docs/guide/misc/release-notes.md` and `brooklyn-docs/website/meta/versions.md` in your favourite editor and amend.
-For release notes this means bumping the reference to the previous version in the "Backwards Compatibility" section
-and putting some placeholder text elsewhere.
-
-Then:
-
-{% highlight bash %}
-find . -name "*.bak" -delete
-for m in $SUBMODULES; do ( cd $m && git add . && git commit -m "Change version to $NEW_MASTER_VERSION" ); done
-git add $SUBMODULES && git commit -m "Update submodules to $NEW_MASTER_VERSION"
-git add . && git commit -m "Change version to $NEW_MASTER_VERSION"
-{% endhighlight %}
-
-If you are happy with the changes, push them:
-
-{% highlight bash %}
-for m in $MODULES; do ( cd $m && git push apache-git master ); done
-{% endhighlight %}
-
-
-Switch back to the release branch
----------------------------------
-
-Move back to the release branch:
-
-{% highlight bash %}
-for m in $MODULES; do ( cd $m && git checkout $VERSION_NAME ); done
-{% endhighlight %}
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/committers/release-process/verify-release-artifacts.md
----------------------------------------------------------------------
diff --git a/website/developers/committers/release-process/verify-release-artifacts.md b/website/developers/committers/release-process/verify-release-artifacts.md
deleted file mode 100644
index c5020bf..0000000
--- a/website/developers/committers/release-process/verify-release-artifacts.md
+++ /dev/null
@@ -1,216 +0,0 @@
----
-layout: website-normal
-title: Verify the release artifacts
-navgroup: developers
----
-
-Below is described a series of "sanity checks" that should be performed before uploading the artifacts to the
-pre-release area. They are also useful for community members that want to check the artifact before voting (community
-members may also want to check the [list of required software packages](prerequisites.html#software-packages) to ensure
-they have the GnuPG and md5sum/sha1sum installed.
-
-Setup
------
-
-The scripts below use several environment variables to cut out repetition and enable easy repeatability for the next
-release. You should determine the following information and set your environment:
-
-{% highlight bash %}
-# The version we are releasing now.
-VERSION_NAME=0.10.0
-
-# The release candidate number we are making now.
-RC_NUMBER=1
-
-# A reference to your Git repository for Brooklyn
-BASE_REPO=~/repos/apache-asf/brooklyn
-
-# The Git commit hash from which the release was made - get this from the release script, or the Release Manager's announcement
-GIT_COMMIT=edcf928ee65cc29a84376c822759e468a9f016fe
-{% endhighlight %}
-
-Import the PGP keys of the release Managers:
-
-{% highlight bash %}
-curl https://dist.apache.org/repos/dist/release/brooklyn/KEYS | gpg2 --import
-{% endhighlight %}
-
-
-Download the artifacts
-----------------------
-
-If you've just built the RC, simply go to that directory and skip this step.
-
-If you're verifying a build someone else has made, first download the files including all keys using:
-
-{% highlight bash %}
-TEMP_DIR=~/tmp/brooklyn/release/${VERSION_NAME}-rc${RC_NUMBER}
-BASE_NAME=apache-brooklyn-${VERSION_NAME}-rc${RC_NUMBER}
-BASE_URL=https://dist.apache.org/repos/dist/dev/brooklyn/${BASE_NAME}/
-
-mkdir -p ${TEMP_DIR}
-cd ${TEMP_DIR}
-curl -s $BASE_URL | \
- grep href | grep -v '\.\.' | \
- sed -e 's@.*href="@'$BASE_URL'@' | \
- sed -e 's@">.*@@' | \
- xargs -n 1 curl -O
-{% endhighlight %}
-
-(Alternatively if you have `apache-dist-dev-repo` checked out,
-you can do an `svn up` in there and `cd apache-brooklyn-${VERSION_NAME}-rc${RC_NUMBER}`.)
-
-Verify presence of NOTICE & LICENSE
------------------------------------
-Check that all archives are correctly annotated with license information.
-Check NOTICE is included:
-
-{% highlight bash %}
-for ARCHIVE in $(find * -type f ! \( -name '*.asc' -o -name '*.md5' -o -name '*.sha1' -o -name '*.sha256' \) ); do
- REL_ARCHIVE=${ARCHIVE/-rc?}
- case $ARCHIVE in
- *.tar.gz)
- LIST="tar -tvf"
- PREFIX=${REL_ARCHIVE%.tar.gz}
- ;;
- *.zip)
- LIST="unzip -Zl"
- PREFIX=${REL_ARCHIVE%.zip}
- ;;
- *.rpm)
- LIST="rpm -qlp"
- PREFIX="/opt/brooklyn"
- ;;
- *)
- echo "Unrecognized file type $ARCHIVE. Aborting!"
- exit 1
- ;;
- esac
- $LIST $ARCHIVE | grep "$PREFIX/NOTICE" && \
- $LIST $ARCHIVE | grep "$PREFIX/LICENSE" \
- || { echo "Missing LICENSE or NOTICE in $ARCHIVE. Aborting!"; break; }
-done
-{% endhighlight %}
-
-Verify the hashes and signatures of artifacts
----------------------------------------------
-
-Then check the hashes and signatures, ensuring you get a positive message from each one:
-
-{% highlight bash %}
-for artifact in $(find * -type f ! \( -name '*.asc' -o -name '*.md5' -o -name '*.sha1' -o -name '*.sha256' \) ); do
- md5sum -c ${artifact}.md5 && \
- shasum -a1 -c ${artifact}.sha1 && \
- shasum -a256 -c ${artifact}.sha256 && \
- gpg2 --verify ${artifact}.asc ${artifact} \
- || { echo "Invalid signature for $artifact. Aborting!"; break; }
-done
-{% endhighlight %}
-
-
-Verify expanded source archive matches contents of RC tag
----------------------------------------------------------
-
-These commands will compare the contents of the source release to the contents of the equivalent Git commit. Note that
-there will be some differences: we cannot release binary files in the source release, so some test artifacts will
-appear to be missing from the source release, and the source release excludes the documentation, website and release
-scripts.
-
-{% highlight bash %}
-cd $BASE_REPO
-git checkout $GIT_COMMIT
-git clean -d -f -x # WARNING: this will forcibly clean your workspace!
-
-cd $TEMP_DIR
-mkdir unpacked-src
-# Either:
-tar xzf ${BASE_NAME}-src.tar.gz -C unpacked-src/
-# or:
-unzip ${BASE_NAME}-src.zip -d unpacked-src/
-# (or preferably both!)
-diff -qr unpacked-src/$BASE_NAME $BASE_REPO
-{% endhighlight %}
-
-Check for files with invalid headers in source archive
-------------------------------------------------------
-
-{% highlight bash %}
-grep -rL "Licensed to the Apache Software Foundation" * | less
-{% endhighlight %}
-
-Check for binary files in source archive
------------------------------------------
-
-Look for files which are created/compiled based on other source files in the distribution.
-"Primary" binary files like images are acceptable.
-
-{% highlight bash %}
-find . | xargs -n1 file | awk -F $':' ' { t = $1; $1 = $2; $2 = t; print; } ' | sort | less
-{% endhighlight %}
-
-
-
-Verify the operation of the binary distribution
------------------------------------------------
-
-{% highlight bash %}
-cd $TEMP_DIR
-mkdir unpacked-bin
-# Either:
-tar xzf ${BASE_NAME}-bin.tar.gz -C unpacked-bin/
-# or:
-unzip ${BASE_NAME}-bin.tar.gz -d unpacked-bin/
-# (or preferably both!)
-cd unpacked-bin
-./bin/brooklyn launch
-{% endhighlight %}
-
-Try deploying a simple app, such as the YAML:
-
-{% highlight yaml %}
-location: localhost
-services:
-- type: org.apache.brooklyn.entity.webapp.jboss.JBoss7Server
-{% endhighlight %}
-
-
-Inspect the Maven staging repository
-------------------------------------
-
-Go to the Apache Nexus server at [https://repository.apache.org/](https://repository.apache.org/) and log in using the
-link in the top right (the credentials are the same as your Git and Jenkins credentials). Go to the "Staging
-Repositories" page, and click the repository with the name starting `orgapachebrooklyn`.
-
-Give this a brief inspection to ensure that it looks reasonable. In particular:
-
-- The expected projects are there. (There is no need to do an exhaustive check - but if there is only a couple of
- projects there, then something has clearly gone wrong!)
-- The projects contain artifacts with the expected version number.
-- The artifacts for a project look reasonable - and there is a `.asc` file (detached PGP cleartext signature) for each
- artifact.
-
-
-About the sanity check
-----------------------
-
-This is the most basic sanity check. This is now suitable to be uploaded to the pre-release area and an announcement
-made with voting open. This is then the point for the RM and the community to perform more detailed testing on the RC
-artifacts and submit bug reports and votes.
-
-
-Automated sanity check script available at brooklyn-dist/release/verity_brooklyn_rc.sh
-
-
-If the sanity check fails
--------------------------
-
-Note the problems causing the failure, and file bug reports, start mailing list discussions etc., as appropriate.
-
-#### For the release manager who was preparing an RC for upload
-
-You should completely discard the defective artifacts.
-
-You will also need to drop the Maven staging repository on Apache's Nexus server: go to the Apache Nexus server at
-[https://repository.apache.org/](https://repository.apache.org/) and log in using the link in the top right (the
-credentials are the same as your Git and Jenkins credentials). Go to the "Staging Repositories" page, and tick the
-repository with the name starting `orgapachebrooklyn`. Click the **Drop** button.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/committers/release-process/vote.md
----------------------------------------------------------------------
diff --git a/website/developers/committers/release-process/vote.md b/website/developers/committers/release-process/vote.md
deleted file mode 100644
index 8030dee..0000000
--- a/website/developers/committers/release-process/vote.md
+++ /dev/null
@@ -1,187 +0,0 @@
----
-layout: website-normal
-title: Vote on dev@brooklyn
-navgroup: developers
----
-
-Start the vote
---------------
-
-A script to generate the voting email can be found in `brooklyn-dist/release/print-vote-email.sh`,
-taking a single argument being the staging repo ID. For example:
-
- brooklyn-dist/release/print-vote-email.sh orgapachebrooklyn-1234 | pbcopy
-
-You should move the subject and put your name at the end, and simply eyeball the rest. This should be sent to **dev@brooklyn.apache.org**.
-
-Alternatively, copy-paste the e-mail template below, being sure to substitute:
-
-- VERSION_NAME
-- RC_NUMBER
-- URLs containing version numbers
-- URL for your own PGP key
-- Checksums
-- URL for the Maven staging repository
-
-### Subject: [VOTE] Release Apache Brooklyn ${VERSION_NAME} [rc${RC_NUMBER}]
-
-{% highlight text %}
-This is to call for a vote for the release of Apache Brooklyn ${VERSION_NAME}.
-
-This release comprises of a source code distribution, and a corresponding
-binary distribution, and Maven artifacts.
-
-The source and binary distributions, including signatures, digests, etc. can
-be found at:
-https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-${VERSION_NAME}-rc${RC_NUMBER}
-
-The artifact SHA-256 checksums are as follows:
-c3b5c581f14b44aed786010ac7c8c2d899ea0ff511135330395a2ff2a30dd5cf *apache-brooklyn-${VERSION_NAME}-rc${RC_NUMBER}-bin.tar.gz
-cef49056ba6e5bf012746a72600b2cee8e2dfca1c39740c945c456eacd6b6fca *apache-brooklyn-${VERSION_NAME}-rc${RC_NUMBER}-bin.zip
-8069bfc54e7f811f6b57841167b35661518aa88cabcb070bf05aae2ff1167b5a *apache-brooklyn-${VERSION_NAME}-rc${RC_NUMBER}-src.tar.gz
-acd2229c44e93e41372fd8b7ea0038f15fe4aaede5a3bcc5056f28a770543b82 *apache-brooklyn-${VERSION_NAME}-rc${RC_NUMBER}-src.zip
-
-The Nexus staging repository for the Maven artifacts is located at:
-https://repository.apache.org/content/repositories/orgapachebrooklyn-1004
-
-All release artifacts are signed with the following key:
-https://people.apache.org/keys/committer/richard.asc
-
-KEYS file available here:
-https://dist.apache.org/repos/dist/release/brooklyn/KEYS
-
-The artifacts were built from Git commit ID
-24a23c5a4fd5967725930b8ceaed61dfbd225980
-https://git-wip-us.apache.org/repos/asf?p=brooklyn.git;a=commit;h=24a23c5a4fd5967725930b8ceaed61dfbd225980
-
-
-Please vote on releasing this package as Apache Brooklyn ${VERSION_NAME}.
-
-The vote will be open for at least 72 hours.
-[ ] +1 Release this package as Apache Brooklyn ${VERSION_NAME}
-[ ] +0 no opinion
-[ ] -1 Do not release this package because ...
-
-
-Thanks,
-[Release manager name]
-{% endhighlight %}
-
-Discuss the vote
-----------------
-Open a parallel thread for a place to discuss the vote. Name it [DISCUSS]<Subject of the voting email>, replying
-to the vote email. Here's an example body for the email.
-
-{% highlight text %}
-This thread is for discussions related to the release vote.
-
-I should clarify what we are looking for in a release vote. Particularly,
-we are looking for people to download,validate, and test the release.
-Only if you are satisfied that the artifacts are correct and the quality is
-high enough, should you make a "+1" vote. Alongside your vote you should list
-the checks that you made.
-
-Here is a good example: http://markmail.org/message/gevsz2pdciraw6jw
-
-The vote is not simply about "the master branch contains the features I wanted" -
-it is about making sure that *these* artifacts are *correct* (e.g. they are
-not corrupted, hashes and signatures pass) and are of *sufficiently high
-quality* to be stamped as an official release of The Apache Software Foundation.
-
-Why test the artifacts when master is looking good? Here are some reasons:
-
-- somebody could have made a commit that broke it, since you last git pulled
-- the release branch could have been made at the wrong point, or inconsistently
- between all of the submodules
-- something in the release process could have broken it
-- I could have made a mistake and corrupted the files
-- a problem with the Apache infrastructure could mean that the release files are
- unobtainable or corrupted
-
-This is why the release manager needs you to download the actual release
-artifacts and try them out.
-
-The way Apache works can be a bit arcane sometimes, but it's all done with
-a reason. If the vote passes then the contents of the email and its links
-become "endorsed" by The Apache Software Foundation, and the Foundation will
-take on legal liability for them, forever.
-
-And of course we want the best possible experience for our users - so we need
-the actual release files to be tested manually to make sure that a mistake does
-not ruin the experience for users.
-
-So if you can spare an hour or more to download some of the artifacts and try
-them out, then it will be *very* useful! The vote lasts for three days so
-there's no need to rush to get a vote in.
-
-Thanks!
-[Release manager name]
-{% endhighlight %}
-
-Reply to vote
--------------
-
-Here is an example checklist (thanks Andrew Phillips for your thoroughness on jclouds!)
-
-Checklist (all items optional, mark only those personally verified):
-
-- [ ] Checksums and PGP signatures are valid.
-- [ ] Expanded source archive matches contents of RC tag.
-- [ ] Expanded source archive builds and passes tests.
-- [ ] LICENSE is present and correct.
-- [ ] NOTICE is present and correct, including copyright date.
-- [ ] All files have license headers where appropriate.
-- [ ] All dependencies have compatible licenses.
-- [ ] No compiled archives bundled in source archive.
-- [ ] I follow this project's commits list.
-
-
-Count the vote results
-----------------------
-
-If the release email stated a deadline (normally 72 hours), then you should wait at least that long. If there are
-insufficient votes you may need to extend the deadline - as an informal aim, we should look to get 2/3rds of the PPMC
-and some mentors voting +1. If a release-critical issue is raised and confirmed, then you may end the vote early with a
-negative result.
-
-Votes from PPMC members are binding; votes from others are non-binding. In the case of non-binding negative votes,
-please consider these carefully even if you are not bound by them.
-
-If there are any negative or zero votes, consider these carefully. Aim to “convert” negative or zero votes into positive
-by addressing any concerns. A negative vote is not necessarily a veto[citation required], but it should be a clear
-warning sign to not proceed if somebody strongly believes that the release should not proceed as is.
-
-Finally, count up the +1s and separate into binding (PPMC) and non-binding.
-
-Email the vote result
----------------------
-
-This is a new email thread with a different subject
-(the same as before with `[RESULT]` prepended).
-
-Note that you must find the URL for the previous thread at [mail-archives.apache.org](https://mail-archives.apache.org/).
-
-### Subject: [RESULT]\[VOTE] Release Apache Brooklyn ${VERSION_NAME} [rc${RC_NUMBER}]
-
-{% highlight text %}
-The vote for releasing Apache Brooklyn ${VERSION_NAME} passed with 5 binding +1s, 1 non-binding +1s, and no 0 or -1.
-
-Vote thread link:
-https://mail-archives.apache.org/mod_mbox/brooklyn-dev/201507.mbox/%3CCABQFKi1WapCMRUqQ93E7Qow5onKgL3nyG3HW9Cse7vo%2BtUChRQ%40mail.gmail.com%3E
-
-Binding +1s:
-Hadrian Zbarcea (IPMC)
-Richard Downer
-Sam Corbett
-Aled Sage
-Andrea Turli
-
-Non-binding +1s:
-Ciprian Ciubotariu
-
-Thanks to everyone that tested our release and voted.
-
-Next, the release manager will publish the artifacts, and make an announcement to this list once they are available from
-the Apache mirrors.
-
-{% endhighlight %}
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/fork-after.png
----------------------------------------------------------------------
diff --git a/website/developers/fork-after.png b/website/developers/fork-after.png
deleted file mode 100644
index 3148ff3..0000000
Binary files a/website/developers/fork-after.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/fork-before.png
----------------------------------------------------------------------
diff --git a/website/developers/fork-before.png b/website/developers/fork-before.png
deleted file mode 100644
index 276eb9d..0000000
Binary files a/website/developers/fork-before.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/fork-new.png
----------------------------------------------------------------------
diff --git a/website/developers/fork-new.png b/website/developers/fork-new.png
deleted file mode 100644
index 34c2053..0000000
Binary files a/website/developers/fork-new.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/how-to-contribute.md
----------------------------------------------------------------------
diff --git a/website/developers/how-to-contribute.md b/website/developers/how-to-contribute.md
deleted file mode 100644
index 30e6142..0000000
--- a/website/developers/how-to-contribute.md
+++ /dev/null
@@ -1,118 +0,0 @@
----
-layout: website-normal
-title: How to Contribute
-children:
-- { section: Contributor License Agreement, title: CLA }
-- { section: Create an Issue in Jira, title: Jira }
-- { section: Pull Request at GitHub, title: GitHub }
-- { section: The Review Process, title: Reviews }
-- { section: Contributing without using GitHub, title: Patches }
-- { link: /developers/code/index.html, title: Get the Code }
-- { link: /developers/links.html, title: Handy Places }
----
-
-Welcome and thank you for your interest in contributing to Apache Brooklyn! This guide will take you through the
-process of making contributions to the Apache Brooklyn code base.
-
-<div class="panel panel-info">
-<div class="panel-heading" markdown="1">
-#### TL;DR
-</div>
-<div class="panel-body" markdown="1">
-
-* Pull request to the relevant [GitHub](http://github.com/apache/?query=brooklyn) project
-* Sign the [Apache CLA](https://www.apache.org/licenses/#clas) if it's non-trivial.
-* For bigger changes, open a [Jira](https://issues.apache.org/jira/browse/BROOKLYN)
- and/or [email the list](../community/mailing-lists.html).
-
-</div>
-</div>
-
-
-### Contributor License Agreement
-
-Apache Brooklyn is licensed under the [Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0). All
-contributions will be under this license, so please read and understand this license before contributing.
-
-For all but the most trivial patches, **we need a Contributor License Agreement for you** on file with the Apache
-Software Foundation. Please read the [guide to CLAs](https://www.apache.org/licenses/#clas) to find out how to file a
-CLA with the Foundation.
-
-
-### Join the Community
-
-If it's your first contribution or it's a particularly big or complex contribution, things typically go much more
-smoothly when they start off with a conversation.
-Significant changes are normally discussed on the mailing list in any case,
-sometimes with a [feature proposal](https://drive.google.com/drive/#folders/0B3XurVLRa7pIUHNFV3NuVVRkRlE/0B3XurVLRa7pIblN4NGRNN2dYUGM/0B3XurVLRa7pIMlZQSUxrdTh4Wmc) document.
-
-Visit our [Community](index.html) page to see how to contact Brooklyners via IRC or email.
-
-### Create an Issue in Jira
-
-The first step is usually to create or find an issue in [Brooklyn's Jira](https://issues.apache.org/jira/browse/BROOKLYN)
-for your feature request or fix. For small changes this isn't necessary, but it's good to see if your change fixes an
-existing issue anyway.
-
-
-### Pull Request at GitHub
-
-This is our preferred way for contributing code. Our root GitHub repository is located at
-[https://github.com/apache/brooklyn](https://github.com/apache/brooklyn) with most of the code in one of the subprojects.
-You can checkout and PR against just one of the projects listed there. See the README in our root repository for information on subprojects.
-
-Your commit messages must properly describes the changes that have been made and their purpose
-([here are some guidelines](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)). If your
-contributions fix a Jira issue, then ensure that you reference the issue (like `BROOKLYN-9876`) in the commit message.
-
-Create a pull request (PR) in GitHub for the change you're interested in making.
-Include a link to the Jira issue (if it has one) in the PR comment as well as the commit message.
-
-Some good references for working with GitHub are below.
-
-- [Setting Up Git with GitHub](https://help.github.com/articles/set-up-git)
-- [Forking a Repository](https://help.github.com/articles/fork-a-repo)
-- [Submitting Pull Requests](https://help.github.com/articles/using-pull-requests)
-- [Rebasing your Branch](https://help.github.com/articles/interactive-rebase)
-
-Finally, add a comment in the Jira issue with a link to the pull request so we know the code is ready to be reviewed.
-
-### The Review Process
-
-The Apache Brooklyn community will review your pull request before it is merged.
-If we are slow to respond, please feel free to post a reminder to the PR, Jira issue, IRC channel
-or mailing list -- see the [Community](../community/) page to see how to contact us.
-
-During the review process you may be asked to make some changes to your submission. While working through feedback,
-it can be beneficial to create new commits so the incremental change is obvious. This can also lead to a complex set
-of commits, and having an atomic change per commit is preferred in the end. Use your best judgement and work with
-your reviewer as to when you should revise a commit or create a new one.
-
-You may also get automated messages on the pull request from the CI running tests
-or GitHub determining whether a PR can be merged.
-Please keep these up to date to aid reviewers.
-
-A pull request is considered ready to be merged once it gets at lease one +1 from a committer.
-At this point your code will be included in the latest Apache Brooklyn.
-Congratulations and thank you!
-
-
-### Contributing without using GitHub
-
-If you prefer to not use GitHub, then that is fine - we are also happy to accept patches attached to a Jira issue.
-Our canonical root repository is located at `https://git-wip-us.apache.org/repos/asf/brooklyn.git` with others
-in `brooklyn-*.git`; for example:
-
-{% highlight bash %}
-$ git clone https://git-wip-us.apache.org/repos/asf/brooklyn-server.git
-{% endhighlight %}
-
-When producing patches, please use `git format-patch` or a similar mechanism - this will ensure that you are properly
-attributed as the author of the patch when a committer merges it.
-The review process will be as with pull requests, except for comments only appearing on the Jira issue.
-
-
-### Handy Places
-
-If you've not done so, you'll probably want to start by [getting the code](code/).
-Once you've done that, you'll find [handy development bookmarks here](links.html).
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/index.md
----------------------------------------------------------------------
diff --git a/website/developers/index.md b/website/developers/index.md
deleted file mode 100644
index ccbf934..0000000
--- a/website/developers/index.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-layout: website-normal
-title: Developers
-children:
-- code/
-- how-to-contribute.md
-- link: /v/latest/dev/index.html
- title_in_menu: "Developer Guide"
- not_external: true
-- committers/
-- code-standards.md
-- links.md
-- { link: 'http://github.com/apache/brooklyn', title: 'GitHub' }
-- { link: 'https://issues.apache.org/jira/browse/BROOKLYN', title: 'Bug Tracker (JIRA)' }
----
-
-Hello developers!
-These pages are aimed at people who want to get involved with reading, changing, testing and otherwise
-working with the bleeding edge Brooklyn code.
-
-<div class="panel panel-danger">
-<div class="panel-heading" markdown="1">
-#### Caution
-</div>
-<div class="panel-body" markdown="1">
-As these pages contain information about accessing the bleeding edge code and artifacts produced from it,
-you should be aware that the code and binaries you will encounter may be unstable.
-The Apache Software Foundation has not performed the level of validation and due diligence done
-on formally released artifacts.
-Proceed only if you understand the potential consequences of using unreleased code
-and are comfortable doing so.
-</div>
-</div>
-
-We heartily welome contributions and new members.
-There's nothing official needed to get involved;
-simply come say hello somewhere in the [community](../community/index.html):
-
-- [Mailing lists](../community/mailing-lists.html)
-- [IRC channel](../community/irc.html)
-- [JIRA for bug tracking](https://issues.apache.org/jira/browse/BROOKLYN)
-
-Then [get the code](code/).
-
-When you have a blueprint or an improvement you want to share,
-there are a few instructions to note on [how to contribute](how-to-contribute.html).
-
-If you're looking to learn more about the codebase itself,
-have a look at [Developer Guide]({{ site.path.guide }}/dev/).
-There are also a number of [development bookmarks](links.html) for the tools we use
-(git, jenkins, jira).
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/links.md
----------------------------------------------------------------------
diff --git a/website/developers/links.md b/website/developers/links.md
deleted file mode 100644
index b5da4ee..0000000
--- a/website/developers/links.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-layout: website-normal
-title: Handy Places
----
-
-{% include fields.md %}
-
-* **Code** is in Github at [https://github.com/apache/brooklyn/](https://github.com/apache/brooklyn/)
-
-* **Issues** are in Jira at [https://issues.apache.org/jira/browse/BROOKLYN/](https://issues.apache.org/jira/browse/BROOKLYN/)
-
-* **Maven repositories** are at:
-
- * [Apache releases]({{ apache_releases_repo_groupid_url }})
- * [Apache snapshots]({{ apache_snapshots_repo_groupid_url }})
-
-* **CI** is done by Jenkins at [https://builds.apache.org/job/brooklyn-master-build/](https://builds.apache.org/job/brooklyn-master-build/)
-
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/developers/pull-request.png
----------------------------------------------------------------------
diff --git a/website/developers/pull-request.png b/website/developers/pull-request.png
deleted file mode 100644
index 70407f2..0000000
Binary files a/website/developers/pull-request.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/documentation/faq.md
----------------------------------------------------------------------
diff --git a/website/documentation/faq.md b/website/documentation/faq.md
deleted file mode 100644
index 25d3864..0000000
--- a/website/documentation/faq.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: FAQ
-layout: website-normal
----
-
-## What's the difference between Brooklyn and...
-
-#### Chef and Puppet and other server config management tools?
-
-#### Cloudformation and Heat and other infrastructure declarative tools?
-
-#### CloudFoundry and other PaaS platforms?
-
-
-## Why is this page blank?
-
-Supplying the answers are a TODO.
-
-
-## How do I supply answers?
-
-Click the "Edit this Page" link in the bottom right.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/documentation/glossary.md
----------------------------------------------------------------------
diff --git a/website/documentation/glossary.md b/website/documentation/glossary.md
deleted file mode 100644
index 6846d23..0000000
--- a/website/documentation/glossary.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-layout: website-normal
-title: Glossary
----
-
-[//]: # (Abusing link groups to write comments that are not rendered in the document..)
-[//]: # (The links below reference the id attributes generated for the headers.)
-[//]: # (For example, the Autonomic section can be referred to with a link to #autonomic.)
-[//]: # (So if you alter any of the headers you should update the relevant link group too.)
-
-[autonomic]: #autonomic
-[blueprint]: #blueprint
-[effector]: #effector
-[entity]: #entity
-[policy]: #policy
-[sensor]: #sensor
-[YAML]: #yaml
-
-[//]: # (Note: Autonomic and blueprint section could link to learnmore page.)
-
-
-#### Autonomic
-
-Refers to the self-managing characteristics of distributed computing resources,
-adapting to unpredictable changes while hiding intrinsic complexity to
-operators and users.
-
-
-#### Blueprint
-
-A description of an application or system, which can be used for its automated
-deployment and runtime management. The blueprint describes a model of the
-application (i.e. its components, their configuration, and their
-relationships), along with policies for runtime management. The blueprint can
-be described in [YAML][].
-
-###### See also
-* [Documentation]({{site.path.website}}/learnmore/catalog/index.html) for the entity,
- policy and enricher blueprints that Apache Brooklyn supports out-of-the-box.
-
-
-#### Effector
-
-An operation on an [entity][].
-
-
-#### Enricher
-
-Generates new events or [sensor][] values (metrics) for an entity, usually by aggregating
-or modifying data from one or more other sensors.
-
-
-#### Entity
-
-A component of an application or system. This could be a physical component, a
-service, a grouping of components, or a logical construct describing part of an
-application/system. It is a "managed element" in autonomic computing parlance.
-
-
-#### Policy
-
-Part of an autonomic management system, performing runtime management. A policy
-is associated with an [entity][]; it normally manages the health of that entity
-or an associated group of entities (e.g. HA policies or auto-scaling policies).
-
-
-#### Sensor
-
-An attribute of an [entity][].
-
-
-#### YAML
-
-A human-readable data format.
-
-###### See also
-* [Wikipedia article](http://en.wikipedia.org/wiki/YAML) on YAML
-
-
-#### Apache jclouds
-
-An open source Java library that provides a consistent interface to many
-clouds. Apache Brooklyn uses Apache jclouds as its core cloud abstraction.
-
-###### See also
-* [Project homepage](https://jclouds.apache.org/)
-
-
-#### CAMP and TOSCA
-
-OASIS Cloud Application Management for Platforms (CAMP) and OASIS Topology and
-Orchestration Specification for Cloud Applications (TOSCA) are specifications
-that aim to standardise the portability and management of cloud applications.
-
-###### See also
-* [CAMP homepage](https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=camp)
-* [TOSCA homepage](https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tosca)
-
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/documentation/index.md
----------------------------------------------------------------------
diff --git a/website/documentation/index.md b/website/documentation/index.md
deleted file mode 100644
index d1f323d..0000000
--- a/website/documentation/index.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-layout: website-normal
-title: Documentation
-children:
- - link: /v/latest/index.html
- title_in_menu: "User Guide"
- not_external: true
-
- - link: /v/latest/dev/index.html
- title_in_menu: Developer Guide
- not_external: true
-
- - path: ../meta/versions.md
- title_in_menu: Versions
-
- - path: other-docs.md
- title_in_menu: Other Resources
----
-
-{% comment %}
-TODO add a bunch more here
-
-TODO add FAQ
-{% endcomment %}
-
-## Official User Guide
-
-Our main user manual is organised by release version. Please pick the version that you are using:
-
-- [{{ site.brooklyn-stable-version }}]({{ site.path.v }}/latest) -
- This is the latest stable version.
-
-- [Older versions]({{ site.path.website }}/meta/versions.html)
-
-
-## Other Docs
-
-Other mini-docs are available [here](other-docs.html),
-or see the [Learn More]({{ site.path.website }}/learnmore) section of the site.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/5b360c27/website/documentation/other-docs.md
----------------------------------------------------------------------
diff --git a/website/documentation/other-docs.md b/website/documentation/other-docs.md
deleted file mode 100644
index 0b80ce7..0000000
--- a/website/documentation/other-docs.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Other Resources
-layout: website-normal
-children:
-- { path: glossary.md }
-- { path: ../meta/versions.md }
-- { path: ../meta/sitemap.md }
----
-
-{% include list-children.html %}