On 5 November 2015 at 14:01, Paolo Bonzini <pbonz...@redhat.com> wrote: > On 05/11/2015 14:44, Peter Maydell wrote: >> We used to have 3 month releases, but I think we found that these >> were too short: If you have about a month hardfreeze and a month >> softfreeze then you only have a month of open feature development, >> which seems pretty short to me. > > It's short unless you assume that development goes on in private > maintainer trees during hard freeze. It's always happened at least for > the block layer, and probably for everything else. About 400 commits in > 2.5 were authored before the 2.4 release.
Mostly I don't have a for-the-next-release tree for target-arm during freeze unless I completely can't avoid it, because it's a pain to maintain both. I suspect at least some of the other subsystems work the same way. People can develop during freeze, and post patches to the list, but whether they get reviewed or picked up into submaintainer trees is a different question. > 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. I don't think the QEMU community is big enough for the kernel's dev practices to be reasonably applicable to us. thanks -- PMM
