[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:42:07 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 |
On 27.04.2018 18:24, Peter Maydell wrote:
> 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...
Markus seems currently to be in the mood to cut down the testing time
(see the current qom-test mail thread), so maybe we can convince him ... ;-)
> (In the utopian far future I'd like us to have just one QEMU
> executable that could handle all architectures at once :-))
Yes, that would be great ... but that's really distant future, I guess.
Thomas
- [Qemu-devel] release retrospective, next release timing, numbering, Peter Maydell, 2018/04/27
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Thomas Huth, 2018/04/27
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Peter Maydell, 2018/04/27
- Re: [Qemu-devel] release retrospective, next release timing, numbering,
Thomas Huth <=
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Paolo Bonzini, 2018/04/30
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Peter Maydell, 2018/04/30
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Michal Suchánek, 2018/04/27
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Richard Henderson, 2018/04/29
- Re: [Qemu-devel] release retrospective, next release timing, numbering, Daniel P . Berrangé, 2018/04/30
Re: [Qemu-devel] release retrospective, next release timing, numbering, Cornelia Huck, 2018/04/30
Re: [Qemu-devel] release retrospective, next release timing, numbering, Daniel P . Berrangé, 2018/04/30