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

[Paolo Bonzini <pbonzini@redhat.com>]

On 05/11/2015 15:30, Peter Maydell wrote:
> I suspect at least some of the other subsystems work the same way.

I try not to have a for-this-release tree during hard freeze. :)

> > The main issue is that shorter cycles may mean fewer and bigger pull
> > requests.  It also means more awareness of conflicts is needed.  We
> > definitely lack the continuous integration infrastructure that is needed
> > for that.
>
> I think it works for the kernel because the different subsystems
> have large communities of their own and the subtrees get a
> reasonable amount of testing as a result, plus there are
> efforts like linux-next to pre-check subtrees for conflicts
> before an actual merge attempt happens.

Yes, that's what I meant for continuous integration.

My hunch is that conflicts outside .json or trace-events are rare.  It
would be an interesting experiment if someone was willing to prepare a
daily or bi-weekly (Mon/Thu) "qemu-next" branch for a few weeks during
the 2.6 development.

> I don't think the QEMU
> community is big enough for the kernel's dev practices to be
> reasonably applicable to us.

On the other hand, something like "qemu-next" would be much easier to
use daily than linux-next.

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.

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.  This is still very different from the
kernel's merge window model.  OTOH with such a 2 months cadence we could
probably get rid of stable releases altogether, limiting them to
security issues.

So, there's room for experimenting.  That said, we probably agree that 4
months and staying on time is better than saying officially 3 months and
delaying every release.

Paolo