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

[Blue Swirl]

On Sat, Sep 24, 2011 at 9:56 PM, Anthony Liguori <address@hidden> wrote:
>
> 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.

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