qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] release retrospective, next release timing, numbering


From: Thomas Huth
Subject: Re: [Qemu-devel] release retrospective, next release timing, numbering
Date: Fri, 27 Apr 2018 18:17:27 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 27.04.2018 17:51, Peter Maydell wrote:
> Hi; I usually let people forget about releases for a month or
> so before bringing this topic up, but:
> 
> (1) do we want to call the next release 2.13, or something else?
> There's no particular reason to bump to 3.0 except some combination of
>  * if we keep going like this we'll get up to 2.42, which starts to
>    get silly
>  * Linus-style "avoid being too predictable"
>  * triskaidekaphobia

and maybe:

 * Celebrate 15 years of QEMU
 * Use 3.x to sympathize with Python3 and GTK3
 * Avoid that users mix up 2.13 with 2.1.3 and think that their
   QEMU 2.9 is way newer than 2.13
 * Celebrate that we could get rid of the -net vlan stuff
 * Finally stop me from sending stupid I-want-v3.0 mails

By the way, just another crazy idea for v3.0 (i.e. feel free to turn it
down immediately ;-)): Since compilation and testing time for QEMU is
really huge, what do you think if we got rid of some QEMU binaries?
qemu-system-aarch64 is a superset of qemu-system-arm, qemu-system-x86_64
is a superset of qemu-system-i386 and qemu-system-ppc64 is a superset of
qemu-system-ppc (and qemu-system-ppcemb). Would be feasible to get rid
of the subset binaries with some work? (I think they were especially
useful on 32-bit machines in the past, but most people are using 64-bit
machines nowadays, aren't they?).

 Happy Friday,
  Thomas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]