Planning/SoftFeatureFreeze: Difference between revisions

Latest revision as of 12:24, 9 January 2017

What is the soft feature freeze?

The soft feature freeze is the beginning of the stabilization phase of QEMU's development process. By the date of the soft feature freeze, maintainers must have sent their pull request to the mailing list. This means that features, and in particular non-trivial ones, must have been merged into maintainer trees before the soft freeze date.

What should I do by the soft feature freeze?

As a maintainer, for any feature that you're targeting to the next release, you should make sure that you've posted a pull request to qemu-devel.

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, test and apply your patches. For major features you should probably communicate with the maintainer about his intentions. It also helps if:

Write a Feature page on the qemu.org wiki describing the feature and the motivation
On the release planning wiki page, link to your feature wiki page.
Do all this early enough that you can work with the submaintainer to get the merge process underway

@@ Line 1: / Line 1: @@
 == What is the soft feature freeze? ==
-The soft feature freeze is the beginning of the stabilization phase of QEMU's development process.  By the date of the soft feature freeze, any major feature should have some code posted to the qemu-devel mailing list if it's targeting a given release.
+The soft feature freeze is the beginning of the stabilization phase of QEMU's development process.  By the date of the soft feature freeze,  maintainers must have sent their pull request to the mailing list.  This means that features, and in particular non-trivial ones, must have been merged into maintainer trees before the soft freeze date.
 == What should I do by the soft feature freeze? ==
-For any major feature that you're targeting to the next release, you should:
+As a maintainer, for any feature that you're targeting to the next release, you should make sure that you've posted a pull request to qemu-devel.
+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, test and apply your patches.  For major features you should probably communicate with the maintainer about his intentions.  It also helps if:
-# Make sure that you've posted a patch series to qemu-devel
 # Write a Feature page on the qemu.org wiki describing the feature and the motivation
 # On the release planning wiki page, link to your feature wiki page.
+# Do all this early enough that you can work with the submaintainer to get the merge process underway
-== Will my patches be rejected if I don't post before the soft feature freeze? ==
-That's ultimately up to the subsystem maintainer.  It's a value call based on the relative importance of the feature verses the disruptiveness of the feature.  It's always best to avoid this problem in the first place and release early, release often[http://en.wikipedia.org/wiki/Release_early,_release_often].