From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37244) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuLza-0005o7-Gc for qemu-devel@nongnu.org; Thu, 05 Nov 2015 09:58:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZuLzX-0000tW-AV for qemu-devel@nongnu.org; Thu, 05 Nov 2015 09:58:22 -0500 Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]:32955) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuLzX-0000tK-4n for qemu-devel@nongnu.org; Thu, 05 Nov 2015 09:58:19 -0500 Received: by wmeg8 with SMTP id g8so16625719wme.0 for ; Thu, 05 Nov 2015 06:58:18 -0800 (PST) Sender: Paolo Bonzini References: <1446725610.30393.23.camel@redhat.com> <563B586A.1060908@de.ibm.com> <563B6148.8030602@redhat.com> From: Paolo Bonzini Message-ID: <563B6E84.9090709@redhat.com> Date: Thu, 5 Nov 2015 15:58:12 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] virtio-gpu doesn't build if you do a linux-headers update from kvm/next List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Christian Borntraeger , Gerd Hoffmann , QEMU Developers 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