On Thu, 12 May 2016 09:40:21 +0200 Christian Borntraeger <borntrae...@de.ibm.com> wrote:
> Maybe a topic for this years QEMU summit could be to talk about > release process and release criterias. +1 to that. > We could > a: allow more patches , e.g. I thing that this patch would be have > been taken in the Linux kernel a day before the release, see for > example what is applied 4 days before a release as network fixes: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4d8bbbff1227bbb27fdb02b6db17f080c06eedad > 22 files changed, 258 insertions, 86 deletions Personally, I would probably go for something between applying this patch and that networking pull :) > b: as we are strict and only apply hand selected patches, regressions are > very unlikely, so we could release sooner. For example the CVE fixes could > have just been taken and rc5 being released as final. (which we did anyway > but 3 days later) > > c: we consider everything fine and keep the process > > d: better ideas One thing I've noticed is that softfreeze/early hardfreeze qemus often seem more unstable than versions earlier in the development cycle - probably because people panic and rush to get code in for the release. I don't know if stricter rules/enforcement of what is supposed to go in during softfreeze/hardfreeze would help here.
