From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46031) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6XFB-00010s-MJ for qemu-devel@nongnu.org; Wed, 21 Sep 2011 20:34:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R6XF9-00021v-OG for qemu-devel@nongnu.org; Wed, 21 Sep 2011 20:34:25 -0400 Received: from mail-iy0-f173.google.com ([209.85.210.173]:49315) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6XF9-00021e-LF for qemu-devel@nongnu.org; Wed, 21 Sep 2011 20:34:23 -0400 Received: by iagf6 with SMTP id f6so2696011iag.4 for ; Wed, 21 Sep 2011 17:34:22 -0700 (PDT) Message-ID: <4E7A828A.3030404@codemonkey.ws> Date: Wed, 21 Sep 2011 19:34:18 -0500 From: Anthony Liguori MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel Consider this a friendly reminder that we're only three weeks away from the soft feature freeze for 1.0. I've written a wiki page about my expectations for the soft feature freeze. It's inlined here for easier commenting. == 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. == What should I do by the soft feature freeze? == For any major feature that you're targeting to the next release, you should: # 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. == 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].