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

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

[Peter Maydell]

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
but maybe we should anyway?

(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 definitely done by the middle of August, to avoid a clash
   with a personal commitment
 * so probably hardfreeze 10th July, softfreeze 3rd July

(3) retrospective, lessons learned &c
 * please remember that if every single submaintainer submits
   a pull request on the morning of an RC, it is physically
   not possible for me to process all those pulls in time to
   tag the RC that day. We had several RCs which got delayed
   by a day because of this; please try to submit earlier
   rather than later...
 * provide your opinions here ?

thanks
-- PMM

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

[Thomas Huth]

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

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

[Peter Maydell]

On 27 April 2018 at 17:17, Thomas Huth <thuth@redhat.com> 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

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

[Thomas Huth]

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

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

[Paolo Bonzini]

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 _that_ impossible though.  Peter Crosthwaite had some initial
patches for multi-arch support.

Paolo

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

[Peter Maydell]

On 30 April 2018 at 11:06, Paolo Bonzini <pbonzini@redhat.com> 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, that would be great ... but that's really distant future, I guess.
>
> Not _that_ impossible though.  Peter Crosthwaite had some initial
> patches for multi-arch support.

People have been making noises at me about wanting at least the
initial "both an A profile and an M profile Arm core in one board"
support, so it's possible that might float up to the top of my
todo list at some point. (No promises!)

thanks
-- PMM

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

[Daniel P. Berrangé]

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 <thuth@redhat.com> wrote:
> >> 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.

I'm curious what is the compelling benefit of having a single fat QEMU
binary that included all archiectures at once ?

>From a security POV I find it desirable for us to go in the other direction
away from monolithic binaries that include everything. We've started that
work with turning various pieces of QEMU into loadable modules. In the future
we might see some pieces being moved into completely separate binaries. eg we
could have a core QEMU binary and separate binaries for GTK, SPICE, VNC, etc
frontends.

If each target architecture could be a loadable module, it might be
acceptable, but I wouldn't much like the idea of having every architecture
compiled into a single binary. Distros like to build every QEMU feature,
but users reasonably don't want to expand their attack surface by having
all features installed, so being able to install packages for each target
arch separately is a compelling benefit of current set of QEMU per-target
binaries that I wouldn't want to loose.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Peter Maydell]

On 2 May 2018 at 12:58, Daniel P. Berrangé <berrange@redhat.com> 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". One binary seems the most
sensible way to do that, since otherwise we'd end up with some
huge multiplication of binaries for all the possible architecture
combinations. It also would reduce the number of times we end up
recompiling and shipping any particular PCI device. From the
perspective of QEMU as emulation environment, it's a nice
simplification.

> From a security POV I find it desirable for us to go in the other direction
> away from monolithic binaries that include everything. We've started that
> work with turning various pieces of QEMU into loadable modules. In the future
> we might see some pieces being moved into completely separate binaries. eg we
> could have a core QEMU binary and separate binaries for GTK, SPICE, VNC, etc
> frontends.
>
> If each target architecture could be a loadable module, it might be
> acceptable, but I wouldn't much like the idea of having every architecture
> compiled into a single binary. Distros like to build every QEMU feature,
> but users reasonably don't want to expand their attack surface by having
> all features installed, so being able to install packages for each target
> arch separately is a compelling benefit of current set of QEMU per-target
> binaries that I wouldn't want to loose.

Well, we already have issues with that where for instance
qemu-system-aarch64 has a lot of device models that the
typical KVM VM doesn't need. More modularity might help
(though we have shied away from having devices be modules
in the past).

thanks
-- PMM

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

[Daniel P. Berrangé]

On Wed, May 02, 2018 at 01:05:21PM +0100, Peter Maydell wrote:
> On 2 May 2018 at 12:58, Daniel P. Berrangé <berrange@redhat.com> 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". One binary seems the most
> sensible way to do that, since otherwise we'd end up with some
> huge multiplication of binaries for all the possible architecture
> combinations. It also would reduce the number of times we end up
> recompiling and shipping any particular PCI device. From the
> perspective of QEMU as emulation environment, it's a nice
> simplification.

Ah that's interesting - should have known there was wierd hardware
like that out there :-)   So from that POV, it would be good to
try to aim for making the CPU emulation loadable modules to avoid
degrading our current level of modularization.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Thomas Huth]

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é <berrange@redhat.com> 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". One binary seems the most
>> sensible way to do that, since otherwise we'd end up with some
>> huge multiplication of binaries for all the possible architecture
>> combinations. It also would reduce the number of times we end up
>> recompiling and shipping any particular PCI device. From the
>> perspective of QEMU as emulation environment, it's a nice
>> simplification.
> 
> Ah that's interesting - should have known there was wierd hardware
> like that out there :-)

It's not that weird. A lot of "normal" machines have a service processor
(aka. BMC - board management controller) on board - and this service
processor is completely different to the main CPU. For example, the main
CPU could be an x86 or PPC, and the service processor is an embedded ARM
chip. To emulate a complete board, you'd need both CPU types in one QEMU
binary. Or you need to come up with some fancy interface between two
QEMU instances...

 Thomas

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

[Daniel P. Berrangé]

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é <berrange@redhat.com> 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". One binary seems the most
> >> sensible way to do that, since otherwise we'd end up with some
> >> huge multiplication of binaries for all the possible architecture
> >> combinations. It also would reduce the number of times we end up
> >> recompiling and shipping any particular PCI device. From the
> >> perspective of QEMU as emulation environment, it's a nice
> >> simplification.
> > 
> > Ah that's interesting - should have known there was wierd hardware
> > like that out there :-)
> 
> It's not that weird. A lot of "normal" machines have a service processor
> (aka. BMC - board management controller) on board - and this service
> processor is completely different to the main CPU. For example, the main
> CPU could be an x86 or PPC, and the service processor is an embedded ARM
> chip. To emulate a complete board, you'd need both CPU types in one QEMU
> binary. Or you need to come up with some fancy interface between two
> QEMU instances...

Hmm, yes, even Intel x86_64 boards these days all have the management engine
running an old 486 derived CPU. Perhaps one day we'll emulate a new x86
machine type with a ME :-)

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Cédric Le Goater]

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é <berrange@redhat.com> 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". One binary seems the most
>>>> sensible way to do that, since otherwise we'd end up with some
>>>> huge multiplication of binaries for all the possible architecture
>>>> combinations. It also would reduce the number of times we end up
>>>> recompiling and shipping any particular PCI device. From the
>>>> perspective of QEMU as emulation environment, it's a nice
>>>> simplification.
>>>
>>> Ah that's interesting - should have known there was wierd hardware
>>> like that out there :-)
>>
>> It's not that weird. A lot of "normal" machines have a service processor
>> (aka. BMC - board management controller) on board - and this service
>> processor is completely different to the main CPU. For example, the main
>> CPU could be an x86 or PPC, and the service processor is an embedded ARM
>> chip. To emulate a complete board, you'd need both CPU types in one QEMU
>> binary. Or you need to come up with some fancy interface between two
>> QEMU instances...
> 
> Hmm, yes, even Intel x86_64 boards these days all have the management engine
> running an old 486 derived CPU. Perhaps one day we'll emulate a new x86
> machine type with a ME :-)

There are quite a few Intel boards with an Aspeed (ARM) BMC.

C.

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

[Cédric Le Goater]

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é <berrange@redhat.com> 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". One binary seems the most
>>> sensible way to do that, since otherwise we'd end up with some
>>> huge multiplication of binaries for all the possible architecture
>>> combinations. It also would reduce the number of times we end up
>>> recompiling and shipping any particular PCI device. From the
>>> perspective of QEMU as emulation environment, it's a nice
>>> simplification.
>>
>> Ah that's interesting - should have known there was wierd hardware
>> like that out there :-)
> 
> It's not that weird. A lot of "normal" machines have a service processor
> (aka. BMC - board management controller) on board - and this service
> processor is completely different to the main CPU. For example, the main
> CPU could be an x86 or PPC, and the service processor is an embedded ARM
> chip. To emulate a complete board, you'd need both CPU types in one QEMU
> binary. Or you need to come up with some fancy interface between two
> QEMU instances...

like a QEMU chardev backend to implement an IPMI BT interface between 
a QEMU Aspeed SoC machine and a QEMU PowerNV machine ? It works :) But,
you need real HW to find timing issues ...

They are plenty of other "wires" to fully model an OpenPower system, 
LPC, MBOX, etc. The dialogues between the ppc64 host firmware and 
the BMC firmware are very diverse. 

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 execution in some ways and find timing issues.


C.

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 2497 bytes --]

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 execution in some ways and find timing issues.

Yes, there is demand for heterogenous guests.  People have worked on
this problem in the past but nothing mergeable came out of it.

The main issue with a monolithic binary is that today, QEMU builds
target-specific object files (see Makefile.target).  That means the same
C source file is recompiled for each target with different #defines.  We
cannot easily link these "duplicate" object files into a single binary
because the symbol names would collide.

It would be necessary to refactor target-specific #ifdefs.  Here is a
trivial example from arch_init.c:

  #ifdef TARGET_SPARC
  int graphic_width = 1024;
  int graphic_height = 768;
  int graphic_depth = 8;
  #else
  int graphic_width = 800;
  int graphic_height = 600;
  int graphic_depth = 32;
  #endif

This can be converted into a runtime check:

  static void init_graphic_resolution(void)
  {
      if (arch_type == QEMU_ARCH_SPARC) {
          graphic_width = 1024;
          graphic_height = 768;
          graphic_depth = 8;
      } else {
          graphic_width = 800;
          graphic_height = 600;
          graphic_depth = 32;
      }
  }
  target_init(init_graphic_resolution)

I'm assuming target_init() registers functions that will be called once
arch_type has been set.

Of course the meaning of arch_type in a heterogenous system is different
since there can be multiple CPUs.  It would mean the overall board (e.g.
a SPARC machine).  But that is a separate issue and can only be
addressed once target-specific files have been eliminated.

I also want to point out that a monolithic binary is totally orthogonal
to modularity (reducing attack surface, reducing dependencies).  These
two issues do not conflict with each other.  We could have a single
"qemu-softmmu" binary that dynamically loads needed machine types, CPU,
and emulated devices.  That way the monolithic binary can do everything
but is still minimal.

So to clarify, three separate steps:

1. Get rid of target-specific #ifdefs
2a. Modular QEMU, single binary
2b. Heterogenous QEMU

2a and 2b are independent but both depend on 1.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

[Dr. David Alan Gilbert]

* Stefan Hajnoczi (stefanha@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 model a platform, specially if we can 
> > synchronize the execution in some ways and find timing issues.
> 
> Yes, there is demand for heterogenous guests.  People have worked on
> this problem in the past but nothing mergeable came out of it.
> 
> The main issue with a monolithic binary is that today, QEMU builds
> target-specific object files (see Makefile.target).  That means the same
> C source file is recompiled for each target with different #defines.  We
> cannot easily link these "duplicate" object files into a single binary
> because the symbol names would collide.
> 
> It would be necessary to refactor target-specific #ifdefs.  Here is a
> trivial example from arch_init.c:
> 
>   #ifdef TARGET_SPARC
>   int graphic_width = 1024;
>   int graphic_height = 768;
>   int graphic_depth = 8;
>   #else
>   int graphic_width = 800;
>   int graphic_height = 600;
>   int graphic_depth = 32;
>   #endif
> 
> This can be converted into a runtime check:
> 
>   static void init_graphic_resolution(void)
>   {
>       if (arch_type == QEMU_ARCH_SPARC) {
>           graphic_width = 1024;
>           graphic_height = 768;
>           graphic_depth = 8;
>       } else {
>           graphic_width = 800;
>           graphic_height = 600;
>           graphic_depth = 32;
>       }
>   }
>   target_init(init_graphic_resolution)
> 
> I'm assuming target_init() registers functions that will be called once
> arch_type has been set.
> 
> Of course the meaning of arch_type in a heterogenous system is different
> since there can be multiple CPUs.  It would mean the overall board (e.g.
> a SPARC machine).  But that is a separate issue and can only be
> addressed once target-specific files have been eliminated.
> 
> I also want to point out that a monolithic binary is totally orthogonal
> to modularity (reducing attack surface, reducing dependencies).  These
> two issues do not conflict with each other.  We could have a single
> "qemu-softmmu" binary that dynamically loads needed machine types, CPU,
> and emulated devices.  That way the monolithic binary can do everything
> but is still minimal.
> 
> So to clarify, three separate steps:
> 
> 1. Get rid of target-specific #ifdefs
> 2a. Modular QEMU, single binary
> 2b. Heterogenous QEMU
> 
> 2a and 2b are independent but both depend on 1.

(1) may not be required, if those ifdef's are in target-specific
builds; but that does require that any target-specific stuff goes
through a well defined interface to be a loadable module and not
have a zillion overlapping symbols.

Making it loadable modules feels nice.

Dave

> Stefan


--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 3962 bytes --]

On Thu, May 03, 2018 at 07:50:41PM +0100, Dr. David Alan Gilbert wrote:
> * Stefan Hajnoczi (stefanha@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 model a platform, specially if we can 
> > > synchronize the execution in some ways and find timing issues.
> > 
> > Yes, there is demand for heterogenous guests.  People have worked on
> > this problem in the past but nothing mergeable came out of it.
> > 
> > The main issue with a monolithic binary is that today, QEMU builds
> > target-specific object files (see Makefile.target).  That means the same
> > C source file is recompiled for each target with different #defines.  We
> > cannot easily link these "duplicate" object files into a single binary
> > because the symbol names would collide.
> > 
> > It would be necessary to refactor target-specific #ifdefs.  Here is a
> > trivial example from arch_init.c:
> > 
> >   #ifdef TARGET_SPARC
> >   int graphic_width = 1024;
> >   int graphic_height = 768;
> >   int graphic_depth = 8;
> >   #else
> >   int graphic_width = 800;
> >   int graphic_height = 600;
> >   int graphic_depth = 32;
> >   #endif
> > 
> > This can be converted into a runtime check:
> > 
> >   static void init_graphic_resolution(void)
> >   {
> >       if (arch_type == QEMU_ARCH_SPARC) {
> >           graphic_width = 1024;
> >           graphic_height = 768;
> >           graphic_depth = 8;
> >       } else {
> >           graphic_width = 800;
> >           graphic_height = 600;
> >           graphic_depth = 32;
> >       }
> >   }
> >   target_init(init_graphic_resolution)
> > 
> > I'm assuming target_init() registers functions that will be called once
> > arch_type has been set.
> > 
> > Of course the meaning of arch_type in a heterogenous system is different
> > since there can be multiple CPUs.  It would mean the overall board (e.g.
> > a SPARC machine).  But that is a separate issue and can only be
> > addressed once target-specific files have been eliminated.
> > 
> > I also want to point out that a monolithic binary is totally orthogonal
> > to modularity (reducing attack surface, reducing dependencies).  These
> > two issues do not conflict with each other.  We could have a single
> > "qemu-softmmu" binary that dynamically loads needed machine types, CPU,
> > and emulated devices.  That way the monolithic binary can do everything
> > but is still minimal.
> > 
> > So to clarify, three separate steps:
> > 
> > 1. Get rid of target-specific #ifdefs
> > 2a. Modular QEMU, single binary
> > 2b. Heterogenous QEMU
> > 
> > 2a and 2b are independent but both depend on 1.
> 
> (1) may not be required, if those ifdef's are in target-specific
> builds; but that does require that any target-specific stuff goes
> through a well defined interface to be a loadable module and not
> have a zillion overlapping symbols.

Right, there are many cases that I omitted and the arch_init.c example
was the simplest case.  Each instance needs to be handled on a
case-by-case basis.

We may need to keep multiple copies of object code.  Byteswapping is an
example of this:

  #if defined(HOST_WORDS_BIGENDIAN) != defined(TARGET_WORDS_BIGENDIAN)
  #define BSWAP_NEEDED
  #endif

Adding runtime endianness checks to all guest memory accesses could
impact performance.  This is why everything that includes cpu.h is
currently per-target.

This work is no small task but I think it's necessary.  The starting
point for anyone who'd like to contribute:

Look at obj-y files in the makefiles.  These are the target-specific
object files that need to be investigated.  Everything already in
common-obj-y is only built once and can be ignored.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

[Markus Armbruster]

Stefan Hajnoczi <stefanha@redhat.com> 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 both depend on 1.

1. can be incremental.  Something for
<https://wiki.qemu.org/Contribute/BiteSizedTasks>?

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

On Fri, May 04, 2018 at 07:29:20AM +0200, Markus Armbruster wrote:
> Stefan Hajnoczi <stefanha@redhat.com> writes:
> > So to clarify, three separate steps:
> >
> > 1. Get rid of target-specific #ifdefs
> 
> 1. can be incremental.  Something for
> <https://wiki.qemu.org/Contribute/BiteSizedTasks>?

Some conversions are trivial, others are not.  I think asking newcomers
to figure out how to untangle the #ifdefs without a plan would not
produce good results.

Someone experienced should lay the groundwork and identify common types
of conversions.  Then bite-sized tasks can be defined for trivial
conversions.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

[Peter Maydell]

On 4 May 2018 at 09:16, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> On Fri, May 04, 2018 at 07:29:20AM +0200, Markus Armbruster wrote:
>> Stefan Hajnoczi <stefanha@redhat.com> writes:
>> > So to clarify, three separate steps:
>> >
>> > 1. Get rid of target-specific #ifdefs
>>
>> 1. can be incremental.  Something for
>> <https://wiki.qemu.org/Contribute/BiteSizedTasks>?
>
> Some conversions are trivial, others are not.  I think asking newcomers
> to figure out how to untangle the #ifdefs without a plan would not
> produce good results.

Yes; we have a bad track record of putting "general unfinished
conversions" into the bite-sized-tasks list and then finding
that new contributors try to tackle things that are more
subtle than the brief description makes them seem (especially
since often the unfinished parts of a conversion are the hard
parts!)

thanks
-- PMM

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

[Michal Suchánek]

On Fri, 27 Apr 2018 17:24:38 +0100
Peter Maydell <peter.maydell@linaro.org> wrote:

> On 27 April 2018 at 17:17, Thomas Huth <thuth@redhat.com> 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...

At least the PPC vs PPC64 default to different BIOS, machine type, etc.

That could be achieved by a wrapper script around the 64bit binary I
suppose.

Is there any reason why the 64bit emulator would not run on 32bit
system? The emulated 64bit system is .. emulated after all.

Thanks

Michal

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

[Richard Henderson]

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 64-bit guest is really a
32-bit guest in disguise, this carries a performance penalty.

If we ever stop caring about 32-bit hosts, the question becomes moot.


r~

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

[Laszlo Ersek]

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 double-word
> arithmetic to emulate the 64-bit guest.  When the 64-bit guest is really a
> 32-bit guest in disguise, this carries a performance penalty.
> 
> If we ever stop caring about 32-bit hosts, the question becomes moot.

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 my understanding, all of those have to be expressed with
host virtual addresses in the QEMU process (regardless of TCG vs. KVM).
But on a 32-bit host, the QEMU process only has 4GB HVA space.

Thanks
Laszlo

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

[Peter Maydell]

On 2 May 2018 at 11:41, Laszlo Ersek <lersek@redhat.com> 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 my understanding, all of those have to be expressed with
> host virtual addresses in the QEMU process (regardless of TCG vs. KVM).
> But on a 32-bit host, the QEMU process only has 4GB HVA space.

I think the situation there would be unchanged -- on a 32 bit
host the ramaddr type is 32 bits (unless Xen is configured into
the binary!) regardless of the guest architecture size, and the
limit on RAM size is 2GB, and the hwaddr is 64 bits regardless
of guest architecture size. That wouldn't change whether we had
a single executable or split ones for 32 and 64 bit targets.
You can have more than 4GB of guest physical address space
(we don't map that into the host address space), but there's
a 2GB RAM limit (because we do map all the RAM blocks); these
limits currently apply equally to qemu-system-i386 and
qemu-system_x86-64.

thanks
-- PMM

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

[Michal Suchánek]

On Sun, 29 Apr 2018 09:56:37 -0500
Richard Henderson <richard.henderson@linaro.org> 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 double-word
> arithmetic to emulate the 64-bit guest.  When the 64-bit guest is
> really a 32-bit guest in disguise, this carries a performance penalty.
> 
> If we ever stop caring about 32-bit hosts, the question becomes moot.
> 

So if I installed 32bit pc binaries and 32bit qemu instead of the
x86_64 binaries on my ARM board it would be faster. Good to know if I
ever try wacky experiments like that again ;-)

Thanks

Michal

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

[Daniel P. Berrangé]

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 <peter.maydell@linaro.org> wrote:
> 
> > On 27 April 2018 at 17:17, Thomas Huth <thuth@redhat.com> 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...
> 
> At least the PPC vs PPC64 default to different BIOS, machine type, etc.
> 
> That could be achieved by a wrapper script around the 64bit binary I
> suppose.
> 
> Is there any reason why the 64bit emulator would not run on 32bit
> system? The emulated 64bit system is .. emulated after all.

I'm assuming thuat a qemu-system-x86_64  binary cannot use KVM to run
on a 32-bit host kernel, even if it was only running a 32-bit guest ?

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Markus Armbruster]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 27 April 2018 at 17:17, Thomas Huth <thuth@redhat.com> 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...

Nothing and nobody but ourselves can prevent us from breaking backward
compatibility.

We *choose* to sacrifice the poor chickens to the idol of backward
compatibility.  We *choose* to sacrifice to the idol whatever time and
effort it demands[*].  We *choose* to let the idol smother other
endeavors.

See also slide 35 "Must it be?" of
https://www.linux-kvm.org/images/f/f2/Armbru-qapi-cmdline_1.pdf

Breaking backward compatibility without good reasons is stupid.
Maintaining it at all costs is just as stupid.  There's no non-stupid
way around facing the tradeoffs and making choices.

Our adoption of a deprecation policy has enabled us to make sensible
choices in cases where providing old and new interface at the same time
is inexpensive: we keep the old one around until the deprecation grace
period expires.

What if we run into cases where that isn't practical?

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 doesn't
help one bit, it still wants us to replicate every mess we ever made in
the old command line.  Would that be a smart choice?

Even with a deprecation policy in place, there's still no non-stupid way
around facing the tradeoffs and making choices.

[...]


[*] Curiously, the idol doesn't seem to demand effort to test backward
compatibility.  The idol seems to be fine with us breaking it
accidentally, only doing it knowingly incurs its wrath.

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

[Daniel P. Berrangé]

On Wed, May 02, 2018 at 09:29:39AM +0200, Markus Armbruster wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
> 
> > On 27 April 2018 at 17:17, Thomas Huth <thuth@redhat.com> 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...
> 
> Nothing and nobody but ourselves can prevent us from breaking backward
> compatibility.
> 
> We *choose* to sacrifice the poor chickens to the idol of backward
> compatibility.  We *choose* to sacrifice to the idol whatever time and
> effort it demands[*].  We *choose* to let the idol smother other
> endeavors.
> 
> See also slide 35 "Must it be?" of
> https://www.linux-kvm.org/images/f/f2/Armbru-qapi-cmdline_1.pdf
> 
> Breaking backward compatibility without good reasons is stupid.
> Maintaining it at all costs is just as stupid.  There's no non-stupid
> way around facing the tradeoffs and making choices.
> 
> Our adoption of a deprecation policy has enabled us to make sensible
> choices in cases where providing old and new interface at the same time
> is inexpensive: we keep the old one around until the deprecation grace
> period expires.
> 
> What if we run into cases where that isn't practical?

Check the deprecation policy wording again :-)  All it says is that we
intend to give users 2 releases warning prior to making an incompatible
change.

Now, we've tried to nice and always provide the replacement functionality
at the same time that we introduce the deprecation warning, so there is a
period of overlap to let apps adapt, but we never actually documented that
as a hard requirement. That is perhaps an oversight when I wrote the
deprecation docs, but it does leave us wiggle room on how to intepret
what we need todo here.

  https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features

> 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 doesn't
> help one bit, it still wants us to replicate every mess we ever made in
> the old command line.  Would that be a smart choice?

I venture to suggest that the deprecation policy leaves us enough
ambiguity that we could issue a deprecation warning saying something
suitably vague like "various quirks of the cli may change in incompatible
ways in future", and then just do a big-bang conversion to QAPI'ified
version. If there are known quirks that we intend to break we could
call them out, but if we accidentally change a few quirks without
realizing it, so be it.

IOW, the big-bang conversion to QAPIified CLI is possible with our
deprecation policy, without having the maintain the existing code
in parallel with bug-for-bug compat. The main constraint is that
we would need to have a reasonable idea about when the QAPIified
CLI is likely to be ready to merge, so we have ability to warn
developers of forthcoming changes.

> [*] Curiously, the idol doesn't seem to demand effort to test backward
> compatibility.  The idol seems to be fine with us breaking it
> accidentally, only doing it knowingly incurs its wrath.

Testing is something we should have for everything we do, but no amount
of testing is ever going to have perfect coverage unless we spend x5
the dev time on testing, as in writing the feature. We just have to be
sensible about how we invest time in different areas to maximise benefit
for the user. We also have to accept the reality of our current codebase
which has very patchy test coverage - mandating everyone do something when
they'd be starting from (near) zero is not likely to yield happy devs.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Cornelia Huck]

On Wed, 2 May 2018 09:16:32 +0100
Daniel P. Berrangé <berrange@redhat.com> 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 doesn't
> > help one bit, it still wants us to replicate every mess we ever made in
> > the old command line.  Would that be a smart choice?  
> 
> I venture to suggest that the deprecation policy leaves us enough
> ambiguity that we could issue a deprecation warning saying something
> suitably vague like "various quirks of the cli may change in incompatible
> ways in future", and then just do a big-bang conversion to QAPI'ified
> version. If there are known quirks that we intend to break we could
> call them out, but if we accidentally change a few quirks without
> realizing it, so be it.
> 
> IOW, the big-bang conversion to QAPIified CLI is possible with our
> deprecation policy, without having the maintain the existing code
> in parallel with bug-for-bug compat. The main constraint is that
> we would need to have a reasonable idea about when the QAPIified
> CLI is likely to be ready to merge, so we have ability to warn
> developers of forthcoming changes.

I agree, that should be workable with our current deprecation policy.

[If it is at all feasible, we should also warn explicitly if a
known-quirky option is used, but the general warning should be enough,
especially if we feature it prominently in QEMU release notes as well.]

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

[Cornelia Huck]

On Fri, 27 Apr 2018 16:51:03 +0100
Peter Maydell <peter.maydell@linaro.org> 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

* avoiding that this discussion comes up every release :)

> but maybe we should anyway?

v3.0 sounds fine to me.

> 
> (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 definitely done by the middle of August, to avoid a clash
>    with a personal commitment
>  * so probably hardfreeze 10th July, softfreeze 3rd July

August might be more of a vacation month than July, anyway? (Depending
on where you live, I guess.)

No objection from me.

> 
> (3) retrospective, lessons learned &c
>  * please remember that if every single submaintainer submits
>    a pull request on the morning of an RC, it is physically
>    not possible for me to process all those pulls in time to
>    tag the RC that day. We had several RCs which got delayed
>    by a day because of this; please try to submit earlier
>    rather than later...

There seemed to have been several 'oh crap' issues that people wanted
to get in asap, so that might account for it.

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?

>  * provide your opinions here ?
> 
> thanks
> -- PMM
> 

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

[Peter Maydell]

On 30 April 2018 at 10:29, Cornelia Huck <cohuck@redhat.com> 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?

Generally my preference is for more smaller requests:
 * it means that patches from contributors get into master faster
 * the bigger the pull request the more likely that something in it
   will fail a build test and result in a delay for the whole lot

My rule of thumb for target-arm pull requests is to send one
if my queue gets up to 10 or so patches or if it's been two weeks
since the last one, I think. (I'm not saying 2 weeks is a limit
on how often to send -- it's just about where my personal
tradeoff between how long I hold onto things and how frequently
I want to do the test-and-send-pullreq work is set.)

thanks
-- PMM

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

[Daniel P. Berrangé]

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 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
> but maybe we should anyway?

I'm in favour of changnig the major version to 3.0, but when we do
so we should also define a clear rule we can follow for major version
bumps, so we don't have the same silly debate for how we pick 4.0,
5.0 etc.

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 soon as you try to assign special meaning to major
version changes, you open the door to endless debate about whether
a particular set of changes is meaningful enough to justify the
major version change, leading to eventually 2.42. 

Two possible options

 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 release when minor version gets double-digits.
    eg 3.0, 3.1, ...., 3.9, 3.9, 4.0, ...., 4.9, 5.0...

Personally I'd go for (a). If we do this, it doesn't preclude
us from just happening to do some releases that are backwards
incompatible. Our deprecation policy has provided us a way to
have a backwards incompatible change in ANY release we make.
We just have to ensure people are forewarned of what's coming.

If it was an incredibly large & disruptive incompatible change,
we might none the less choose to align its arrival with a major
version bump. That's ok. We simply do not require that a major
version change has to have a major incompatibility.

> (3) retrospective, lessons learned &c
>  * please remember that if every single submaintainer submits
>    a pull request on the morning of an RC, it is physically
>    not possible for me to process all those pulls in time to
>    tag the RC that day. We had several RCs which got delayed
>    by a day because of this; please try to submit earlier
>    rather than later...
>  * provide your opinions here ?

It is moderately rare that we have a huge new subsystem like RiscV
enter tree during a release cycle. Given our experiance of this
though, it is clear that when such new subsystems arrive, we need
one or more existing maintainers to mentor the submitter wrt QEMU
processes. We saw that is is unreasonable to expect a new comer
to QEMU development to figure it all out for themselves, and Peter
doesn't have the time to do this mentoring while also dealing with
existing merge workload.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Cornelia Huck]

On Mon, 30 Apr 2018 11:33:12 +0100
Daniel P. Berrangé <berrange@redhat.com> 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 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
> > but maybe we should anyway?  
> 
> I'm in favour of changnig the major version to 3.0, but when we do
> so we should also define a clear rule we can follow for major version
> bumps, so we don't have the same silly debate for how we pick 4.0,
> 5.0 etc.
> 
> 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 soon as you try to assign special meaning to major
> version changes, you open the door to endless debate about whether
> a particular set of changes is meaningful enough to justify the
> major version change, leading to eventually 2.42. 

I agree.

> 
> Two possible options
> 
>  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 release when minor version gets double-digits.
>     eg 3.0, 3.1, ...., 3.9, 3.9, 4.0, ...., 4.9, 5.0...
> 
> Personally I'd go for (a). If we do this, it doesn't preclude
> us from just happening to do some releases that are backwards
> incompatible. Our deprecation policy has provided us a way to
> have a backwards incompatible change in ANY release we make.
> We just have to ensure people are forewarned of what's coming.

If we bump the major version each year anyway, why not go the whole way
and use 2018.1, 2018.2, ... (or even <year>.<month>)? The nice thing
about that is that you can see at a glance when the release took place.
The drawback is that stable updates might look a bit awkward, but I
don't think that's too bad, as we don't do multiple stable branches.

> 
> If it was an incredibly large & disruptive incompatible change,
> we might none the less choose to align its arrival with a major
> version bump. That's ok. We simply do not require that a major
> version change has to have a major incompatibility.

I'm not really in favour of that. "The major version means nothing
special, except when it does"? Also, cue the "is this change disruptive
enough?" discussions :)

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

[Thomas Huth]

On 30.04.2018 13:21, Cornelia Huck wrote:
> On Mon, 30 Apr 2018 11:33:12 +0100
> Daniel P. Berrangé <berrange@redhat.com> 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 soon as you try to assign special meaning to major
>> version changes, you open the door to endless debate about whether
>> a particular set of changes is meaningful enough to justify the
>> major version change, leading to eventually 2.42. 
> 
> I agree.

I agree with this, too. We've seen that in some v3.0 discussions during
the last year.

>> Two possible options
>>
>>  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 release when minor version gets double-digits.
>>     eg 3.0, 3.1, ...., 3.9, 3.9, 4.0, ...., 4.9, 5.0...

It's just a matter of taste, but I think I'd prefer variant b). That
will bump the major release approx. every three years which sounds like
a good time frame for me.

> If we bump the major version each year anyway, why not go the whole way
> and use 2018.1, 2018.2, ... (or even <year>.<month>)? 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, ...?

 Thomas

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

[Cornelia Huck]

On Mon, 30 Apr 2018 19:36:40 +0200
Thomas Huth <thuth@redhat.com> wrote:

> On 30.04.2018 13:21, Cornelia Huck wrote:
> > On Mon, 30 Apr 2018 11:33:12 +0100
> > Daniel P. Berrangé <berrange@redhat.com> 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 soon as you try to assign special meaning to major
> >> version changes, you open the door to endless debate about whether
> >> a particular set of changes is meaningful enough to justify the
> >> major version change, leading to eventually 2.42.   
> > 
> > I agree.  
> 
> I agree with this, too. We've seen that in some v3.0 discussions during
> the last year.
> 
> >> Two possible options
> >>
> >>  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 release when minor version gets double-digits.
> >>     eg 3.0, 3.1, ...., 3.9, 3.9, 4.0, ...., 4.9, 5.0...  
> 
> It's just a matter of taste, but I think I'd prefer variant b). That
> will bump the major release approx. every three years which sounds like
> a good time frame for me.

I think anything that keeps release numbers in ascending order would
basically work :)

> 
> > If we bump the major version each year anyway, why not go the whole way
> > and use 2018.1, 2018.2, ... (or even <year>.<month>)? 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, ...?

Uh, and what happens in the next century?

:)

So many options, and all make some sense... I predict we stay with the
same numbering as before :)

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

[Liviu Ionescu]

On 2 May 2018 at 10:38:09, Cornelia Huck (cohuck@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 release when minor version gets double-digits.
> > >> eg 3.0, 3.1, ...., 3.9, 3.9, 4.0, ...., 4.9, 5.0...
> >
> > It's just a matter of taste, but I think I'd prefer variant b).
> That
> > will bump the major release approx. every three years which
> sounds like
> > a good time frame for me.
>
> I think anything that keeps release numbers in ascending order
> would
> basically work :)

not really.

I suggest you use semantic versioning:

https://semver.org


regards,

Liviu

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

[Daniel P. Berrangé]

On Wed, May 02, 2018 at 12:43:10AM -0700, Liviu Ionescu wrote:
> On 2 May 2018 at 10:38:09, Cornelia Huck (cohuck@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 release when minor version gets double-digits.
> > > >> eg 3.0, 3.1, ...., 3.9, 3.9, 4.0, ...., 4.9, 5.0...
> > >
> > > It's just a matter of taste, but I think I'd prefer variant b).
> > That
> > > will bump the major release approx. every three years which
> > sounds like
> > > a good time frame for me.
> >
> > I think anything that keeps release numbers in ascending order
> > would
> > basically work :)
> 
> not really.
> 
> I suggest you use semantic versioning:
> 
> https://semver.org

No, not semver. It is not a good match for the way QEMU is handling
incompatible changes. Our deprecation policy lets us include incompatible
changes in *any* release. So with semver that would force a major version
bump on every release which is madness.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Liviu Ionescu]

On 2 May 2018 at 10:59:07, Daniel P. Berrangé (berrange@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

[Thomas Huth]

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

https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features

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.

 Thomas

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

[Liviu Ionescu]

On 2 May 2018 at 11:13:49, Thomas Huth (thuth@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 point.

thinking twice, I'm not sure it is a real sacrifice; I think that the
problem here is the strict definition:

"The feature will remain functional for 2 releases prior to actual removal."

if it were:

"The feature will remain functional for _at least_ 2 releases prior to
actual removal. "

or even better:

"The feature will remain functional for _at least_ 2 _major_ releases
prior to actual removal. "


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 example, minor
releases every 3-6 months, and patch releases when needed.


from a use perspective, I don't think that updating the deprecation
policy would be objected, so that would not be perceived as a
sacrifice; on the contrary, such a mechanism would allow both a
faster/flexible release cycle, and give the users a more educated
guess when it is time to upgrade; both beneficial.

for the developers/maintainers... I agree that it would require some
more discipline and responsibility.

not to mention that even before semver, in most versioning schemes it
was somehow expected that while the first version number remains the
same, compatibility is more or less preserved.


regards,

Liviu

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

[Daniel P. Berrangé]

On Wed, May 02, 2018 at 02:03:14AM -0700, Liviu Ionescu wrote:
> On 2 May 2018 at 11:13:49, Thomas Huth (thuth@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 point.
> 
> thinking twice, I'm not sure it is a real sacrifice; I think that the
> problem here is the strict definition:
> 
> "The feature will remain functional for 2 releases prior to actual removal."
> 
> if it were:
> 
> "The feature will remain functional for _at least_ 2 releases prior to
> actual removal. "
> 
> or even better:
> 
> "The feature will remain functional for _at least_ 2 _major_ releases
> prior to actual removal. "
> 
> 
> 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 example, minor
> releases every 3-6 months, and patch releases when needed.

No, we do not want to extend the deprecation period further just so that
we can adopt semver.  We explicitly chose "2 releases", so that every
deprecation warning has the same lifetime - we don't want some deprecations
to be 4 months long, while other deprecation warnings are 1+1/2 years long.

> from a use perspective, I don't think that updating the deprecation
> policy would be objected, so that would not be perceived as a
> sacrifice; on the contrary, such a mechanism would allow both a
> faster/flexible release cycle, and give the users a more educated
> guess when it is time to upgrade; both beneficial.
> 
> for the developers/maintainers... I agree that it would require some
> more discipline and responsibility.
> 
> not to mention that even before semver, in most versioning schemes it
> was somehow expected that while the first version number remains the
> same, compatibility is more or less preserved.

Plenty of software has versioning schemes that are nothing like semver.
Any assumption that first version number changes mean incompatibilty is
a false one, unless the project has explicitly declared that to be the
case.  Calender based versioning is very widely used.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Paolo Bonzini]

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 example, minor
>> releases every 3-6 months, and patch releases when needed.
> No, we do not want to extend the deprecation period further just so that
> we can adopt semver.  We explicitly chose "2 releases", so that every
> deprecation warning has the same lifetime - we don't want some deprecations
> to be 4 months long, while other deprecation warnings are 1+1/2 years long.

In practice it's already "at least" 2 releases, if only because
sometimes 1) people forget, or 2) they are busy with more important
things, or 3) we want to provide a good replacement and it turns out to
be harder than 2 releases.

Paolo

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

[Cornelia Huck]

On Wed, 2 May 2018 02:03:14 -0700
Liviu Ionescu <ilg@livius.net> wrote:

> On 2 May 2018 at 11:13:49, Thomas Huth (thuth@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 point.
> 
> thinking twice, I'm not sure it is a real sacrifice; I think that the
> problem here is the strict definition:
> 
> "The feature will remain functional for 2 releases prior to actual removal."
> 
> if it were:
> 
> "The feature will remain functional for _at least_ 2 releases prior to
> actual removal. "
> 
> or even better:
> 
> "The feature will remain functional for _at least_ 2 _major_ releases
> prior to actual removal. "
> 
> 
> 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.

Ugh, no. That would mean we have to drag around ill-conceived
interfaces for way too long.

> 
> major releases can be scheduled every 1-2 years, for example, minor
> releases every 3-6 months, and patch releases when needed.
> 
> 
> from a use perspective, I don't think that updating the deprecation
> policy would be objected, so that would not be perceived as a
> sacrifice; on the contrary, such a mechanism would allow both a
> faster/flexible release cycle, and give the users a more educated
> guess when it is time to upgrade; both beneficial.

How on earth is that supposed to speed things up?

And really, time to upgrade is either "bugs have been fixed", "a
feature I want has been introduced", or "my distro pushed a new
package". Not a magic number.

> 
> for the developers/maintainers... I agree that it would require some
> more discipline and responsibility.

I just don't see any benefits from that.

> 
> not to mention that even before semver, in most versioning schemes it
> was somehow expected that while the first version number remains the
> same, compatibility is more or less preserved.

I don't like semver. For development as it is done in many projects
today, you're just doing incremental updates all the time, probably
with a stable branch on the side. Meaningful version numbers just get
us to stupid discussions about what is a bugfix, what a minor feature,
and what a major feature.

IOW, I think *any* versioning scheme that does not assign
interface/feature expectations to version numbers (beyond "a suffix
means a stable update" or something like that) is what would work for
us.

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

[Thomas Huth]

On 02.05.2018 11:03, Liviu Ionescu wrote:
> On 2 May 2018 at 11:13:49, Thomas Huth (thuth@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 point.
> 
> thinking twice, I'm not sure it is a real sacrifice; I think that the
> problem here is the strict definition:
> 
> "The feature will remain functional for 2 releases prior to actual removal."
> 
> if it were:
> 
> "The feature will remain functional for _at least_ 2 releases prior to
> actual removal. "
> 
> or even better:
> 
> "The feature will remain functional for _at least_ 2 _major_ releases
> prior to actual removal. "

Sorry, but this really does not match with what we discussed last year
(see the thread at
https://lists.gnu.org/archive/html/qemu-devel/2017-03/msg01592.html for
example), so I doubt that we can get a consensus on this for QEMU.

 Thomas

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

[Cornelia Huck]

On Wed, 2 May 2018 01:02:49 -0700
Liviu Ionescu <ilg@livius.net> wrote:

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

See https://wiki.qemu.org/Features/LegacyRemoval, especially "Rules for
removing an interface". An incompatible change is basically a subset of
removing.

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

[Max Reitz]

[-- Attachment #1: Type: text/plain, Size: 1881 bytes --]

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 (cohuck@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 release when minor version gets double-digits.
>>>>>> eg 3.0, 3.1, ...., 3.9, 3.9, 4.0, ...., 4.9, 5.0...
>>>>
>>>> It's just a matter of taste, but I think I'd prefer variant b).
>>> That
>>>> will bump the major release approx. every three years which
>>> sounds like
>>>> a good time frame for me.
>>>
>>> I think anything that keeps release numbers in ascending order
>>> would
>>> basically work :)
>>
>> not really.
>>
>> I suggest you use semantic versioning:
>>
>> https://semver.org
> 
> No, not semver. It is not a good match for the way QEMU is handling
> incompatible changes. Our deprecation policy lets us include incompatible
> changes in *any* release. So with semver that would force a major version
> bump on every release which is madness.

FWIW, I think that just means that our deprecation policy is weird.

As a developer, it's great, of course.  You can break everything, just
put up a heads-up two versions in advance.

But I'm grateful I'm not a direct user of qemu (i.e. without libvirt).
I imagine it to be pretty stressful if I have to check on every (or
every second...) release that qemu doesn't show up new deprecation
notices for something I'm using.

Maybe it would make sense to collect things we want to deprecate and
then have a major release every year where we do that deprecation.  As a
user, I'd much prefer that to the possibility of everything changing all
the time.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Gerd Hoffmann]

  Hi,

> > If we bump the major version each year anyway, why not go the whole way
> > and use 2018.1, 2018.2, ... (or even <year>.<month>)? 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 could also drop the major/minor scheme altogether (as they are
meaningless anyway) and just go for YYMM, i.e. 1808 (for a august
release).

If we go for a time-based numbering scheme:  I'd prefer the year being
part of the version number, for the same reason Thomas mentioned above:
It makes it easy to see when a particular version was released.

cheers,
  Gerd

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

[Daniel P. Berrangé]

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 <year>.<month>)? 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 could also drop the major/minor scheme altogether (as they are
> meaningless anyway) and just go for YYMM, i.e. 1808 (for a august
> release).

I don't much like that - it'll lead to a wierd progression of numbers
where we'll be constantly the rationale re-explaining to people who
want to know why we've jumped from 1808 to 1902 to 1905 etc

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

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 <year>.<month>)? 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 could also drop the major/minor scheme altogether (as they are
> > meaningless anyway) and just go for YYMM, i.e. 1808 (for a august
> > release).
> 
> I don't much like that - it'll lead to a wierd progression of numbers
> where we'll be constantly the rationale re-explaining to people who
> want to know why we've jumped from 1808 to 1902 to 1905 etc

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 convention is YY.MM though, not YYMM.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

[Daniel P. Berrangé]

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 way
> > > > > and use 2018.1, 2018.2, ... (or even <year>.<month>)? 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 could also drop the major/minor scheme altogether (as they are
> > > meaningless anyway) and just go for YYMM, i.e. 1808 (for a august
> > > release).
> > 
> > I don't much like that - it'll lead to a wierd progression of numbers
> > where we'll be constantly the rationale re-explaining to people who
> > want to know why we've jumped from 1808 to 1902 to 1905 etc
> 
> 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 convention is YY.MM though, not YYMM.

It feels like we've got quite a strong backing for time based versioning
amongst people replying here. I'd be happy with YY.MM

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Cornelia Huck]

On Thu, 3 May 2018 10:07:27 +0100
Daniel P. Berrangé <berrange@redhat.com> 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:  
> > > >   Hi,
> > > >   
> > > > > > If we bump the major version each year anyway, why not go the whole way
> > > > > > and use 2018.1, 2018.2, ... (or even <year>.<month>)? 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 could also drop the major/minor scheme altogether (as they are
> > > > meaningless anyway) and just go for YYMM, i.e. 1808 (for a august
> > > > release).  
> > > 
> > > I don't much like that - it'll lead to a wierd progression of numbers
> > > where we'll be constantly the rationale re-explaining to people who
> > > want to know why we've jumped from 1808 to 1902 to 1905 etc  
> > 
> > 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 convention is YY.MM though, not YYMM.  
> 
> It feels like we've got quite a strong backing for time based versioning
> amongst people replying here. I'd be happy with YY.MM

FWIW, both YY.MM and YYYY.MM look fine to me.

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

[Peter Maydell]

On 3 May 2018 at 10:07, Daniel P. Berrangé <berrange@redhat.com> 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 convention is YY.MM though, not YYMM.
>
> It feels like we've got quite a strong backing for time based versioning
> amongst people replying here. I'd be happy with YY.MM

I'm not hugely in favour mostly because I don't much like
changing version numbering formats -- does it really gain
us anything? But I guess it's a bit of a bikeshed-colour question.

thanks
-- PMM

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

[Daniel P. Berrangé]

On Thu, May 03, 2018 at 10:26:40AM +0100, Peter Maydell wrote:
> On 3 May 2018 at 10:07, Daniel P. Berrangé <berrange@redhat.com> 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 convention is YY.MM though, not YYMM.
> >
> > It feels like we've got quite a strong backing for time based versioning
> > amongst people replying here. I'd be happy with YY.MM
> 
> I'm not hugely in favour mostly because I don't much like
> changing version numbering formats -- does it really gain
> us anything? But I guess it's a bit of a bikeshed-colour question.

You mean the change from 3 to 2 digits ?   We would presumably need to
stick a zero on the end of it anyway. eg  18.04.0 indicates 2018, May
initial release. Then 18.04.1 indicates the first stable branch release,
etc.

Or if you mean you don't like the jump from 2.x to 18.x, we could just
follow a time based version scheme, but just bumping major digit once
a year as I first suggested in this thread ?

Both are effectively saying the same thing - we're changing versions
based on time, not features. So it is largely a matter of whether you
want the actual date visible or not.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Thomas Huth]

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é <berrange@redhat.com> 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 convention is YY.MM though, not YYMM.
>>>
>>> It feels like we've got quite a strong backing for time based versioning
>>> amongst people replying here. I'd be happy with YY.MM
>>
>> I'm not hugely in favour mostly because I don't much like
>> changing version numbering formats -- does it really gain
>> us anything? But I guess it's a bit of a bikeshed-colour question.
> 
> You mean the change from 3 to 2 digits ?   We would presumably need to
> stick a zero on the end of it anyway. eg  18.04.0 indicates 2018, May
> initial release. Then 18.04.1 indicates the first stable branch release,
> etc.
> 
> Or if you mean you don't like the jump from 2.x to 18.x, we could just
> follow a time based version scheme, but just bumping major digit once
> a year as I first suggested in this thread ?
> 
> Both are effectively saying the same thing - we're changing versions
> based on time, not features. So it is largely a matter of whether you
> want the actual date visible or not.

If we're going to a year-based numbering, I think we should do it the
"libvirt" way and simply increment the current number by one each year,
instead of jumping directly to 18. So in case this numbering scheme does
not work out as we expected, we can easier revert back to another
numbering scheme, without looking completely stupid due to the big
number gap and without having to explain later why QEMU version 19 is
*not* released in the year 2019.

 Thomas

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

[Gerd Hoffmann]

On Thu, May 03, 2018 at 10:26:40AM +0100, Peter Maydell wrote:
> On 3 May 2018 at 10:07, Daniel P. Berrangé <berrange@redhat.com> 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 convention is YY.MM though, not YYMM.
> >
> > It feels like we've got quite a strong backing for time based versioning
> > amongst people replying here. I'd be happy with YY.MM
> 
> I'm not hugely in favour mostly because I don't much like
> changing version numbering formats -- does it really gain
> us anything? But I guess it's a bit of a bikeshed-colour question.

Well, major/minor numbers don't mean anything.  So I think it makes
sense to give them a meaning, and given we do time-based releases it
surely makes sense to use a time-based scheme.  Major indicating the
year is the obvious and common choice here.  Various variants are in
use:

  (a) major equals year, minor equals month (ubuntu style).
  (b) major equals year, minor counts up (mesa style).
  (c) major is bumped each year, but doesn't equal year (libvirt style).

If we don't want give them a meaning, how about:

  (d) just drop the minor and count up major each release (systemd style)?

My personal preference would be (a) or (b), because it is easy to see
when a version was released.  (b) looks more like a classic version
number, we would have 18.0, 18.1, ... instead of 18.04, 18.08, ...

cheers,
  Gerd

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

[Thomas Huth]

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é <berrange@redhat.com> 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 convention is YY.MM though, not YYMM.
>>>
>>> It feels like we've got quite a strong backing for time based versioning
>>> amongst people replying here. I'd be happy with YY.MM
>>
>> I'm not hugely in favour mostly because I don't much like
>> changing version numbering formats -- does it really gain
>> us anything? But I guess it's a bit of a bikeshed-colour question.
> 
> Well, major/minor numbers don't mean anything.  So I think it makes
> sense to give them a meaning, and given we do time-based releases it
> surely makes sense to use a time-based scheme.  Major indicating the
> year is the obvious and common choice here.  Various variants are in
> use:
> 
>   (a) major equals year, minor equals month (ubuntu style).
>   (b) major equals year, minor counts up (mesa style).
>   (c) major is bumped each year, but doesn't equal year (libvirt style).
> 
> If we don't want give them a meaning, how about:
> 
>   (d) just drop the minor and count up major each release (systemd style)?
> 
> My personal preference would be (a) or (b), because it is easy to see
> when a version was released.  (b) looks more like a classic version
> number, we would have 18.0, 18.1, ... instead of 18.04, 18.08, ...

I'd really would like to avoid variant (a) ... otherwise people will
confuse 18.1.1 and 18.11 (aka. 18.11.0) again...

 Thomas

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

[Daniel P. Berrangé]

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é <berrange@redhat.com> 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 convention is YY.MM though, not YYMM.
> >>>
> >>> It feels like we've got quite a strong backing for time based versioning
> >>> amongst people replying here. I'd be happy with YY.MM
> >>
> >> I'm not hugely in favour mostly because I don't much like
> >> changing version numbering formats -- does it really gain
> >> us anything? But I guess it's a bit of a bikeshed-colour question.
> > 
> > Well, major/minor numbers don't mean anything.  So I think it makes
> > sense to give them a meaning, and given we do time-based releases it
> > surely makes sense to use a time-based scheme.  Major indicating the
> > year is the obvious and common choice here.  Various variants are in
> > use:
> > 
> >   (a) major equals year, minor equals month (ubuntu style).
> >   (b) major equals year, minor counts up (mesa style).
> >   (c) major is bumped each year, but doesn't equal year (libvirt style).
> > 
> > If we don't want give them a meaning, how about:
> > 
> >   (d) just drop the minor and count up major each release (systemd style)?
> > 
> > My personal preference would be (a) or (b), because it is easy to see
> > when a version was released.  (b) looks more like a classic version
> > number, we would have 18.0, 18.1, ... instead of 18.04, 18.08, ...
> 
> I'd really would like to avoid variant (a) ... otherwise people will
> confuse 18.1.1 and 18.11 (aka. 18.11.0) again...

We could keep major == year, minor == nth release of $year. eg 18.1,
18.2, 18.3 for the 1st, 2nd and 3rd releases of 2018. Still makes it
fairly clear what timeframe each was released in, without having to
follow month numbers.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Kashyap Chamarthy]

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 (mesa style).
> > >   (c) major is bumped each year, but doesn't equal year (libvirt style).
> > > 
> > > If we don't want give them a meaning, how about:
> > > 
> > >   (d) just drop the minor and count up major each release (systemd style)?
> > > 
> > > My personal preference would be (a) or (b), because it is easy to see
> > > when a version was released.  (b) looks more like a classic version
> > > number, we would have 18.0, 18.1, ... instead of 18.04, 18.08, ...
> > 
> > I'd really would like to avoid variant (a) ... otherwise people will
> > confuse 18.1.1 and 18.11 (aka. 18.11.0) again...
> 
> We could keep major == year, minor == nth release of $year. eg 18.1,
> 18.2, 18.3 for the 1st, 2nd and 3rd releases of 2018. Still makes it
> fairly clear what timeframe each was released in, without having to
> follow month numbers.

FWIW, the above option sounds simplest to explain so far.

-- 
/kashyap

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

[Thomas Huth]

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 style).
>>>>   (b) major equals year, minor counts up (mesa style).
>>>>   (c) major is bumped each year, but doesn't equal year (libvirt style).
>>>>
>>>> If we don't want give them a meaning, how about:
>>>>
>>>>   (d) just drop the minor and count up major each release (systemd style)?
>>>>
>>>> My personal preference would be (a) or (b), because it is easy to see
>>>> when a version was released.  (b) looks more like a classic version
>>>> number, we would have 18.0, 18.1, ... instead of 18.04, 18.08, ...
>>>
>>> I'd really would like to avoid variant (a) ... otherwise people will
>>> confuse 18.1.1 and 18.11 (aka. 18.11.0) again...
>>
>> We could keep major == year, minor == nth release of $year. eg 18.1,
>> 18.2, 18.3 for the 1st, 2nd and 3rd releases of 2018. Still makes it
>> fairly clear what timeframe each was released in, without having to
>> follow month numbers.
> 
> FWIW, the above option sounds simplest to explain so far.

No, there are some drawbacks when the major version equals the year, see
here:

https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg01092.html

and:

https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg00560.html

 Thomas

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

[Cornelia Huck]

On Thu, 3 May 2018 16:06:19 +0200
Thomas Huth <thuth@redhat.com> 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é <berrange@redhat.com> 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 convention is YY.MM though, not YYMM.  
> >>>
> >>> It feels like we've got quite a strong backing for time based versioning
> >>> amongst people replying here. I'd be happy with YY.MM  
> >>
> >> I'm not hugely in favour mostly because I don't much like
> >> changing version numbering formats -- does it really gain
> >> us anything? But I guess it's a bit of a bikeshed-colour question.  
> > 
> > Well, major/minor numbers don't mean anything.  So I think it makes
> > sense to give them a meaning, and given we do time-based releases it
> > surely makes sense to use a time-based scheme.  Major indicating the
> > year is the obvious and common choice here.  Various variants are in
> > use:
> > 
> >   (a) major equals year, minor equals month (ubuntu style).
> >   (b) major equals year, minor counts up (mesa style).
> >   (c) major is bumped each year, but doesn't equal year (libvirt style).
> > 
> > If we don't want give them a meaning, how about:
> > 
> >   (d) just drop the minor and count up major each release (systemd style)?
> > 
> > My personal preference would be (a) or (b), because it is easy to see
> > when a version was released.  (b) looks more like a classic version
> > number, we would have 18.0, 18.1, ... instead of 18.04, 18.08, ...  
> 
> I'd really would like to avoid variant (a) ... otherwise people will
> confuse 18.1.1 and 18.11 (aka. 18.11.0) again...

Just use YYYY instead of YY :)

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

[Kevin Wolf]

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é <berrange@redhat.com> 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 convention is YY.MM though, not YYMM.
> > >
> > > It feels like we've got quite a strong backing for time based versioning
> > > amongst people replying here. I'd be happy with YY.MM
> > 
> > I'm not hugely in favour mostly because I don't much like
> > changing version numbering formats -- does it really gain
> > us anything? But I guess it's a bit of a bikeshed-colour question.
> 
> Well, major/minor numbers don't mean anything.  So I think it makes
> sense to give them a meaning, and given we do time-based releases it
> surely makes sense to use a time-based scheme.  Major indicating the
> year is the obvious and common choice here.  Various variants are in
> use:
> 
>   (a) major equals year, minor equals month (ubuntu style).
>   (b) major equals year, minor counts up (mesa style).
>   (c) major is bumped each year, but doesn't equal year (libvirt style).

I generally don't like time-based versioning schemes too much, but I
guess the only real objection I can think of is what happens when a
release slips? Either the version number wouldn't match the actual
release date, which doesn't look too good, or it's unpredictable during
the development cycle and we'd have to get used to fixing up things like
the "Since:" specification in the QAPI schema immediately before a
release.

But if I had to choose between these options, I think I'd go for (b) or
(c).

> If we don't want give them a meaning, how about:
> 
>   (d) just drop the minor and count up major each release (systemd style)?

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. would be stable
releases, and the December release would be 4.0.

It feels like the minimal change to fix our existing versioning scheme.

Or in fact:

    (e) What's the problem with 2.42, really?

I agree that a constant "2." prefix isn't really useful, but it probably
doesn't really hurt either.

Kevin

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

[Thomas Huth]

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é <berrange@redhat.com> 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 convention is YY.MM though, not YYMM.
>>>>
>>>> It feels like we've got quite a strong backing for time based versioning
>>>> amongst people replying here. I'd be happy with YY.MM
>>>
>>> I'm not hugely in favour mostly because I don't much like
>>> changing version numbering formats -- does it really gain
>>> us anything? But I guess it's a bit of a bikeshed-colour question.
>>
>> Well, major/minor numbers don't mean anything.  So I think it makes
>> sense to give them a meaning, and given we do time-based releases it
>> surely makes sense to use a time-based scheme.  Major indicating the
>> year is the obvious and common choice here.  Various variants are in
>> use:
>>
>>   (a) major equals year, minor equals month (ubuntu style).
>>   (b) major equals year, minor counts up (mesa style).
>>   (c) major is bumped each year, but doesn't equal year (libvirt style).
> 
> I generally don't like time-based versioning schemes too much, but I
> guess the only real objection I can think of is what happens when a
> release slips? Either the version number wouldn't match the actual
> release date, which doesn't look too good, or it's unpredictable during
> the development cycle and we'd have to get used to fixing up things like
> the "Since:" specification in the QAPI schema immediately before a
> release.

... and numbered machine types ...
That's a very good point indeed, Kevin. We really should *not* do (a).
And since we're currently doing releases in December, which could slip
to January of the next year, I think we also should not do (b). This
will only cause confusion and wrong expectations otherwise. So if we
decide to bump the major release each year, (c) sounds like the best
option to me (and if we slip such a release from December to January, it
should be ok to keep the old major number).

>> If we don't want give them a meaning, how about:
>>
>>   (d) just drop the minor and count up major each release (systemd style)?
> 
> 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. would be stable
> releases, and the December release would be 4.0.

Well, the version numbers will increase pretty fast this way. We should
not be afraid of having QEMU 4711 one day...

> It feels like the minimal change to fix our existing versioning scheme.
> 
> Or in fact:
> 
>     (e) What's the problem with 2.42, really?

People tend to mix up 2.42 with 2.4.2 ... and sometimes you get bad
sorting in directory listings, when e.g. qemu-2.10.0-... shows up before
qemu-2.2.0-... etc.

> I agree that a constant "2." prefix isn't really useful, but it probably
> doesn't really hurt either.

So let's do it the (old) Java / Sun way and simply drop the major number
and continue counting with the minor number? Hmmm, no, never mind.

 Thomas

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

[Kevin Wolf]

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é <berrange@redhat.com> 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 convention is YY.MM though, not YYMM.
> >>>>
> >>>> It feels like we've got quite a strong backing for time based versioning
> >>>> amongst people replying here. I'd be happy with YY.MM
> >>>
> >>> I'm not hugely in favour mostly because I don't much like
> >>> changing version numbering formats -- does it really gain
> >>> us anything? But I guess it's a bit of a bikeshed-colour question.
> >>
> >> Well, major/minor numbers don't mean anything.  So I think it makes
> >> sense to give them a meaning, and given we do time-based releases it
> >> surely makes sense to use a time-based scheme.  Major indicating the
> >> year is the obvious and common choice here.  Various variants are in
> >> use:
> >>
> >>   (a) major equals year, minor equals month (ubuntu style).
> >>   (b) major equals year, minor counts up (mesa style).
> >>   (c) major is bumped each year, but doesn't equal year (libvirt style).
> > 
> > I generally don't like time-based versioning schemes too much, but I
> > guess the only real objection I can think of is what happens when a
> > release slips? Either the version number wouldn't match the actual
> > release date, which doesn't look too good, or it's unpredictable during
> > the development cycle and we'd have to get used to fixing up things like
> > the "Since:" specification in the QAPI schema immediately before a
> > release.
> 
> ... and numbered machine types ...
> That's a very good point indeed, Kevin. We really should *not* do (a).
> And since we're currently doing releases in December, which could slip
> to January of the next year, I think we also should not do (b). This
> will only cause confusion and wrong expectations otherwise. So if we
> decide to bump the major release each year, (c) sounds like the best
> option to me (and if we slip such a release from December to January, it
> should be ok to keep the old major number).

Yes, I guess (c) could still work.

> >> If we don't want give them a meaning, how about:
> >>
> >>   (d) just drop the minor and count up major each release (systemd style)?
> > 
> > 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. would be stable
> > releases, and the December release would be 4.0.
> 
> Well, the version numbers will increase pretty fast this way. We should
> not be afraid of having QEMU 4711 one day...

Indeed, we'd get there in only 1569 years if we keep our current release
frequency until then.

More seriously, if you want to keep major and minor, and prefer them
both to stay low as long as possible, the ..., 3.9, 4.0, ... model is
probably what gets you closest to that.

On the other hand, I don't think it would be horrible if in about twenty
years we ended up at the 59.0 that Firefox has today.

> > It feels like the minimal change to fix our existing versioning scheme.
> > 
> > Or in fact:
> > 
> >     (e) What's the problem with 2.42, really?
> 
> People tend to mix up 2.42 with 2.4.2 ... and sometimes you get bad
> sorting in directory listings, when e.g. qemu-2.10.0-... shows up before
> qemu-2.2.0-... etc.

Good points, though I see them more as minor annoyances.

Anyway, it's a general point about double-digit minor versions and
another reason why (a) isn't a good idea if you plan to make releases
between October and December.

> > I agree that a constant "2." prefix isn't really useful, but it probably
> > doesn't really hurt either.
> 
> So let's do it the (old) Java / Sun way and simply drop the major number
> and continue counting with the minor number? Hmmm, no, never mind.

Would be essentially the same as I suggested, except starting with 13.0
instead of 3.0.

Kevin

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

[Richard Henderson]

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. would be stable
> releases, and the December release would be 4.0.
> 
> It feels like the minimal change to fix our existing versioning scheme.

This is very similar to what GCC started to use at version 5.

    https://gcc.gnu.org/develop.html#num_scheme

I do think it makes sense to drop minor versions, leaving only major +
patchlevel (which then appears to be minor version).


r~

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

[Thomas Huth]

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 would result in 3.0 for the next release, 3.1 etc. would be stable
>> releases, and the December release would be 4.0.
>>
>> It feels like the minimal change to fix our existing versioning scheme.
> 
> This is very similar to what GCC started to use at version 5.
> 
>     https://gcc.gnu.org/develop.html#num_scheme
> 
> I do think it makes sense to drop minor versions, leaving only major +
> patchlevel (which then appears to be minor version).

We're currently also using the patch level for marking developing
version (x.y.50) and release candidates (x.y.9r) ... we should also
think of a way how we want to map that to a new numbering scheme. If we
do it the GCC way, I guess the x.0 release will be the development
"versions"? But the release candidates? Do we still need a third number
for doing those (3.0.1 = rc1, 3.0.2 = rc2, ...)?

 Thomas

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

[Kevin Wolf]

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
> >> version number for QEMU, I'd just merge them.
> >>
> >> This would result in 3.0 for the next release, 3.1 etc. would be stable
> >> releases, and the December release would be 4.0.
> >>
> >> It feels like the minimal change to fix our existing versioning scheme.
> > 
> > This is very similar to what GCC started to use at version 5.
> > 
> >     https://gcc.gnu.org/develop.html#num_scheme
> > 
> > I do think it makes sense to drop minor versions, leaving only major +
> > patchlevel (which then appears to be minor version).
> 
> We're currently also using the patch level for marking developing
> version (x.y.50) and release candidates (x.y.9r) ... we should also
> think of a way how we want to map that to a new numbering scheme. If we
> do it the GCC way, I guess the x.0 release will be the development
> "versions"? But the release candidates? Do we still need a third number
> for doing those (3.0.1 = rc1, 3.0.2 = rc2, ...)?

Nothing stops you from using 3.50, 3.91, etc. like we always did.

Kevin

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

[Peter Maydell]

On 30 April 2018 at 11:33, Daniel P. Berrangé <berrange@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.

I realised we didn't really come to a conclusion in this discussion.
I've reread the thread, and my proposal is to arbitrarily pick
something which accords with my aesthetic preferences, which is
this one that Dan suggests.

That will make the next release be 3.0.0.

thanks
-- PMM

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

[Daniel P. Berrangé]

On Tue, May 22, 2018 at 11:07:04AM +0100, Peter Maydell wrote:
> On 30 April 2018 at 11:33, Daniel P. Berrangé <berrange@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.
> 
> I realised we didn't really come to a conclusion in this discussion.
> I've reread the thread, and my proposal is to arbitrarily pick
> something which accords with my aesthetic preferences, which is
> this one that Dan suggests.
>
> That will make the next release be 3.0.0.


Great, I was hoping you would play benevolent leader and arbitrarily
pick one of the options to bring this to a close :-)

FYI, i'll aim to send a patch that documents this versioning plan for
future reference.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Greg Kurz]

On Fri, 27 Apr 2018 16:51:03 +0100
Peter Maydell <peter.maydell@linaro.org> 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
> but maybe we should anyway?
> 

Do we care for machine versions to stick to QEMU versions ? I ask,
because we've already added a pseries-2.13 machine type (in master
since David's latest pull req). No big deal though if we have to
turn it into pseries-3.0 I guess...

> (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 definitely done by the middle of August, to avoid a clash
>    with a personal commitment
>  * so probably hardfreeze 10th July, softfreeze 3rd July
> 
> (3) retrospective, lessons learned &c
>  * please remember that if every single submaintainer submits
>    a pull request on the morning of an RC, it is physically
>    not possible for me to process all those pulls in time to
>    tag the RC that day. We had several RCs which got delayed
>    by a day because of this; please try to submit earlier
>    rather than later...
>  * provide your opinions here ?
> 
> thanks
> -- PMM
> 

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

[Peter Maydell]

On 30 April 2018 at 15:23, Greg Kurz <groug@kaod.org> wrote:
> On Fri, 27 Apr 2018 16:51:03 +0100
> Peter Maydell <peter.maydell@linaro.org> 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
>> but maybe we should anyway?
>>
>
> Do we care for machine versions to stick to QEMU versions ? I ask,
> because we've already added a pseries-2.13 machine type (in master
> since David's latest pull req). No big deal though if we have to
> turn it into pseries-3.0 I guess...

Yeah, we'd just bump that to pseries-3.0.

(We should probably have some more formal process for ensuring
that all our versioned machines get a version for the new
release at some point before rc0. We've been close to forgetting
for virt once or twice.)

thanks
-- PMM

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

[Daniel P. Berrangé]

On Mon, Apr 30, 2018 at 04:23:59PM +0200, Greg Kurz wrote:
> On Fri, 27 Apr 2018 16:51:03 +0100
> Peter Maydell <peter.maydell@linaro.org> 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
> > but maybe we should anyway?
> > 
> 
> Do we care for machine versions to stick to QEMU versions ? I ask,
> because we've already added a pseries-2.13 machine type (in master
> since David's latest pull req). No big deal though if we have to
> turn it into pseries-3.0 I guess...

We don't promise machine ABI compat for git master snapshots, so renaming
is fine provided it is done before release.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2093 bytes --]

On Mon, Apr 30, 2018 at 04:23:59PM +0200, Greg Kurz wrote:
> On Fri, 27 Apr 2018 16:51:03 +0100
> Peter Maydell <peter.maydell@linaro.org> 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
> > but maybe we should anyway?
> > 
> 
> Do we care for machine versions to stick to QEMU versions ? I ask,
> because we've already added a pseries-2.13 machine type (in master
> since David's latest pull req). No big deal though if we have to
> turn it into pseries-3.0 I guess...

We definitely want this to match the overall release name, so we'll
need to change it if we decide on something other than 2.13.

> 
> > (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 definitely done by the middle of August, to avoid a clash
> >    with a personal commitment
> >  * so probably hardfreeze 10th July, softfreeze 3rd July
> > 
> > (3) retrospective, lessons learned &c
> >  * please remember that if every single submaintainer submits
> >    a pull request on the morning of an RC, it is physically
> >    not possible for me to process all those pulls in time to
> >    tag the RC that day. We had several RCs which got delayed
> >    by a day because of this; please try to submit earlier
> >    rather than later...
> >  * provide your opinions here ?
> > 
> > thanks
> > -- PMM
> > 
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]

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 definitely done by the middle of August, to avoid a clash
>    with a personal commitment

I will be offline mid-August to mid-September, sorry.  Someone else can
volunteer to do the release.

> (3) retrospective, lessons learned &c
>  * please remember that if every single submaintainer submits
>    a pull request on the morning of an RC, it is physically
>    not possible for me to process all those pulls in time to
>    tag the RC that day. We had several RCs which got delayed
>    by a day because of this; please try to submit earlier
>    rather than later...
>  * provide your opinions here ?

Paolo asked sub-maintainers to include changelogs in pull request
messages.  This will make it easy to collate the QEMU 3.0 changelog just
from the merge commits.  I think it's a good idea.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

[Peter Maydell]

On 1 May 2018 at 13:24, Stefan Hajnoczi <stefanha@redhat.com> 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
>>    cycle we might need to wind that in by a couple of weeks so
>>    it's definitely done by the middle of August, to avoid a clash
>>    with a personal commitment
>
> I will be offline mid-August to mid-September, sorry.  Someone else can
> volunteer to do the release.

I think the best approach is that we'll make sure the dates for
the release are set so it's definitely done by mid-August,
and we'll find a suitable volunteer to do the post-release
pull request handling for late August/September...

-- PMM

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

[Laurent Vivier]

[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]

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 need to wind that in by a couple of weeks so
>>    it's definitely done by the middle of August, to avoid a clash
>>    with a personal commitment
> 
> I will be offline mid-August to mid-September, sorry.  Someone else can
> volunteer to do the release.
> 
>> (3) retrospective, lessons learned &c
>>  * please remember that if every single submaintainer submits
>>    a pull request on the morning of an RC, it is physically
>>    not possible for me to process all those pulls in time to
>>    tag the RC that day. We had several RCs which got delayed
>>    by a day because of this; please try to submit earlier
>>    rather than later...
>>  * provide your opinions here ?
> 
> Paolo asked sub-maintainers to include changelogs in pull request
> messages.  This will make it easy to collate the QEMU 3.0 changelog just
> from the merge commits.  I think it's a good idea.

BTW, is there a way to have "git publish --pull-request" opens
automatically an editor with the cover letter?

I've just forgot to fill the entry in my last pull request...

Thanks,
Laurent


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1814 bytes --]

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 persuade Stefan to do the release management this
> >>    cycle we might need to wind that in by a couple of weeks so
> >>    it's definitely done by the middle of August, to avoid a clash
> >>    with a personal commitment
> > 
> > I will be offline mid-August to mid-September, sorry.  Someone else can
> > volunteer to do the release.
> > 
> >> (3) retrospective, lessons learned &c
> >>  * please remember that if every single submaintainer submits
> >>    a pull request on the morning of an RC, it is physically
> >>    not possible for me to process all those pulls in time to
> >>    tag the RC that day. We had several RCs which got delayed
> >>    by a day because of this; please try to submit earlier
> >>    rather than later...
> >>  * provide your opinions here ?
> > 
> > Paolo asked sub-maintainers to include changelogs in pull request
> > messages.  This will make it easy to collate the QEMU 3.0 changelog just
> > from the merge commits.  I think it's a good idea.
> 
> BTW, is there a way to have "git publish --pull-request" opens
> automatically an editor with the cover letter?
> 
> I've just forgot to fill the entry in my last pull request...

Yes, this is the new default in git-publish v1.4.3.  Please make sure
you have the latest version.

Fedora and EPEL RPMs are available (updates will be pushed next Tuesday):
https://apps.fedoraproject.org/packages/git-publish

GitHub:
https://github.com/stefanha/git-publish/releases/tag/v1.4.3

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

[Philippe Mathieu-Daudé]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

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 &c
[...]
>  * provide your opinions here ?

Maybe v3 is a good opportunity to update QEMU standards...

- Clarify which APIs are outdated
  (Add /* DEPRECATED (use: NiceApi3.0) */ comments around)

- Select some up-to-date and recommended (well-documented)
  boards/device/block examples for newcomers (add in Wiki)

Some more painful ideas:

- Public function/structures added/modified get documentation
  (kernel-doc / Sphinx)

- New feature gets unit-qtesting (make check-unit)

- New device gets acceptance qtesting (make check-qtest)

- New board gets integration qtesting (boot BIOS/FW, Avocado)

I understand each maintainer manage his tree with his own criterion, IMO
these might be the minimum requested for paid contributors.

Regards,

Phil.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]