Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)

[Anthony Liguori]

On Sep 24, 2011 3:05 AM, "Blue Swirl" <address@hidden> wrote:
>
> On Thu, Sep 22, 2011 at 12:34 AM, Anthony Liguori <address@hidden> 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.

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].
> >
> >