Add post announcing the release plan for 3.2.0 and EOL of 2.16
Change-Id: If80e1264125841d04cf50e9ffc0a4add3d3eb3a4
diff --git a/_posts/2020-04-22-gerrit-3.2-release-plan.md b/_posts/2020-04-22-gerrit-3.2-release-plan.md
new file mode 100644
index 0000000..ff27c94
--- /dev/null
+++ b/_posts/2020-04-22-gerrit-3.2-release-plan.md
@@ -0,0 +1,81 @@
+---
+title: "Release Plan for Gerrit 3.2"
+tags: news
+keywords: news
+permalink: 2020-04-22-gerrit-3.2-release-plan.html
+summary: "Release Plan for Gerrit 3.2"
+hide_sidebar: true
+hide_navtoggle: true
+toc: true
+---
+
+## High Level Release Plan
+
+| Date | Activity |
+|-----------|---------------------------------------------|
+| April 24 | Create `stable-3.2` and release `3.2.0-rc0` |
+| May 1 | Release `3.2.0-rc1` |
+| May 8 | Release `3.2.0-rc2` |
+| May 15 | Release `3.2.0-rc3` |
+| May 22 | Release `3.2.0-rc4` |
+| May 25-29 | "Release week" (see below) |
+| June 1 | Final release of `3.2.0` |
+
+## Change Acceptance Policy for the Stable Branch
+
+We don't expect that all ongoing feature development will be completed before
+the stable branch is created, so we will allow further development to continue
+on the stable branch to bring features to completion *until `rc3`*.
+
+After `rc3` only bug fixes will be accepted on the stable branch.
+
+We would prefer that bug fixes are pushed for review directly onto the stable
+branch, rather than onto master to be cherry-picked back. The reason for this
+is to avoid that the release managers need to spend time manually checking
+which changes need to be backported, which could result in changes being
+overlooked.
+
+## "Release Week"
+
+We had initially planned to finalize and make the release during the Spring
+hackathon, but that has been cancelled due to the ongoing situation with COVID-19.
+
+Instead we will ask community members, particularly those who would have joined
+the hackathon, to allocate some of their time during the "release week" (25-29 May)
+to help with finalizing the release
+
+- test the release candidates
+- report issues
+- triage and troubleshoot incoming bug reports
+- make fixes
+- do code reviews
+- test the latest head of the stable branch
+
+To expedite reviews of Library-Compliance and frontend changes, we will ask
+Google to make some members available, and we will also ask Matthias Sohn or
+anyone else from the JGit community to be available to help with JGit related
+issues.
+
+We have set up a dedicated channel on Slack
+([`#gerrit-32-release`](https://gerritcodereview.slack.com/archives/C0128RZFSR3))
+where these activities will be coordinated. It is yet to be confirmed if we will
+set up any kind of video or voice conferences.
+
+## End-to-end Testing
+
+We plan to use the
+[Gatling e2e test framework for Git](https://gerrit-review.googlesource.com/Documentation/dev-e2e-tests.html),
+developed by GerritForge and Ericsson, to test the stability of the release on a production-like
+setup on AWS automatically provisioned using the [aws-gerrit](https://gerrit.googlesource.com/aws-gerrit)
+templates.
+
+## End of Life for Gerrit 2.16.x
+
+Per the support policy mentioned on the
+[project homepage](https://www.gerritcodereview.com/support.html#supported-versions),
+after 3.2.0 is released 2.16.x will reach end of life and will no longer be
+actively supported, however we plan to make exceptions to this policy for
+any issues related to the migration to NoteDb.
+
+Support for 3.1.x and 3.0.x will continue; users of 2.16.x or earlier are
+recommended to upgrade to one of these versions.
