On Sat, Sep 24, 2011 at 9:56 PM, Anthony Liguori <anth...@codemonkey.ws> wrote: > > On Sep 24, 2011 3:05 AM, "Blue Swirl" <blauwir...@gmail.com> wrote: >> >> On Thu, Sep 22, 2011 at 12:34 AM, Anthony Liguori <anth...@codemonkey.ws> >> wrote: >> > 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. >> >> I think the freezes and the release should be delayed until the memory >> API conversion is finished, deliberately shipping semi-broken code >> just to satisfy schedules does not benefit anyone but the schedule >> creator. It looks to me that converting all buses and devices might be >> finished by the deadline but it may as well take a bit more until >> everything works again. > > The point of having a freeze period is to give time to fix any problems. > Six weeks should be plenty of time to fix any memory API fall out.
Maybe I'm too pessimistic about the schedule, but we'll see. > > Regards, > > Anthony Liguori > >> > == 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]. >> > >> > >
