Re: [Qemu-devel] [PATCH] target-mips: fix call to memset in soft reset code

[Christian Borntraeger <borntraeger@de.ibm.com>]

On 05/12/2016 10:06 AM, Cornelia Huck wrote:
> On Thu, 12 May 2016 09:40:21 +0200
> Christian Borntraeger <borntraeger@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.

Yes, there are some problems here. But I fully agree with Peter.
We really do need more infrastructure and people to
- maintain stable release much more often and for more than one release
  (that would allow to be less strict before a release)
- have something like qemu-next
- have something like kbuild test robot (aka 0-Day)
- have releases more often (to reduce the pressure to rush in)

Christian