From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3187B21B02822 for ; Thu, 16 Aug 2018 07:51:54 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 21B967788A; Thu, 16 Aug 2018 14:51:54 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-198.rdu2.redhat.com [10.10.120.198]) by smtp.corp.redhat.com (Postfix) with ESMTP id 56A8920180F4; Thu, 16 Aug 2018 14:51:53 +0000 (UTC) From: Laszlo Ersek To: edk2-devel-01 Cc: Andrew Fish , Leif Lindholm , Michael D Kinney Date: Thu, 16 Aug 2018 16:51:48 +0200 Message-Id: <20180816145149.8897-2-lersek@redhat.com> In-Reply-To: <20180816145149.8897-1-lersek@redhat.com> References: <20180816145149.8897-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Thu, 16 Aug 2018 14:51:54 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Thu, 16 Aug 2018 14:51:54 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: [edk2-wiki PATCH 1/2] release planning: describe the hard and soft feature freezes X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2018 14:51:55 -0000 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 Cc: Leif Lindholm Cc: Michael D Kinney Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek --- 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