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

On Tue, May 22, 2018 at 11:07:04AM +0100, Peter Maydell wrote: > On 30 April 2018 at 11:33, Daniel P. Berrangé wrote: > > a) Bump major version once a year, so we'll have 3.0, 3.1, 3.3, > > 4.0, 4.1, 4.2, 5.0, ...etc We missed the first release this > > year, so we would only have 3.0

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

On 02/05/2018 11:10, Daniel P. Berrangé wrote: >> it would allow to postpone incompatible removals to relatively seldom >> major releases, add new features during more often minor releases, and >> fix bugs during regular patch releases. >> >> major releases can be scheduled every 1-2 years, for

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

On 04/27/2018 12:51 PM, Peter Maydell wrote: > Hi; I usually let people forget about releases for a month or > so before bringing this topic up, but: [...] > That will make the next release be 3.0.0. [...] > (3) retrospective, lessons learned [...] > * provide your opinions here ? Maybe v3 is a

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

On 30 April 2018 at 11:33, Daniel P. Berrangé wrote: > a) Bump major version once a year, so we'll have 3.0, 3.1, 3.3, > 4.0, 4.1, 4.2, 5.0, ...etc We missed the first release this > year, so we would only have 3.0 and 3.1 this year. I realised we didn't really

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

On Sun, 29 Apr 2018 09:56:37 -0500 Richard Henderson wrote: > On 04/27/2018 02:01 PM, Michal Suchánek wrote: > > Is there any reason why the 64bit emulator would not run on 32bit > > system? The emulated 64bit system is .. emulated after all. > > It does run, but

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

On 07.05.2018 15:38, Kashyap Chamarthy wrote: > On Thu, May 03, 2018 at 03:16:10PM +0100, Daniel P. Berrangé wrote: >> On Thu, May 03, 2018 at 04:06:19PM +0200, Thomas Huth wrote: >>> On 03.05.2018 15:43, Gerd Hoffmann wrote: > > [...] > (a) major equals year, minor equals month (ubuntu

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

Am 07.05.2018 um 07:33 hat Thomas Huth geschrieben: > On 04.05.2018 19:30, Richard Henderson wrote: > > On 05/04/2018 06:20 AM, Kevin Wolf wrote: > >> I'm not sure what the exact systemd model is, but as we came to the > >> conclusion that there is no semantic difference between major and minor >

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

On Thu, May 03, 2018 at 03:16:10PM +0100, Daniel P. Berrangé wrote: > On Thu, May 03, 2018 at 04:06:19PM +0200, Thomas Huth wrote: > > On 03.05.2018 15:43, Gerd Hoffmann wrote: [...] > > > (a) major equals year, minor equals month (ubuntu style). > > > (b) major equals year, minor counts up

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

On 04.05.2018 19:30, Richard Henderson wrote: > On 05/04/2018 06:20 AM, Kevin Wolf wrote: >> I'm not sure what the exact systemd model is, but as we came to the >> conclusion that there is no semantic difference between major and minor >> version number for QEMU, I'd just merge them. >> >> This

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

On 2018-05-02 09:59, Daniel P. Berrangé wrote: > On Wed, May 02, 2018 at 12:43:10AM -0700, Liviu Ionescu wrote: >> On 2 May 2018 at 10:38:09, Cornelia Huck (coh...@redhat.com) wrote: >> >>> a) Bump major version once a year, so we'll have 3.0, 3.1, >>> 3.3, >> 4.0, 4.1, 4.2, 5.0, ...etc We

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

On 05/04/2018 06:20 AM, Kevin Wolf wrote: > I'm not sure what the exact systemd model is, but as we came to the > conclusion that there is no semantic difference between major and minor > version number for QEMU, I'd just merge them. > > This would result in 3.0 for the next release, 3.1 etc.

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

Am 04.05.2018 um 15:53 hat Thomas Huth geschrieben: > On 04.05.2018 15:20, Kevin Wolf wrote: > > Am 03.05.2018 um 15:43 hat Gerd Hoffmann geschrieben: > >> On Thu, May 03, 2018 at 10:26:40AM +0100, Peter Maydell wrote: > >>> On 3 May 2018 at 10:07, Daniel P. Berrangé wrote: >

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

On 04.05.2018 15:20, Kevin Wolf wrote: > Am 03.05.2018 um 15:43 hat Gerd Hoffmann geschrieben: >> On Thu, May 03, 2018 at 10:26:40AM +0100, Peter Maydell wrote: >>> On 3 May 2018 at 10:07, Daniel P. Berrangé wrote: On Thu, May 03, 2018 at 08:21:00AM +0100, Stefan

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

Am 03.05.2018 um 15:43 hat Gerd Hoffmann geschrieben: > On Thu, May 03, 2018 at 10:26:40AM +0100, Peter Maydell wrote: > > On 3 May 2018 at 10:07, Daniel P. Berrangé wrote: > > > On Thu, May 03, 2018 at 08:21:00AM +0100, Stefan Hajnoczi wrote: > > >> I don't see an issue with

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

On Thu, May 03, 2018 at 11:52:20PM +0200, Laurent Vivier wrote: > Le 01/05/2018 à 14:24, Stefan Hajnoczi a écrit : > > On Fri, Apr 27, 2018 at 04:51:03PM +0100, Peter Maydell wrote: > >> (2) release timing: > >> * usual schedule would give us a next release mid-to-late August > >> * unless I can

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

On Thu, May 03, 2018 at 07:50:41PM +0100, Dr. David Alan Gilbert wrote: > * Stefan Hajnoczi (stefa...@redhat.com) wrote: > > On Thu, May 03, 2018 at 04:16:41PM +0200, Cédric Le Goater wrote: > > > Coming back to the initial motivation that Peter pointed out, would > > > the goal to be able to run

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

On 4 May 2018 at 09:16, Stefan Hajnoczi wrote: > On Fri, May 04, 2018 at 07:29:20AM +0200, Markus Armbruster wrote: >> Stefan Hajnoczi writes: >> > So to clarify, three separate steps: >> > >> > 1. Get rid of target-specific #ifdefs >> >> 1. can be

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

On Fri, May 04, 2018 at 07:29:20AM +0200, Markus Armbruster wrote: > Stefan Hajnoczi writes: > > So to clarify, three separate steps: > > > > 1. Get rid of target-specific #ifdefs > > 1. can be incremental. Something for > ?

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

Stefan Hajnoczi writes: [...] > So to clarify, three separate steps: > > 1. Get rid of target-specific #ifdefs ... and compile just once instead of per target, speeding up the build > 2a. Modular QEMU, single binary > 2b. Heterogenous QEMU > > 2a and 2b are independent but

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

Le 01/05/2018 à 14:24, Stefan Hajnoczi a écrit : > On Fri, Apr 27, 2018 at 04:51:03PM +0100, Peter Maydell wrote: >> (2) release timing: >> * usual schedule would give us a next release mid-to-late August >> * unless I can persuade Stefan to do the release management this >>cycle we might

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

* Stefan Hajnoczi (stefa...@redhat.com) wrote: > On Thu, May 03, 2018 at 04:16:41PM +0200, Cédric Le Goater wrote: > > Coming back to the initial motivation that Peter pointed out, would > > the goal to be able to run vcpus of different architectures ? It would > > certainly be interesting to

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

On Thu, May 03, 2018 at 04:16:41PM +0200, Cédric Le Goater wrote: > Coming back to the initial motivation that Peter pointed out, would > the goal to be able to run vcpus of different architectures ? It would > certainly be interesting to model a platform, specially if we can > synchronize the

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

On 05/03/2018 11:42 AM, Thomas Huth wrote: > On 03.05.2018 11:33, Daniel P. Berrangé wrote: >> On Wed, May 02, 2018 at 01:05:21PM +0100, Peter Maydell wrote: >>> On 2 May 2018 at 12:58, Daniel P. Berrangé wrote: I'm curious what is the compelling benefit of having a

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

On 03.05.2018 15:43, Gerd Hoffmann wrote: > On Thu, May 03, 2018 at 10:26:40AM +0100, Peter Maydell wrote: >> On 3 May 2018 at 10:07, Daniel P. Berrangé wrote: >>> On Thu, May 03, 2018 at 08:21:00AM +0100, Stefan Hajnoczi wrote: I don't see an issue with time-based

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

On Thu, 3 May 2018 16:06:19 +0200 Thomas Huth wrote: > On 03.05.2018 15:43, Gerd Hoffmann wrote: > > On Thu, May 03, 2018 at 10:26:40AM +0100, Peter Maydell wrote: > >> On 3 May 2018 at 10:07, Daniel P. Berrangé wrote: > >>> On Thu, May 03, 2018 at

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

On Thu, May 03, 2018 at 04:06:19PM +0200, Thomas Huth wrote: > On 03.05.2018 15:43, Gerd Hoffmann wrote: > > On Thu, May 03, 2018 at 10:26:40AM +0100, Peter Maydell wrote: > >> On 3 May 2018 at 10:07, Daniel P. Berrangé wrote: > >>> On Thu, May 03, 2018 at 08:21:00AM +0100,

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

On 05/03/2018 11:45 AM, Daniel P. Berrangé wrote: > On Thu, May 03, 2018 at 11:42:23AM +0200, Thomas Huth wrote: >> On 03.05.2018 11:33, Daniel P. Berrangé wrote: >>> On Wed, May 02, 2018 at 01:05:21PM +0100, Peter Maydell wrote: On 2 May 2018 at 12:58, Daniel P. Berrangé

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

On Thu, May 03, 2018 at 10:26:40AM +0100, Peter Maydell wrote: > On 3 May 2018 at 10:07, Daniel P. Berrangé wrote: > > On Thu, May 03, 2018 at 08:21:00AM +0100, Stefan Hajnoczi wrote: > >> I don't see an issue with time-based numbering schemes. Ubuntu made it > >> popular

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

On 03.05.2018 11:31, Daniel P. Berrangé wrote: > On Thu, May 03, 2018 at 10:26:40AM +0100, Peter Maydell wrote: >> On 3 May 2018 at 10:07, Daniel P. Berrangé wrote: >>> On Thu, May 03, 2018 at 08:21:00AM +0100, Stefan Hajnoczi wrote: I don't see an issue with time-based

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

On Thu, May 03, 2018 at 11:42:23AM +0200, Thomas Huth wrote: > On 03.05.2018 11:33, Daniel P. Berrangé wrote: > > On Wed, May 02, 2018 at 01:05:21PM +0100, Peter Maydell wrote: > >> On 2 May 2018 at 12:58, Daniel P. Berrangé wrote: > >>> I'm curious what is the compelling

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

On 03.05.2018 11:33, Daniel P. Berrangé wrote: > On Wed, May 02, 2018 at 01:05:21PM +0100, Peter Maydell wrote: >> On 2 May 2018 at 12:58, Daniel P. Berrangé wrote: >>> I'm curious what is the compelling benefit of having a single fat QEMU >>> binary that included all

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

On 3 May 2018 at 10:07, Daniel P. Berrangé wrote: > On Thu, May 03, 2018 at 08:21:00AM +0100, Stefan Hajnoczi wrote: >> I don't see an issue with time-based numbering schemes. Ubuntu made it >> popular and other projects (like DPDK) are doing the same thing now. >> >> The

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

On Wed, May 02, 2018 at 01:05:21PM +0100, Peter Maydell wrote: > On 2 May 2018 at 12:58, Daniel P. Berrangé wrote: > > I'm curious what is the compelling benefit of having a single fat QEMU > > binary that included all archiectures at once ? > > The motivation is "I want to

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

On Thu, 3 May 2018 10:07:27 +0100 Daniel P. Berrangé wrote: > On Thu, May 03, 2018 at 08:21:00AM +0100, Stefan Hajnoczi wrote: > > On Wed, May 02, 2018 at 09:02:00AM +0100, Daniel P. Berrangé wrote: > > > On Wed, May 02, 2018 at 09:44:03AM +0200, Gerd Hoffmann wrote: > >

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

On Thu, May 03, 2018 at 10:26:40AM +0100, Peter Maydell wrote: > On 3 May 2018 at 10:07, Daniel P. Berrangé wrote: > > On Thu, May 03, 2018 at 08:21:00AM +0100, Stefan Hajnoczi wrote: > >> I don't see an issue with time-based numbering schemes. Ubuntu made it > >> popular

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

On Thu, May 03, 2018 at 08:21:00AM +0100, Stefan Hajnoczi wrote: > On Wed, May 02, 2018 at 09:02:00AM +0100, Daniel P. Berrangé wrote: > > On Wed, May 02, 2018 at 09:44:03AM +0200, Gerd Hoffmann wrote: > > > Hi, > > > > > > > > If we bump the major version each year anyway, why not go the whole

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

On Wed, May 02, 2018 at 09:02:00AM +0100, Daniel P. Berrangé wrote: > On Wed, May 02, 2018 at 09:44:03AM +0200, Gerd Hoffmann wrote: > > Hi, > > > > > > If we bump the major version each year anyway, why not go the whole way > > > > and use 2018.1, 2018.2, ... (or even .)? The nice thing > > >

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

On Mon, Apr 30, 2018 at 04:23:59PM +0200, Greg Kurz wrote: > On Fri, 27 Apr 2018 16:51:03 +0100 > 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

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

On 2 May 2018 at 12:58, Daniel P. Berrangé wrote: > I'm curious what is the compelling benefit of having a single fat QEMU > binary that included all archiectures at once ? The motivation is "I want to model a board with an SoC that has both Arm cores and Microblaze cores".

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

On Fri, Apr 27, 2018 at 06:42:07PM +0200, Thomas Huth wrote: > On 27.04.2018 18:24, Peter Maydell wrote: > > On 27 April 2018 at 17:17, Thomas Huth wrote: > >> By the way, just another crazy idea for v3.0 (i.e. feel free to turn it > >> down immediately ;-)): Since compilation

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

On 2 May 2018 at 11:41, Laszlo Ersek wrote: > What about guest RAM size (more precisely, guest-phys address space)? > > The x86_64 target might want to use tens of GBs of guest-phys address > space, e.g. for cold-plugged RAM, for DIMM hotplug, for 64-bit PCI MMIO > aperture. To

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

On 04/29/18 16:56, Richard Henderson wrote: > On 04/27/2018 02:01 PM, Michal Suchánek wrote: >> Is there any reason why the 64bit emulator would not run on 32bit >> system? The emulated 64bit system is .. emulated after all. > > It does run, but it requires that the 32-bit host perform

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

On Wed, 2 May 2018 09:16:32 +0100 Daniel P. Berrangé wrote: > On Wed, May 02, 2018 at 09:29:39AM +0200, Markus Armbruster wrote: > > How can I provide both the old command line in all its quirky glory and > > a QAPIfied command line? Unless we can, the deprecation policy

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

On 02.05.2018 11:03, Liviu Ionescu wrote: > On 2 May 2018 at 11:13:49, Thomas Huth (th...@redhat.com) wrote: > >> https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features > > Thank you, Thomas. > >> It took quite a while to get a consensus on that policy, so I don't >> think that we want

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

On Wed, 2 May 2018 02:03:14 -0700 Liviu Ionescu wrote: > On 2 May 2018 at 11:13:49, Thomas Huth (th...@redhat.com) wrote: > > > https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features > > Thank you, Thomas. > > > It took quite a while to get a consensus on that

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

On Wed, May 02, 2018 at 02:03:14AM -0700, Liviu Ionescu wrote: > On 2 May 2018 at 11:13:49, Thomas Huth (th...@redhat.com) wrote: > > > https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features > > Thank you, Thomas. > > > It took quite a while to get a consensus on that policy, so I don't

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

On 2 May 2018 at 11:13:49, Thomas Huth (th...@redhat.com) wrote: > https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features Thank you, Thomas. > It took quite a while to get a consensus on that policy, so I don't > think that we want to sacrifice that for semver. ok, this might be a

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

On Wed, 2 May 2018 01:02:49 -0700 Liviu Ionescu wrote: > On 2 May 2018 at 10:59:07, Daniel P. Berrangé (berra...@redhat.com) wrote: > > > Our deprecation policy lets us include incompatible > > changes in *any* release. > > can you elaborate on this? > > where is this

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

On Wed, May 02, 2018 at 09:29:39AM +0200, Markus Armbruster wrote: > Peter Maydell writes: > > > On 27 April 2018 at 17:17, Thomas Huth wrote: > >> On 27.04.2018 17:51, Peter Maydell wrote: > >>> Hi; I usually let people forget about releases for a

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

On 02.05.2018 10:02, Liviu Ionescu wrote: > On 2 May 2018 at 10:59:07, Daniel P. Berrangé (berra...@redhat.com) wrote: > >> Our deprecation policy lets us include incompatible >> changes in *any* release. > > can you elaborate on this? > > where is this policy defined?

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

On 2 May 2018 at 10:59:07, Daniel P. Berrangé (berra...@redhat.com) wrote: > Our deprecation policy lets us include incompatible > changes in *any* release. can you elaborate on this? where is this policy defined? thank you, Liviu

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

On Wed, May 02, 2018 at 09:44:03AM +0200, Gerd Hoffmann wrote: > Hi, > > > > If we bump the major version each year anyway, why not go the whole way > > > and use 2018.1, 2018.2, ... (or even .)? The nice thing > > > about that is that you can see at a glance when the release took place. > > >

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

On Wed, May 02, 2018 at 12:43:10AM -0700, Liviu Ionescu wrote: > On 2 May 2018 at 10:38:09, Cornelia Huck (coh...@redhat.com) wrote: > > > > > >> a) Bump major version once a year, so we'll have 3.0, 3.1, > > 3.3, > > > >> 4.0, 4.1, 4.2, 5.0, ...etc We missed the first release this > > > >> year,

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

Hi, > > If we bump the major version each year anyway, why not go the whole way > > and use 2018.1, 2018.2, ... (or even .)? The nice thing > > about that is that you can see at a glance when the release took place. > > ... or simply drop the first two digits and call them 18.1, 18.2, ...? We

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

On 2 May 2018 at 10:38:09, Cornelia Huck (coh...@redhat.com) wrote: > > > >> a) Bump major version once a year, so we'll have 3.0, 3.1, > 3.3, > > >> 4.0, 4.1, 4.2, 5.0, ...etc We missed the first release this > > >> year, so we would only have 3.0 and 3.1 this year. > > >> > > >> b) Bump major

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

On Mon, 30 Apr 2018 19:36:40 +0200 Thomas Huth wrote: > On 30.04.2018 13:21, Cornelia Huck wrote: > > On Mon, 30 Apr 2018 11:33:12 +0100 > > Daniel P. Berrangé wrote: > [...] > >> Given, that we have a clear deprecation process now, my view is that > >>

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

Peter Maydell writes: > On 27 April 2018 at 17:17, Thomas Huth 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

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

On 1 May 2018 at 13:24, Stefan Hajnoczi wrote: > On Fri, Apr 27, 2018 at 04:51:03PM +0100, Peter Maydell wrote: >> (2) release timing: >> * usual schedule would give us a next release mid-to-late August >> * unless I can persuade Stefan to do the release management this >>

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

On Fri, Apr 27, 2018 at 04:51:03PM +0100, Peter Maydell wrote: > (2) release timing: > * usual schedule would give us a next release mid-to-late August > * unless I can persuade Stefan to do the release management this >cycle we might need to wind that in by a couple of weeks so >it's

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

On 30.04.2018 13:21, Cornelia Huck wrote: > On Mon, 30 Apr 2018 11:33:12 +0100 > Daniel P. Berrangé wrote: [...] >> Given, that we have a clear deprecation process now, my view is that >> we should formally declare that major version numbers changes are >> meaningless. As

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

On Mon, Apr 30, 2018 at 04:23:59PM +0200, Greg Kurz wrote: > On Fri, 27 Apr 2018 16:51:03 +0100 > 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

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

On 30 April 2018 at 15:23, Greg Kurz wrote: > On Fri, 27 Apr 2018 16:51:03 +0100 > 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

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

On Fri, 27 Apr 2018 16:51:03 +0100 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

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

On Mon, 30 Apr 2018 11:33:12 +0100 Daniel P. Berrangé wrote: > On Fri, Apr 27, 2018 at 04:51:03PM +0100, 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

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

On Fri, Apr 27, 2018 at 09:01:20PM +0200, Michal Suchánek wrote: > On Fri, 27 Apr 2018 17:24:38 +0100 > Peter Maydell wrote: > > > On 27 April 2018 at 17:17, Thomas Huth wrote: > > > On 27.04.2018 17:51, Peter Maydell wrote: > > >> Hi; I usually let

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

On Fri, Apr 27, 2018 at 04:51:03PM +0100, 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

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

On 30 April 2018 at 11:06, Paolo Bonzini wrote: > On 27/04/2018 18:42, Thomas Huth wrote: >> On 27.04.2018 18:24, Peter Maydell wrote: >>> (In the utopian far future I'd like us to have just one QEMU >>> executable that could handle all architectures at once :-)) >> >> Yes,

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

On 27/04/2018 18:42, Thomas Huth wrote: > On 27.04.2018 18:24, Peter Maydell wrote: >> (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. Not

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

On 30 April 2018 at 10:29, Cornelia Huck wrote: > On a related note: During the development phase, does it make more > sense to collect stuff until you have a big pile of patches, or is it > better (from an integration perspective) to do more frequent, smaller > pull requests?

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

On Fri, 27 Apr 2018 16:51:03 +0100 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

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

On 04/27/2018 02:01 PM, Michal Suchánek wrote: > Is there any reason why the 64bit emulator would not run on 32bit > system? The emulated 64bit system is .. emulated after all. It does run, but it requires that the 32-bit host perform double-word arithmetic to emulate the 64-bit guest. When the

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

On Fri, 27 Apr 2018 17:24:38 +0100 Peter Maydell wrote: > On 27 April 2018 at 17:17, Thomas Huth 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

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

On 27.04.2018 18:24, Peter Maydell wrote: > On 27 April 2018 at 17:17, Thomas Huth 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

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

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

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

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

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

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