Planning/SoftFeatureFreeze: Difference between revisions

From QEMU
No edit summary
No edit summary
Line 1: Line 1:
***Note: From QEMU 2.8 onwards all patches must be merge by softfreeze.  New features that were on the mailing list will not be allowed in after softfreeze anymore.***
== What is the soft feature freeze? ==
== What is the soft feature freeze? ==



Revision as of 12:58, 29 September 2016

      • Note: From QEMU 2.8 onwards all patches must be merge by softfreeze. New features that were on the mailing list will not be allowed in after softfreeze anymore.***

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 non-trivial feature should have some code posted to the qemu-devel mailing list if it's targeting a given release. Major features, and in particular features with a high likelihood of breaking things, should already be in the process of being merged.

What should I do by the soft feature freeze?

For any feature that you're targeting to the next release, you should:

  1. Make sure that you've posted a patch series to qemu-devel

For major features you should also:

  1. Write a Feature page on the qemu.org wiki describing the feature and the motivation
  2. On the release planning wiki page, link to your feature wiki page.
  3. 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[1].