[Qemu-devel] [RFC] 1.4 release schedule

[Qemu-devel] [RFC] 1.4 release schedule

[Anthony Liguori]

Hi,

Based on popular demand, I'd like to continue with a 3-month release
cycle for the foreseeable future.  One thing I'd like to "fix" though is
to avoid major holidays during the -rc cycles.

The best cycle I can figure is:

Feb 15th
May 15th
Aug 15th
Nov 15th

To get us onto this schedule, we'll need to make 1.4 a short release but
I still think there's ample time to ge stuff done.

I've put up a strawman schedule on the wiki:

http://wiki.qemu.org/Planning/1.4

Regards,

Anthony Liguori

Re: [Qemu-devel] [RFC] 1.4 release schedule

[Johnson, Eric]

I think you meant to change the 1.3.0 to 1.4.0 for the milestones on the Wiki. ;-)

> -----Original Message-----
> From: qemu-devel-bounces+ericj=mips.com@nongnu.org [mailto:qemu-devel-
> bounces+ericj=mips.com@nongnu.org] On Behalf Of Anthony Liguori
> Sent: Monday, December 03, 2012 1:30 PM
> To: qemu-devel@nongnu.org
> Subject: [Qemu-devel] [RFC] 1.4 release schedule
> 
> 
> Hi,
> 
> Based on popular demand, I'd like to continue with a 3-month release
> cycle for the foreseeable future.  One thing I'd like to "fix" though is
> to avoid major holidays during the -rc cycles.
> 
> The best cycle I can figure is:
> 
> Feb 15th
> May 15th
> Aug 15th
> Nov 15th
> 
> To get us onto this schedule, we'll need to make 1.4 a short release but
> I still think there's ample time to ge stuff done.
> 
> I've put up a strawman schedule on the wiki:
> 
> http://wiki.qemu.org/Planning/1.4
> 
> Regards,
> 
> Anthony Liguori
> 

Re: [Qemu-devel] [RFC] 1.4 release schedule

[Anthony Liguori]

"Johnson, Eric" <ericj@mips.com> writes:

> I think you meant to change the 1.3.0 to 1.4.0 for the milestones on
> the Wiki. ;-)

Indeed, fixed now.

Regards,

Anthony Liguori

>
>> -----Original Message-----
>> From: qemu-devel-bounces+ericj=mips.com@nongnu.org [mailto:qemu-devel-
>> bounces+ericj=mips.com@nongnu.org] On Behalf Of Anthony Liguori
>> Sent: Monday, December 03, 2012 1:30 PM
>> To: qemu-devel@nongnu.org
>> Subject: [Qemu-devel] [RFC] 1.4 release schedule
>> 
>> 
>> Hi,
>> 
>> Based on popular demand, I'd like to continue with a 3-month release
>> cycle for the foreseeable future.  One thing I'd like to "fix" though is
>> to avoid major holidays during the -rc cycles.
>> 
>> The best cycle I can figure is:
>> 
>> Feb 15th
>> May 15th
>> Aug 15th
>> Nov 15th
>> 
>> To get us onto this schedule, we'll need to make 1.4 a short release but
>> I still think there's ample time to ge stuff done.
>> 
>> I've put up a strawman schedule on the wiki:
>> 
>> http://wiki.qemu.org/Planning/1.4
>> 
>> Regards,
>> 
>> Anthony Liguori
>> 

Re: [Qemu-devel] [RFC] 1.4 release schedule

[Blue Swirl]

On Mon, Dec 3, 2012 at 9:30 PM, Anthony Liguori <aliguori@us.ibm.com> wrote:
>
> Hi,
>
> Based on popular demand, I'd like to continue with a 3-month release
> cycle for the foreseeable future.  One thing I'd like to "fix" though is
> to avoid major holidays during the -rc cycles.
>
> The best cycle I can figure is:
>
> Feb 15th
> May 15th
> Aug 15th
> Nov 15th
>
> To get us onto this schedule, we'll need to make 1.4 a short release but
> I still think there's ample time to ge stuff done.
>
> I've put up a strawman schedule on the wiki:
>
> http://wiki.qemu.org/Planning/1.4

Looks fine.

The definition of the hard freeze bothers me. A few patches that went
in after 1.3-rc0 were not bug fixes but just new features, so the
difference between soft and hard freezes was not clear.

>
> Regards,
>
> Anthony Liguori
>
>

Re: [Qemu-devel] [RFC] 1.4 release schedule

[Peter Maydell]

On 4 December 2012 18:38, Blue Swirl <blauwirbel@gmail.com> wrote:
> The definition of the hard freeze bothers me. A few patches that went
> in after 1.3-rc0 were not bug fixes but just new features, so the
> difference between soft and hard freezes was not clear.

My vote for this would be to adhere to our definition
and only commit bugfixes.

-- PMM

Re: [Qemu-devel] [RFC] 1.4 release schedule

[Blue Swirl]

On Tue, Dec 4, 2012 at 6:42 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 4 December 2012 18:38, Blue Swirl <blauwirbel@gmail.com> wrote:
>> The definition of the hard freeze bothers me. A few patches that went
>> in after 1.3-rc0 were not bug fixes but just new features, so the
>> difference between soft and hard freezes was not clear.
>
> My vote for this would be to adhere to our definition
> and only commit bugfixes.

With that approach, I'd change the durations a bit, something like 20
days for soft freeze and 10 for hard freeze (really hard, bug fixes
only with word 'fix' in commit message, no late pulls etc).

>
> -- PMM

Re: [Qemu-devel] [RFC] 1.4 release schedule

[Anthony Liguori]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 4 December 2012 18:38, Blue Swirl <blauwirbel@gmail.com> wrote:
>> The definition of the hard freeze bothers me. A few patches that went
>> in after 1.3-rc0 were not bug fixes but just new features, so the
>> difference between soft and hard freezes was not clear.
>
> My vote for this would be to adhere to our definition
> and only commit bugfixes.

Let's get specific.  What was committed post hard freeze that's not a
bug fix?

The only thing I'm aware of is q35.  I asked Michael not to merge that
(he planned to) prior to the hard freeze because there was a specific
change I wanted to be made.  Normally, PCI bits would go through
Michael's tree but I felt the change really needed to be made.

So I agreed to take the bits post hard freeze so the change could be
made.  This is really was an exceptional case though and I don't think
it warrants a change in the description of hard freeze.  This was all
discussed on the mailing list too FWIW.

Regards,

Anthony Liguori

>
> -- PMM

Re: [Qemu-devel] [RFC] 1.4 release schedule

[Blue Swirl]

On Tue, Dec 4, 2012 at 10:00 PM, Anthony Liguori <aliguori@us.ibm.com> wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
>
>> On 4 December 2012 18:38, Blue Swirl <blauwirbel@gmail.com> wrote:
>>> The definition of the hard freeze bothers me. A few patches that went
>>> in after 1.3-rc0 were not bug fixes but just new features, so the
>>> difference between soft and hard freezes was not clear.
>>
>> My vote for this would be to adhere to our definition
>> and only commit bugfixes.
>
> Let's get specific.  What was committed post hard freeze that's not a
> bug fix?

d3067b0 Documentation: Update image format information
a13e5e0 Documentation: Update block cache mode information
044d003 qemu-tech.texi: update implemented xtensa features list
a0a7068 target-i386: Enable SSSE3 TCG support
80ae416 target-i386/cpu: Add missing flags to Haswell CPU model
42015c9 virtio-rng: fix typos, comments
e1e54f3 target-i386: cpu: add missing flags to Haswell CPU model
339c270 qom: make object_finalize static
64b625f qdev: simplify (de)allocation of buses
fde9bf4 qom: make object_delete usable for statically-allocated objects
667d22d qdev: move bus removal to object_unparent
74c856e tests: add thread pool unit tests
b2ea25d tests: add AioContext unit tests
21022c9 q35: Add kvmclock support
a1c9304 ich9: Add i82801b11 dmi-to-pci bridge
df2d8b3 q35: Introduce q35 pc based chipset emulator
678e7b9 ich9: Add smbus
4d00636 ich9: Add the lpc chip
e516572 ich9: Add acpi support and definitions
410edd9 pc/piix_pci: factor out smram/pam logic
d8ee038 pc_piix: Move kvm irq routing functions out of pc_piix.c
a39e356 pc: Move ioapic_init() from pc_piix.c to pc.c
9011a1a pc, pc_piix: split out pc nic initialization
723aedd usb-redir: Don't handle interrupt output packets async
234e810 usb-redir: Split usb_handle_interrupt_data into separate
in/out functions
33c1a68 usb-bt: Return NAK instead of STALL when interrupt ep has no data
1bc6b70 block: add bdrv_reopen() support for raw hdev, floppy, and cdrom
d132c79 target-mips: Add comments on POOL32Axf encoding

>
> The only thing I'm aware of is q35.  I asked Michael not to merge that
> (he planned to) prior to the hard freeze because there was a specific
> change I wanted to be made.  Normally, PCI bits would go through
> Michael's tree but I felt the change really needed to be made.
>
> So I agreed to take the bits post hard freeze so the change could be
> made.  This is really was an exceptional case though and I don't think
> it warrants a change in the description of hard freeze.  This was all
> discussed on the mailing list too FWIW.

The description is OK if a bit terse, for example documentation or
comment fixes could be explicitly mentioned.

I may have missed the discussion where q35 was excepted to bypass the
freeze, but only one third of the commits above were about q35 though.

>
> Regards,
>
> Anthony Liguori
>
>>
>> -- PMM
>

Re: [Qemu-devel] [RFC] 1.4 release schedule

[Hans de Goede]

Hi,

On 12/05/2012 08:28 PM, Blue Swirl wrote:
> On Tue, Dec 4, 2012 at 10:00 PM, Anthony Liguori <aliguori@us.ibm.com> wrote:
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>
>>> On 4 December 2012 18:38, Blue Swirl <blauwirbel@gmail.com> wrote:
>>>> The definition of the hard freeze bothers me. A few patches that went
>>>> in after 1.3-rc0 were not bug fixes but just new features, so the
>>>> difference between soft and hard freezes was not clear.
>>>
>>> My vote for this would be to adhere to our definition
>>> and only commit bugfixes.
>>
>> Let's get specific.  What was committed post hard freeze that's not a
>> bug fix?
>
> d3067b0 Documentation: Update image format information
> a13e5e0 Documentation: Update block cache mode information
> 044d003 qemu-tech.texi: update implemented xtensa features list

Adding missing / updating docs to be more accurate is a bug fix,
and one with a very low chance of causing regressions at that.

> a0a7068 target-i386: Enable SSSE3 TCG support
> 80ae416 target-i386/cpu: Add missing flags to Haswell CPU model
> 42015c9 virtio-rng: fix typos, comments
> e1e54f3 target-i386: cpu: add missing flags to Haswell CPU model
> 339c270 qom: make object_finalize static
> 64b625f qdev: simplify (de)allocation of buses
> fde9bf4 qom: make object_delete usable for statically-allocated objects
> 667d22d qdev: move bus removal to object_unparent
> 74c856e tests: add thread pool unit tests
> b2ea25d tests: add AioContext unit tests
> 21022c9 q35: Add kvmclock support
> a1c9304 ich9: Add i82801b11 dmi-to-pci bridge
> df2d8b3 q35: Introduce q35 pc based chipset emulator
> 678e7b9 ich9: Add smbus
> 4d00636 ich9: Add the lpc chip
> e516572 ich9: Add acpi support and definitions
> 410edd9 pc/piix_pci: factor out smram/pam logic
> d8ee038 pc_piix: Move kvm irq routing functions out of pc_piix.c
> a39e356 pc: Move ioapic_init() from pc_piix.c to pc.c
> 9011a1a pc, pc_piix: split out pc nic initialization


> 723aedd usb-redir: Don't handle interrupt output packets async
Bug-fix

> 234e810 usb-redir: Split usb_handle_interrupt_data into separate
> in/out functions
Preparation patch for the above bugfix, no functional changes.

> 33c1a68 usb-bt: Return NAK instead of STALL when interrupt ep has no data
Bug-fix


Regards,

Hans

Re: [Qemu-devel] [RFC] 1.4 release schedule

[Blue Swirl]

On Wed, Dec 5, 2012 at 7:41 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
>
> On 12/05/2012 08:28 PM, Blue Swirl wrote:
>>
>> On Tue, Dec 4, 2012 at 10:00 PM, Anthony Liguori <aliguori@us.ibm.com>
>> wrote:
>>>
>>> Peter Maydell <peter.maydell@linaro.org> writes:
>>>
>>>> On 4 December 2012 18:38, Blue Swirl <blauwirbel@gmail.com> wrote:
>>>>>
>>>>> The definition of the hard freeze bothers me. A few patches that went
>>>>> in after 1.3-rc0 were not bug fixes but just new features, so the
>>>>> difference between soft and hard freezes was not clear.
>>>>
>>>>
>>>> My vote for this would be to adhere to our definition
>>>> and only commit bugfixes.
>>>
>>>
>>> Let's get specific.  What was committed post hard freeze that's not a
>>> bug fix?
>>
>>
>> d3067b0 Documentation: Update image format information
>> a13e5e0 Documentation: Update block cache mode information
>> 044d003 qemu-tech.texi: update implemented xtensa features list
>
>
> Adding missing / updating docs to be more accurate is a bug fix,
> and one with a very low chance of causing regressions at that.

I don't think they are bug fixes but improvements to documentation
features. But I agree patches only touching documentation, comment and
string contents could be exempted.

>
>
>> a0a7068 target-i386: Enable SSSE3 TCG support
>> 80ae416 target-i386/cpu: Add missing flags to Haswell CPU model
>> 42015c9 virtio-rng: fix typos, comments
>> e1e54f3 target-i386: cpu: add missing flags to Haswell CPU model
>> 339c270 qom: make object_finalize static
>> 64b625f qdev: simplify (de)allocation of buses
>> fde9bf4 qom: make object_delete usable for statically-allocated objects
>> 667d22d qdev: move bus removal to object_unparent
>> 74c856e tests: add thread pool unit tests
>> b2ea25d tests: add AioContext unit tests
>> 21022c9 q35: Add kvmclock support
>> a1c9304 ich9: Add i82801b11 dmi-to-pci bridge
>> df2d8b3 q35: Introduce q35 pc based chipset emulator
>> 678e7b9 ich9: Add smbus
>> 4d00636 ich9: Add the lpc chip
>> e516572 ich9: Add acpi support and definitions
>> 410edd9 pc/piix_pci: factor out smram/pam logic
>> d8ee038 pc_piix: Move kvm irq routing functions out of pc_piix.c
>> a39e356 pc: Move ioapic_init() from pc_piix.c to pc.c
>> 9011a1a pc, pc_piix: split out pc nic initialization
>
>
>
>> 723aedd usb-redir: Don't handle interrupt output packets async
>
> Bug-fix

This was not clear from the description, from that it looked to me
that it's a general change with possibly good and bad effects.

>
>
>> 234e810 usb-redir: Split usb_handle_interrupt_data into separate
>> in/out functions
>
> Preparation patch for the above bugfix, no functional changes.
>
>
>> 33c1a68 usb-bt: Return NAK instead of STALL when interrupt ep has no data
>
> Bug-fix

Word 'fix' was not mentioned in the description.

>
>
> Regards,
>
> Hans

Re: [Qemu-devel] [RFC] 1.4 release schedule

[Markus Armbruster]

Blue Swirl <blauwirbel@gmail.com> writes:

> On Wed, Dec 5, 2012 at 7:41 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>>
>> On 12/05/2012 08:28 PM, Blue Swirl wrote:
>>>
>>> On Tue, Dec 4, 2012 at 10:00 PM, Anthony Liguori <aliguori@us.ibm.com>
>>> wrote:
>>>>
>>>> Peter Maydell <peter.maydell@linaro.org> writes:
>>>>
>>>>> On 4 December 2012 18:38, Blue Swirl <blauwirbel@gmail.com> wrote:
>>>>>>
>>>>>> The definition of the hard freeze bothers me. A few patches that went
>>>>>> in after 1.3-rc0 were not bug fixes but just new features, so the
>>>>>> difference between soft and hard freezes was not clear.
>>>>>
>>>>>
>>>>> My vote for this would be to adhere to our definition
>>>>> and only commit bugfixes.
>>>>
>>>>
>>>> Let's get specific.  What was committed post hard freeze that's not a
>>>> bug fix?
>>>
>>>
>>> d3067b0 Documentation: Update image format information
>>> a13e5e0 Documentation: Update block cache mode information
>>> 044d003 qemu-tech.texi: update implemented xtensa features list
>>
>>
>> Adding missing / updating docs to be more accurate is a bug fix,
>> and one with a very low chance of causing regressions at that.
>
> I don't think they are bug fixes but improvements to documentation
> features. But I agree patches only touching documentation, comment and
> string contents could be exempted.

What about improvements to tests?  No impact on anything but "make
check".

[...]

Re: [Qemu-devel] [RFC] 1.4 release schedule

[Blue Swirl]

On Thu, Dec 6, 2012 at 8:05 AM, Markus Armbruster <armbru@redhat.com> wrote:
> Blue Swirl <blauwirbel@gmail.com> writes:
>
>> On Wed, Dec 5, 2012 at 7:41 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>>
>>> On 12/05/2012 08:28 PM, Blue Swirl wrote:
>>>>
>>>> On Tue, Dec 4, 2012 at 10:00 PM, Anthony Liguori <aliguori@us.ibm.com>
>>>> wrote:
>>>>>
>>>>> Peter Maydell <peter.maydell@linaro.org> writes:
>>>>>
>>>>>> On 4 December 2012 18:38, Blue Swirl <blauwirbel@gmail.com> wrote:
>>>>>>>
>>>>>>> The definition of the hard freeze bothers me. A few patches that went
>>>>>>> in after 1.3-rc0 were not bug fixes but just new features, so the
>>>>>>> difference between soft and hard freezes was not clear.
>>>>>>
>>>>>>
>>>>>> My vote for this would be to adhere to our definition
>>>>>> and only commit bugfixes.
>>>>>
>>>>>
>>>>> Let's get specific.  What was committed post hard freeze that's not a
>>>>> bug fix?
>>>>
>>>>
>>>> d3067b0 Documentation: Update image format information
>>>> a13e5e0 Documentation: Update block cache mode information
>>>> 044d003 qemu-tech.texi: update implemented xtensa features list
>>>
>>>
>>> Adding missing / updating docs to be more accurate is a bug fix,
>>> and one with a very low chance of causing regressions at that.
>>
>> I don't think they are bug fixes but improvements to documentation
>> features. But I agree patches only touching documentation, comment and
>> string contents could be exempted.
>
> What about improvements to tests?  No impact on anything but "make
> check".

While not bug fixes either, those should be also OK. Though if we had
a QA or release team running tests (including these), they would
probably have to restart their test cycle if there are changes to the
test sets so it's not 100% clear.

>
> [...]

Re: [Qemu-devel] [RFC] 1.4 release schedule

[Kevin Wolf]

Am 05.12.2012 20:58, schrieb Blue Swirl:
> On Wed, Dec 5, 2012 at 7:41 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>>
>> On 12/05/2012 08:28 PM, Blue Swirl wrote:
>>>
>>> On Tue, Dec 4, 2012 at 10:00 PM, Anthony Liguori <aliguori@us.ibm.com>
>>> wrote:
>>>>
>>>> Peter Maydell <peter.maydell@linaro.org> writes:
>>>>
>>>>> On 4 December 2012 18:38, Blue Swirl <blauwirbel@gmail.com> wrote:
>>>>>>
>>>>>> The definition of the hard freeze bothers me. A few patches that went
>>>>>> in after 1.3-rc0 were not bug fixes but just new features, so the
>>>>>> difference between soft and hard freezes was not clear.
>>>>>
>>>>>
>>>>> My vote for this would be to adhere to our definition
>>>>> and only commit bugfixes.
>>>>
>>>>
>>>> Let's get specific.  What was committed post hard freeze that's not a
>>>> bug fix?
>>>
>>>
>>> d3067b0 Documentation: Update image format information
>>> a13e5e0 Documentation: Update block cache mode information
>>> 044d003 qemu-tech.texi: update implemented xtensa features list
>>
>>
>> Adding missing / updating docs to be more accurate is a bug fix,
>> and one with a very low chance of causing regressions at that.
> 
> I don't think they are bug fixes but improvements to documentation
> features. But I agree patches only touching documentation, comment and
> string contents could be exempted.

Actually these patches contain changes where the documentation didn't
match the implementation. In other words, the documentation was indeed
buggy.

They also added some missing things, but as you said, improving
documentation during the hard freeze isn't a bad thing anyway.

>>> 74c856e tests: add thread pool unit tests
>>> b2ea25d tests: add AioContext unit tests

And the same is true for tests. They can only improve the release.

> 1bc6b70 block: add bdrv_reopen() support for raw hdev, floppy, and cdrom

Bug fix. Live commit on block devices was broken because the (already
implemented) callbacks accidentally weren't added to all BlockDriver
structs, but only to the 'file' one.

I'll admit that the commit message doesn't make this very clear, but
anyway you should probably trust subsystem maintainers a bit more that
they know what they are doing.

Kevin

Re: [Qemu-devel] [RFC] 1.4 release schedule

[Blue Swirl]

On Thu, Dec 6, 2012 at 10:19 AM, Kevin Wolf <kwolf@redhat.com> wrote:
> Am 05.12.2012 20:58, schrieb Blue Swirl:
>> On Wed, Dec 5, 2012 at 7:41 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>>> Hi,
>>>
>>>
>>> On 12/05/2012 08:28 PM, Blue Swirl wrote:
>>>>
>>>> On Tue, Dec 4, 2012 at 10:00 PM, Anthony Liguori <aliguori@us.ibm.com>
>>>> wrote:
>>>>>
>>>>> Peter Maydell <peter.maydell@linaro.org> writes:
>>>>>
>>>>>> On 4 December 2012 18:38, Blue Swirl <blauwirbel@gmail.com> wrote:
>>>>>>>
>>>>>>> The definition of the hard freeze bothers me. A few patches that went
>>>>>>> in after 1.3-rc0 were not bug fixes but just new features, so the
>>>>>>> difference between soft and hard freezes was not clear.
>>>>>>
>>>>>>
>>>>>> My vote for this would be to adhere to our definition
>>>>>> and only commit bugfixes.
>>>>>
>>>>>
>>>>> Let's get specific.  What was committed post hard freeze that's not a
>>>>> bug fix?
>>>>
>>>>
>>>> d3067b0 Documentation: Update image format information
>>>> a13e5e0 Documentation: Update block cache mode information
>>>> 044d003 qemu-tech.texi: update implemented xtensa features list
>>>
>>>
>>> Adding missing / updating docs to be more accurate is a bug fix,
>>> and one with a very low chance of causing regressions at that.
>>
>> I don't think they are bug fixes but improvements to documentation
>> features. But I agree patches only touching documentation, comment and
>> string contents could be exempted.
>
> Actually these patches contain changes where the documentation didn't
> match the implementation. In other words, the documentation was indeed
> buggy.
>
> They also added some missing things, but as you said, improving
> documentation during the hard freeze isn't a bad thing anyway.
>
>>>> 74c856e tests: add thread pool unit tests
>>>> b2ea25d tests: add AioContext unit tests
>
> And the same is true for tests. They can only improve the release.
>
>> 1bc6b70 block: add bdrv_reopen() support for raw hdev, floppy, and cdrom
>
> Bug fix. Live commit on block devices was broken because the (already
> implemented) callbacks accidentally weren't added to all BlockDriver
> structs, but only to the 'file' one.
>
> I'll admit that the commit message doesn't make this very clear, but
> anyway you should probably trust subsystem maintainers a bit more that
> they know what they are doing.

I'm not objecting to committing patches like these. The description of
hard freeze just should take these into account, something like:

"After the hard feature freeze, the master branch in git is no longer
open for general development. Only bug fixes and improvements to
documentation will be accepted until the next release. Changes to
strings, comments and tests may be considered if they improve the
release."

>
> Kevin

Re: [Qemu-devel] [RFC] 1.4 release schedule

[Andreas Färber]

Am 05.12.2012 20:28, schrieb Blue Swirl:
> On Tue, Dec 4, 2012 at 10:00 PM, Anthony Liguori <aliguori@us.ibm.com> wrote:
>> What was committed post hard freeze that's not a
>> bug fix?
> 
> d3067b0 Documentation: Update image format information
> a13e5e0 Documentation: Update block cache mode information
> 044d003 qemu-tech.texi: update implemented xtensa features list

> a0a7068 target-i386: Enable SSSE3 TCG support

Fixed a regression - cf. commit message

> 80ae416 target-i386/cpu: Add missing flags to Haswell CPU model

Bug fix - keyword "missing", we certainly did not want backwards
compatibility issues for a newly introduced model.

> 42015c9 virtio-rng: fix typos, comments

> e1e54f3 target-i386: cpu: add missing flags to Haswell CPU model

Same as above.

> 339c270 qom: make object_finalize static

Not a bugfix and agreed as not needed for 1.3 but still applied

> 64b625f qdev: simplify (de)allocation of buses
> fde9bf4 qom: make object_delete usable for statically-allocated objects
> 667d22d qdev: move bus removal to object_unparent

Bug fix with preparations

> 74c856e tests: add thread pool unit tests
> b2ea25d tests: add AioContext unit tests
> 21022c9 q35: Add kvmclock support
> a1c9304 ich9: Add i82801b11 dmi-to-pci bridge
> df2d8b3 q35: Introduce q35 pc based chipset emulator
> 678e7b9 ich9: Add smbus
> 4d00636 ich9: Add the lpc chip
> e516572 ich9: Add acpi support and definitions
> 410edd9 pc/piix_pci: factor out smram/pam logic
> d8ee038 pc_piix: Move kvm irq routing functions out of pc_piix.c
> a39e356 pc: Move ioapic_init() from pc_piix.c to pc.c
> 9011a1a pc, pc_piix: split out pc nic initialization
> 723aedd usb-redir: Don't handle interrupt output packets async
> 234e810 usb-redir: Split usb_handle_interrupt_data into separate
> in/out functions
> 33c1a68 usb-bt: Return NAK instead of STALL when interrupt ep has no data
> 1bc6b70 block: add bdrv_reopen() support for raw hdev, floppy, and cdrom
> d132c79 target-mips: Add comments on POOL32Axf encoding

Generally I have been in favor of allowing patches that improve the
quality of the release while not introducing regressions, like typo
fixes or documentation updates. This cycle I was much stricter with the
only-bugfixes rule so I don't understand your complaint.

If for any reason you think a certain PATCH or PULL should not be
applied at a certain point in time, feel free to reply before it gets
committed/merged, which is usually several days later.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [RFC] 1.4 release schedule

[Blue Swirl]

On Thu, Dec 6, 2012 at 9:01 AM, Andreas Färber <afaerber@suse.de> wrote:
> Am 05.12.2012 20:28, schrieb Blue Swirl:
>> On Tue, Dec 4, 2012 at 10:00 PM, Anthony Liguori <aliguori@us.ibm.com> wrote:
>>> What was committed post hard freeze that's not a
>>> bug fix?
>>
>> d3067b0 Documentation: Update image format information
>> a13e5e0 Documentation: Update block cache mode information
>> 044d003 qemu-tech.texi: update implemented xtensa features list
>
>> a0a7068 target-i386: Enable SSSE3 TCG support
>
> Fixed a regression - cf. commit message
>
>> 80ae416 target-i386/cpu: Add missing flags to Haswell CPU model
>
> Bug fix - keyword "missing", we certainly did not want backwards
> compatibility issues for a newly introduced model.
>
>> 42015c9 virtio-rng: fix typos, comments
>
>> e1e54f3 target-i386: cpu: add missing flags to Haswell CPU model
>
> Same as above.
>
>> 339c270 qom: make object_finalize static
>
> Not a bugfix and agreed as not needed for 1.3 but still applied
>
>> 64b625f qdev: simplify (de)allocation of buses
>> fde9bf4 qom: make object_delete usable for statically-allocated objects
>> 667d22d qdev: move bus removal to object_unparent
>
> Bug fix with preparations
>
>> 74c856e tests: add thread pool unit tests
>> b2ea25d tests: add AioContext unit tests
>> 21022c9 q35: Add kvmclock support
>> a1c9304 ich9: Add i82801b11 dmi-to-pci bridge
>> df2d8b3 q35: Introduce q35 pc based chipset emulator
>> 678e7b9 ich9: Add smbus
>> 4d00636 ich9: Add the lpc chip
>> e516572 ich9: Add acpi support and definitions
>> 410edd9 pc/piix_pci: factor out smram/pam logic
>> d8ee038 pc_piix: Move kvm irq routing functions out of pc_piix.c
>> a39e356 pc: Move ioapic_init() from pc_piix.c to pc.c
>> 9011a1a pc, pc_piix: split out pc nic initialization
>> 723aedd usb-redir: Don't handle interrupt output packets async
>> 234e810 usb-redir: Split usb_handle_interrupt_data into separate
>> in/out functions
>> 33c1a68 usb-bt: Return NAK instead of STALL when interrupt ep has no data
>> 1bc6b70 block: add bdrv_reopen() support for raw hdev, floppy, and cdrom
>> d132c79 target-mips: Add comments on POOL32Axf encoding
>
> Generally I have been in favor of allowing patches that improve the
> quality of the release while not introducing regressions, like typo
> fixes or documentation updates. This cycle I was much stricter with the
> only-bugfixes rule so I don't understand your complaint.

I'm just whining about the small mismatch between description of hard
freeze and reality. All of the patches were OK and they probably
improved the release, whether they matched the description or not.

>
> If for any reason you think a certain PATCH or PULL should not be
> applied at a certain point in time, feel free to reply before it gets
> committed/merged, which is usually several days later.

But that is a part of the problem, I'm not so sure which patches or
pulls should be applied after the hard freeze.

>
> Regards,
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [RFC] 1.4 release schedule

[Peter Maydell]

On 3 December 2012 21:30, Anthony Liguori <aliguori@us.ibm.com> wrote:
> I've put up a strawman schedule on the wiki:
>
> http://wiki.qemu.org/Planning/1.4

The definition of 'soft freeze' on this page ("Major features
should have initial code committed") and the definition on
the page http://wiki.qemu.org/Planning/SoftFeatureFreeze
which it links to ("any major feature should have some code
posted to the qemu-devel mailing list") disagree. Which
is right? I think in practice we're using "code committed",
which seems to me the right choice.

-- PMM