Re: [Qemu-devel] [ANNOUNCE] QEMU 1.1-rc2 release

[Anthony Liguori <anthony@codemonkey.ws>]

On 05/15/2012 11:42 AM, Peter Maydell wrote:
> On 15 May 2012 17:38, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>> Known issues == release blockers.  I'm not willing to block a release for
>> uninitialized memory access unless it's be validated by a human (and if it
>> has, there probably will be a patch already).
>>
>> Likewise, memory leaks are not going to block the release unless they are
>> significant.
>>
>> An TCG deficiencies don't count as a release blocker unless it's a
>> regression.
>
> In this case it is a regression...

At what point did it regress?  I don't recall win64 ever working uner TCG...

> Anyway, my point is not "these things must go in" but that it's very
> hard to tell from this side whether a patch is in the state:
>   (a) in your queue and will go into this rc
>   (b) missed the boat for this rc but will be in the next
>   (c) completely overlooked and needs pinging/yelling about
>   (d) judged not important enough to justify fixing in this release

It's it not tagged '1.1' than I am not considering it for 1.1.

If it's tagged with 1.1 *and* in a subsystem with an active submaintainer, I 
would expect the submaintainer to handle it.  I do keep track of it though until 
someone responds with "Thanks, Applied." and will follow up with patches that 
fall into this category.

> The usual "assume it's gone into somebody's tree and ping again
> in a week or two" doesn't work when release candidates are done
> on a schedule of every week or so, you need a more positive ack
> and tracking IMHO.

If you've posted a patch for 1.1 and it's a couple days old without feedback, 
then you probably should ping the appropriate maintainer about it.

FWIW, I don't see any pending 1.1 patches from you so I don't know if this is a 
theoretical concern or a practical one.

Regards,

Anthony Liguori

>
> -- PMM