Re: [Qemu-devel] virtio-gpu doesn't build if you do a linux-headers update from kvm/next

[Peter Maydell]

On 5 November 2015 at 14:58, Paolo Bonzini <address@hidden> wrote:
> I think the main issue is that right now we have a very long freeze
> period.  It would be nice to know why (e.g. what kind of bugs are fixed?
>  are they release blockers only?) and whether a shorter development
> period could also lead to a shorter hard freeze period.

My gut feeling is that what typically happens is this:
 * at or just after softfreeze deadline, we apply a bunch of
   pull requests for big features
 * during softfreeze there's usually one big thing that hits
   middling-to-late, and so in the last week or so we need to
   scrabble around fixing up the stuff that broke when these
   features hit so that rc0 isn't too awful
   [this cycle, that's looking like it might be record-and-replay]
 * hardfreeze is when other people than the core dev community
   think about testing stuff, and we get the resulting bug reports
 * there's always one or two last release-critical issues that don't
   get fixed until very late. This is why hardfreeze always slips
   by an extra week or so (and the last week of hardfreeze is always
   "no changes between final rc and real release").

> Perhaps even 2-ish months, for example it could be 1 month development
> (4.5 weeks) + 2 weeks to rc0 + 3.5 weeks to final (i.e. aim for final
> equal to -rc3).
>
> Or even change soft freeze to "time to respin pending pull requests if
> they fail" (i.e. *pull requests* must be on the list, not patches!) and
> shorten it to 1 week.  That would give 4.5 weeks development + 1 week to
> rc0 + 3.5 weeks to final.

I would be sceptical that we could get a non-broken rc0 if we
put it that close to the thundering-herd of last minute feature pulls.

thanks
- PMM