On 11.05.2017 17:10, Markus Armbruster wrote:
> "Daniel P. Berrange" writes:
>
>> On Wed, May 10, 2017 at 06:15:39PM +0200, Paolo Bonzini wrote:
>>>
>>>
>>> On 10/05/2017 16:47, Thomas Huth wrote:
> So while we can delete pc-0.12, we can't delete associated features needed
> by pc-0.12, w
"Daniel P. Berrange" writes:
> On Wed, May 10, 2017 at 06:15:39PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 10/05/2017 16:47, Thomas Huth wrote:
>> >> So while we can delete pc-0.12, we can't delete associated features needed
>> >> by pc-0.12, without complicating RHEL's ability to create its bac
On Wed, May 10, 2017 at 06:15:39PM +0200, Paolo Bonzini wrote:
>
>
> On 10/05/2017 16:47, Thomas Huth wrote:
> >> So while we can delete pc-0.12, we can't delete associated features needed
> >> by pc-0.12, without complicating RHEL's ability to create its back-compat
> >> machine types. Downstrea
"Dr. David Alan Gilbert" writes:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
>> On Wed, May 10, 2017 at 03:51:25PM +0100, Dr. David Alan Gilbert wrote:
>> > * Daniel P. Berrange (berra...@redhat.com) wrote:
>> > > If we deprecate in this release (~Aug/Sep 2017), and kill in the next
>> >
On 11.05.2017 09:06, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 10/05/2017 16:47, Thomas Huth wrote:
So while we can delete pc-0.12, we can't delete associated features needed
by pc-0.12, without complicating RHEL's ability to create its back-compat
machine types. Dow
"Dr. David Alan Gilbert" writes:
> * Markus Armbruster (arm...@redhat.com) wrote:
>> Thomas Huth writes:
>>
>> > On 10.05.2017 11:08, Daniel P. Berrange wrote:
>> >> On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote:
>> [...]
>> >> Also unless we're going to get more serious about aut
Paolo Bonzini writes:
> On 10/05/2017 16:47, Thomas Huth wrote:
>>> So while we can delete pc-0.12, we can't delete associated features needed
>>> by pc-0.12, without complicating RHEL's ability to create its back-compat
>>> machine types. Downstream would have to un-delete the features.
>>
>> So
* Markus Armbruster (arm...@redhat.com) wrote:
> Thomas Huth writes:
>
> > On 10.05.2017 11:08, Daniel P. Berrange wrote:
> >> On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote:
> [...]
> >> Also unless we're going to get more serious about automated testing to
> >> validate machine typ
On 10/05/2017 16:47, Thomas Huth wrote:
>> So while we can delete pc-0.12, we can't delete associated features needed
>> by pc-0.12, without complicating RHEL's ability to create its back-compat
>> machine types. Downstream would have to un-delete the features.
>
> So I guess this is why Paolo sa
On 10/05/2017 17:37, Markus Armbruster wrote:
> Distro vendors put in serious work to keep versions working for 5 - 10
> years. We can't, and we don't. All we do is try not to break things,
> which is nice, and helps the distro vendors some, but a far cry from
> anything I'd dare call "support"
Thomas Huth writes:
> On 10.05.2017 11:08, Daniel P. Berrange wrote:
>> On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote:
[...]
>> Also unless we're going to get more serious about automated testing to
>> validate machine type compatibility between *all* previously releases,
>> I think
* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Wed, May 10, 2017 at 03:51:25PM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > If we deprecate in this release (~Aug/Sep 2017), and kill in the next
> > > release (Dec 2017), that means our old
On 10/05/2017 16:51, Dr. David Alan Gilbert wrote:
> I'll give you a manual one; I just migrated:
>/opt/qemu/v1.0.1/bin/qemu-system-x86_64 -M pc-1.0 -m 2G
> /home/vms/f23-serial-010.qcow2 -M pc-1.0 -nographic
> to
>/opt/qemu/v2.9.0/bin/qemu-system-x86_64 -M pc-1.0 -m 2G
> /home/vms/f23-
On Wed, May 10, 2017 at 03:51:25PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
> > If we deprecate in this release (~Aug/Sep 2017), and kill in the next
> > release (Dec 2017), that means our oldest machine type pc-1.0 is still
> > going to be 6 years,
* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote:
> > We don't want to carry along old machine types forever. If we are able to
> > remove the pc machines up to 0.13 one day for example, this would allow
> > us to eventually kill the co
On 10.05.2017 12:31, Daniel P. Berrange wrote:
> On Wed, May 10, 2017 at 12:05:16PM +0200, Thomas Huth wrote:
>> On 10.05.2017 11:08, Daniel P. Berrange wrote:
[...]
>>> - Do we really think that we still have users with VMs that are
>>> stuck on a 6 year old machine type from 18 major releas
On Wed, May 10, 2017 at 12:05:16PM +0200, Thomas Huth wrote:
> On 10.05.2017 11:08, Daniel P. Berrange wrote:
> > On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote:
> >> We don't want to carry along old machine types forever. If we are able to
> >> remove the pc machines up to 0.13 one da
On 10.05.2017 11:08, Daniel P. Berrange wrote:
> On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote:
>> We don't want to carry along old machine types forever. If we are able to
>> remove the pc machines up to 0.13 one day for example, this would allow
>> us to eventually kill the code for
On Wed, May 10, 2017 at 08:48:53AM +0200, Thomas Huth wrote:
> We don't want to carry along old machine types forever. If we are able to
> remove the pc machines up to 0.13 one day for example, this would allow
> us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
> BARs directl
We don't want to carry along old machine types forever. If we are able to
remove the pc machines up to 0.13 one day for example, this would allow
us to eventually kill the code for rombar=0 (i.e. where QEMU copies ROM
BARs directly to low memory). So let's start with a deprecation message
for the o
20 matches
Mail list logo
