On 15 May 2012 17:38, Anthony Liguori <anth...@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... 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 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. -- PMM
