[edk2-wiki PATCH 1/2] release planning: describe the hard and soft feature freezes

[Laszlo Ersek <lersek@redhat.com>]

Adopt QEMU's definitions for the soft and hard feature freezes, and update
them for the edk2 process.

(In particular, while we don't forbid such pull requests that are
submitted to the mailing list, we usually apply patches from emails with
git-am, rather than merge remote branches.)

Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 HardFeatureFreeze.md |  6 +++
 SoftFeatureFreeze.md | 42 ++++++++++++++++++++
 2 files changed, 48 insertions(+)

diff --git a/HardFeatureFreeze.md b/HardFeatureFreeze.md
new file mode 100644
index 000000000000..01288dd03f71
--- /dev/null
+++ b/HardFeatureFreeze.md
@@ -0,0 +1,6 @@
+After the hard feature freeze, the master branch in git is no longer open for
+general development. Only bug fixes will be accepted until the next [stable
+tag](EDK-II#stable-tags).
+
+(This definition is modeled after QEMU's [hard feature
+freeze](https://wiki.qemu.org/Planning/HardFeatureFreeze)).
diff --git a/SoftFeatureFreeze.md b/SoftFeatureFreeze.md
new file mode 100644
index 000000000000..9dc7d9c19369
--- /dev/null
+++ b/SoftFeatureFreeze.md
@@ -0,0 +1,42 @@
+# What is the soft feature freeze?
+
+The soft feature freeze is the beginning of the stabilization phase of edk2's
+development process. By the date of the soft feature freeze,  developers must
+have sent their patches to the mailing list **and** received positive
+maintainer reviews (`Reviewed-by` or `Acked-by` tags). This means that
+features, and in particular non-trivial ones, must have been accepted by
+maintainers before the soft freeze date.
+
+Between the soft feature freeze and the [hard feature
+freeze](HardFeatureFreeze), previously reviewed and unit-tested features may be
+applied (or merged) to the master branch, for integration testing. Feature
+addition or enablement patches posted **or** reviewed after the soft feature
+freeze will be delayed until after the upcoming [stable
+tag](EDK-II#stable-tags).
+
+# What should I do by the soft feature freeze?
+
+As a maintainer, for any feature that you're targeting to the next [stable
+tag](EDK-II#stable-tags), you should make sure that you've reviewed and
+accepted the patches related to the feature.
+
+As a developer, you probably should target a date that is at least 1-2 weeks
+earlier than the soft freeze date. This will give the maintainer enough time to
+review and test your patches. For major features you should probably
+communicate with the maintainer about their intentions. It also helps if you:
+
+- Enter a Bugzilla ticket for the [TianoCore Feature
+  Requests](https://bugzilla.tianocore.org/enter_bug.cgi?product=Tianocore%20Feature%20Requests)
+  product.
+
+- Optionally, write a Feature page in the [edk2 wiki](Home) describing the
+  feature and the motivation.
+
+- On the [release planning wiki page](EDK-II-Release-Planning), link to your
+  Bugzilla entry and/or the feature wiki page.
+
+- Do all this early enough that you can work with the maintainer to get the
+  review process underway.
+
+(This definition is modeled after QEMU's [soft feature
+freeze](https://wiki.qemu.org/Planning/SoftFeatureFreeze).)
-- 
2.14.1.3.gb7cf6e02401b