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: Peter Maydell
Subject: Re: [Qemu-devel] release retrospective, next release timing, numbering
Date: Fri, 27 Apr 2018 17:24:38 +0100

On 27 April 2018 at 17:17, Thomas Huth <address@hidden> wrote:
> 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

Oh, hey, I hadn't noticed that. That's as good a reason as
any other!

> 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?).

I think Markus' backward-compatibility rubber chicken may prevent
us from removing those executables...

(In the utopian far future I'd like us to have just one QEMU
executable that could handle all architectures at once :-))

thanks
-- PMM



reply via email to

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