KVM call agenda for May, Tuesday 8th

KVM call agenda for May, Tuesday 8th

[Juan Quintela]

Hi

Please send in any agenda items you are interested in covering.

Thanks, Juan.

[Qemu-devel] KVM call agenda for May, Tuesday 8th

[Juan Quintela]

Hi

Please send in any agenda items you are interested in covering.

Thanks, Juan.

Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[Anthony Liguori]

On 05/07/2012 06:47 AM, Juan Quintela wrote:
>
> Hi
>
> Please send in any agenda items you are interested in covering.

- Status of the 1.1 release

Regards,

Anthony Liguori

>
> Thanks, Juan.
>
>

Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[Anthony Liguori]

On 05/07/2012 06:47 AM, Juan Quintela wrote:
>
> Hi
>
> Please send in any agenda items you are interested in covering.

- Status of the 1.1 release

Regards,

Anthony Liguori

>
> Thanks, Juan.
>
>

Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[Andreas Färber]

Am 07.05.2012 14:54, schrieb Anthony Liguori:
> On 05/07/2012 06:47 AM, Juan Quintela wrote:
>>
>> Please send in any agenda items you are interested in covering.
> 
> - Status of the 1.1 release

Since it looked like the call is not going to take place lacking
feedback from Anthony, I will provocatively go ahead and say the status
of 1.1 is pretty bad, currently. ;)

rc0 is available, but patches submitted for 1.1 shortly before rc0
neither got review nor were applied. Neither did pulls or patches
applied by Anthony get such a notice fwiw so that it's hard to
distinguish what's missing for anyone but the patch author.

With rc0 not being provided as tarball, it would be nice to document the
official, reproducible way of packaging a QEMU tarball on the Wiki. I
have collected some steps from the Rob Landley mips thread, but the
submodules complicate things a bit.

rc1 should've been released yesterday, but it's not available yet, no
info and same issue with patches not being applied.

In the current state of master, rc1 will not build on ppc due to an
#error introduced since rc0 by malc - with its history, Darwin/ppc
should not be a release blocker here and *some* fix to restore the build
should please be applied soon.

And worse, there's more and more colliding patch series on the list -
fixed-width visitors, realize, QBus, VMState, AREG0, CPU - for which we
need a strategy to coordinate our ongoing development and post-1.1
merging. Someone needs to rebase on someone else, question is whom.

Some downstream feedback: I've so far been unable to do a static build
of v1.1-rc0 in the openSUSE build system due to a -lpcre coming from
gthread-2.0.pc Libs.private - an issue we don't see for v1.0.1. If
another distro has encountered that issue I'd be grateful for feedback.
Might be our own issue.
In course of investigating though, I've noticed that lots of our
configure checks are not limited to non-static/softmmu builds and will
contribute cflags/libs to a static linux-user build even if unused.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[Andreas Färber]

Am 07.05.2012 14:54, schrieb Anthony Liguori:
> On 05/07/2012 06:47 AM, Juan Quintela wrote:
>>
>> Please send in any agenda items you are interested in covering.
> 
> - Status of the 1.1 release

Since it looked like the call is not going to take place lacking
feedback from Anthony, I will provocatively go ahead and say the status
of 1.1 is pretty bad, currently. ;)

rc0 is available, but patches submitted for 1.1 shortly before rc0
neither got review nor were applied. Neither did pulls or patches
applied by Anthony get such a notice fwiw so that it's hard to
distinguish what's missing for anyone but the patch author.

With rc0 not being provided as tarball, it would be nice to document the
official, reproducible way of packaging a QEMU tarball on the Wiki. I
have collected some steps from the Rob Landley mips thread, but the
submodules complicate things a bit.

rc1 should've been released yesterday, but it's not available yet, no
info and same issue with patches not being applied.

In the current state of master, rc1 will not build on ppc due to an
#error introduced since rc0 by malc - with its history, Darwin/ppc
should not be a release blocker here and *some* fix to restore the build
should please be applied soon.

And worse, there's more and more colliding patch series on the list -
fixed-width visitors, realize, QBus, VMState, AREG0, CPU - for which we
need a strategy to coordinate our ongoing development and post-1.1
merging. Someone needs to rebase on someone else, question is whom.

Some downstream feedback: I've so far been unable to do a static build
of v1.1-rc0 in the openSUSE build system due to a -lpcre coming from
gthread-2.0.pc Libs.private - an issue we don't see for v1.0.1. If
another distro has encountered that issue I'd be grateful for feedback.
Might be our own issue.
In course of investigating though, I've noticed that lots of our
configure checks are not limited to non-static/softmmu builds and will
contribute cflags/libs to a static linux-user build even if unused.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[Anthony Liguori]

On 05/08/2012 09:10 AM, Andreas Färber wrote:
> Am 07.05.2012 14:54, schrieb Anthony Liguori:
>> On 05/07/2012 06:47 AM, Juan Quintela wrote:
>>>
>>> Please send in any agenda items you are interested in covering.
>>
>> - Status of the 1.1 release
>
> Since it looked like the call is not going to take place lacking
> feedback from Anthony, I will provocatively go ahead and say the status
> of 1.1 is pretty bad, currently. ;)
>
> rc0 is available, but patches submitted for 1.1 shortly before rc0
> neither got review nor were applied. Neither did pulls or patches
> applied by Anthony get such a notice fwiw so that it's hard to
> distinguish what's missing for anyone but the patch author.

All pulls got handled before -rc0 was tagged.

>
> With rc0 not being provided as tarball, it would be nice to document the
> official, reproducible way of packaging a QEMU tarball on the Wiki. I
> have collected some steps from the Rob Landley mips thread, but the
> submodules complicate things a bit.

-rc0's are never provided as a tarball.  This is how the release process works 
and someone always complains about it :-(

> rc1 should've been released yesterday, but it's not available yet, no
> info and same issue with patches not being applied.

I missed a flight yesterday and spent the entire day at an airport so I didn't 
tag it yesterday.  I'm going to work on it today.

> In the current state of master, rc1 will not build on ppc due to an
> #error introduced since rc0 by malc - with its history, Darwin/ppc
> should not be a release blocker here and *some* fix to restore the build
> should please be applied soon.

So... what's the fix?

Regards,

Anthony Liguori

> And worse, there's more and more colliding patch series on the list -
> fixed-width visitors, realize, QBus, VMState, AREG0, CPU - for which we
> need a strategy to coordinate our ongoing development and post-1.1
> merging. Someone needs to rebase on someone else, question is whom.
>
> Some downstream feedback: I've so far been unable to do a static build
> of v1.1-rc0 in the openSUSE build system due to a -lpcre coming from
> gthread-2.0.pc Libs.private - an issue we don't see for v1.0.1. If
> another distro has encountered that issue I'd be grateful for feedback.
> Might be our own issue.
> In course of investigating though, I've noticed that lots of our
> configure checks are not limited to non-static/softmmu builds and will
> contribute cflags/libs to a static linux-user build even if unused.
>
> Regards,
> Andreas
>

Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[Anthony Liguori]

On 05/08/2012 09:10 AM, Andreas Färber wrote:
> Am 07.05.2012 14:54, schrieb Anthony Liguori:
>> On 05/07/2012 06:47 AM, Juan Quintela wrote:
>>>
>>> Please send in any agenda items you are interested in covering.
>>
>> - Status of the 1.1 release
>
> Since it looked like the call is not going to take place lacking
> feedback from Anthony, I will provocatively go ahead and say the status
> of 1.1 is pretty bad, currently. ;)
>
> rc0 is available, but patches submitted for 1.1 shortly before rc0
> neither got review nor were applied. Neither did pulls or patches
> applied by Anthony get such a notice fwiw so that it's hard to
> distinguish what's missing for anyone but the patch author.

All pulls got handled before -rc0 was tagged.

>
> With rc0 not being provided as tarball, it would be nice to document the
> official, reproducible way of packaging a QEMU tarball on the Wiki. I
> have collected some steps from the Rob Landley mips thread, but the
> submodules complicate things a bit.

-rc0's are never provided as a tarball.  This is how the release process works 
and someone always complains about it :-(

> rc1 should've been released yesterday, but it's not available yet, no
> info and same issue with patches not being applied.

I missed a flight yesterday and spent the entire day at an airport so I didn't 
tag it yesterday.  I'm going to work on it today.

> In the current state of master, rc1 will not build on ppc due to an
> #error introduced since rc0 by malc - with its history, Darwin/ppc
> should not be a release blocker here and *some* fix to restore the build
> should please be applied soon.

So... what's the fix?

Regards,

Anthony Liguori

> And worse, there's more and more colliding patch series on the list -
> fixed-width visitors, realize, QBus, VMState, AREG0, CPU - for which we
> need a strategy to coordinate our ongoing development and post-1.1
> merging. Someone needs to rebase on someone else, question is whom.
>
> Some downstream feedback: I've so far been unable to do a static build
> of v1.1-rc0 in the openSUSE build system due to a -lpcre coming from
> gthread-2.0.pc Libs.private - an issue we don't see for v1.0.1. If
> another distro has encountered that issue I'd be grateful for feedback.
> Might be our own issue.
> In course of investigating though, I've noticed that lots of our
> configure checks are not limited to non-static/softmmu builds and will
> contribute cflags/libs to a static linux-user build even if unused.
>
> Regards,
> Andreas
>

Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[Andreas Färber]

Am 08.05.2012 16:24, schrieb Anthony Liguori:
> On 05/08/2012 09:10 AM, Andreas Färber wrote:
>> Am 07.05.2012 14:54, schrieb Anthony Liguori:
>> rc0 is available, but patches submitted for 1.1 shortly before rc0
>> neither got review nor were applied. Neither did pulls or patches
>> applied by Anthony get such a notice fwiw so that it's hard to
>> distinguish what's missing for anyone but the patch author.
> 
> All pulls got handled before -rc0 was tagged.

OK, so if you want pulls for particular maintainer-less patch sets, then
please someone say so as a reply.

>> With rc0 not being provided as tarball, it would be nice to document the
>> official, reproducible way of packaging a QEMU tarball on the Wiki. I
>> have collected some steps from the Rob Landley mips thread, but the
>> submodules complicate things a bit.
> 
> -rc0's are never provided as a tarball.  This is how the release process
> works and someone always complains about it :-(

It was not a complaint about a missing tarball. I know from 1.0 that
there isn't one. But in order to prepare packaging for rc1 I find it
useful to start working with rc0 as a test run because it takes time.

My request (not complaint) was for you to document how you create the
tarballs you publish, so that the adventurous can create them without
bothering you. :)

>> rc1 should've been released yesterday, but it's not available yet, no
>> info and same issue with patches not being applied.
> 
> I missed a flight yesterday and spent the entire day at an airport so I
> didn't tag it yesterday.  I'm going to work on it today.

I can live with a tag or tarball being delayed, the issue is patches
people invested time for QA on don't make it into those tags.
This includes valgrind fixes from Stefan, mingw32 warning fixes, my
copyright and configure patches, one QOM CPU cleanup and possibly others
I'm not tracking. Unhandled pulls as well.

>> In the current state of master, rc1 will not build on ppc due to an
>> #error introduced since rc0 by malc - with its history, Darwin/ppc
>> should not be a release blocker here and *some* fix to restore the build
>> should please be applied soon.
> 
> So... what's the fix?

There's three patches floating around, one in the sparc-softmmu
unassigned memory thread, newer ones in a series of mine, and malc is
bouncing build fixes due to minor issues and his inability to test on
Darwin/ppc. I can send new patches for sure, but rather than spending
time on finding a perfect solution, as a SUSE employee, I'd much prefer
to fix the build issue first (and be it by reverting the troubling
#error commit), fix the register issues for Linux and optionally fix
them for Darwin and AIX. Further, the first patch from my series was
already confirmed correct by malc and could've been applied for rc1 but
wasn't (don't care about that one personally though).

What I'm criticizing here is lack of awareness of what milestones we
break by applying or not applying patches. What good is a Hard Freeze if
we wait with applying patches to the last milestone so they hardly get
any testing or if we postpone all fixes to an orphan stable branch?

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[Andreas Färber]

Am 08.05.2012 16:24, schrieb Anthony Liguori:
> On 05/08/2012 09:10 AM, Andreas Färber wrote:
>> Am 07.05.2012 14:54, schrieb Anthony Liguori:
>> rc0 is available, but patches submitted for 1.1 shortly before rc0
>> neither got review nor were applied. Neither did pulls or patches
>> applied by Anthony get such a notice fwiw so that it's hard to
>> distinguish what's missing for anyone but the patch author.
> 
> All pulls got handled before -rc0 was tagged.

OK, so if you want pulls for particular maintainer-less patch sets, then
please someone say so as a reply.

>> With rc0 not being provided as tarball, it would be nice to document the
>> official, reproducible way of packaging a QEMU tarball on the Wiki. I
>> have collected some steps from the Rob Landley mips thread, but the
>> submodules complicate things a bit.
> 
> -rc0's are never provided as a tarball.  This is how the release process
> works and someone always complains about it :-(

It was not a complaint about a missing tarball. I know from 1.0 that
there isn't one. But in order to prepare packaging for rc1 I find it
useful to start working with rc0 as a test run because it takes time.

My request (not complaint) was for you to document how you create the
tarballs you publish, so that the adventurous can create them without
bothering you. :)

>> rc1 should've been released yesterday, but it's not available yet, no
>> info and same issue with patches not being applied.
> 
> I missed a flight yesterday and spent the entire day at an airport so I
> didn't tag it yesterday.  I'm going to work on it today.

I can live with a tag or tarball being delayed, the issue is patches
people invested time for QA on don't make it into those tags.
This includes valgrind fixes from Stefan, mingw32 warning fixes, my
copyright and configure patches, one QOM CPU cleanup and possibly others
I'm not tracking. Unhandled pulls as well.

>> In the current state of master, rc1 will not build on ppc due to an
>> #error introduced since rc0 by malc - with its history, Darwin/ppc
>> should not be a release blocker here and *some* fix to restore the build
>> should please be applied soon.
> 
> So... what's the fix?

There's three patches floating around, one in the sparc-softmmu
unassigned memory thread, newer ones in a series of mine, and malc is
bouncing build fixes due to minor issues and his inability to test on
Darwin/ppc. I can send new patches for sure, but rather than spending
time on finding a perfect solution, as a SUSE employee, I'd much prefer
to fix the build issue first (and be it by reverting the troubling
#error commit), fix the register issues for Linux and optionally fix
them for Darwin and AIX. Further, the first patch from my series was
already confirmed correct by malc and could've been applied for rc1 but
wasn't (don't care about that one personally though).

What I'm criticizing here is lack of awareness of what milestones we
break by applying or not applying patches. What good is a Hard Freeze if
we wait with applying patches to the last milestone so they hardly get
any testing or if we postpone all fixes to an orphan stable branch?

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[Andreas Färber]

Am 08.05.2012 16:53, schrieb Andreas Färber:
> Am 08.05.2012 16:24, schrieb Anthony Liguori:
>> On 05/08/2012 09:10 AM, Andreas Färber wrote:
>>> With rc0 not being provided as tarball, it would be nice to document the
>>> official, reproducible way of packaging a QEMU tarball on the Wiki. I
>>> have collected some steps from the Rob Landley mips thread, but the
>>> submodules complicate things a bit.
> 
> My request (not complaint) was for you to document how you create the
> tarballs you publish, so that the adventurous can create them without
> bothering you. :)

For the record here's part of the script I came up with:

TAG=v1.1-rc0
NAME=qemu-1.1-rc0

git clone git://git.qemu.org/qemu.git $NAME || exit 1

cd $NAME || exit 1

git checkout $TAG || exit 1

git submodule update --init || exit 1

rm -rf .git roms/*/.git || exit 1

cd .. || exit 1

tar -c $NAME | bzip2 > $NAME.tar.bz2

/-F

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[Anthony Liguori]

On 05/08/2012 10:13 AM, Andreas Färber wrote:
> Am 08.05.2012 16:53, schrieb Andreas Färber:
>> Am 08.05.2012 16:24, schrieb Anthony Liguori:
>>> On 05/08/2012 09:10 AM, Andreas Färber wrote:
>>>> With rc0 not being provided as tarball, it would be nice to document the
>>>> official, reproducible way of packaging a QEMU tarball on the Wiki. I
>>>> have collected some steps from the Rob Landley mips thread, but the
>>>> submodules complicate things a bit.
>>
>> My request (not complaint) was for you to document how you create the
>> tarballs you publish, so that the adventurous can create them without
>> bothering you. :)
>
> For the record here's part of the script I came up with:
>
> TAG=v1.1-rc0
> NAME=qemu-1.1-rc0
>
> git clone git://git.qemu.org/qemu.git $NAME || exit 1
>
> cd $NAME || exit 1
>
> git checkout $TAG || exit 1
>
> git submodule update --init || exit 1
>
> rm -rf .git roms/*/.git || exit 1
>
> cd .. || exit 1
>
> tar -c $NAME | bzip2>  $NAME.tar.bz2

That's pretty close to what I do FWIW.

The script I have is a bit more involved as it also takes care of some qemu.org 
things.  I've always meant to add a make dist target but haven't got around to it.

Regards,

Anthony Liguori

>
> /-F
>

Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[Anthony Liguori]

On 05/07/2012 06:47 AM, Juan Quintela wrote:
>
> Hi
>
> Please send in any agenda items you are interested in covering.

- QEMU documentation

qemu-doc.texi is in a pretty awful state.  I'm wondering if anyone has any ideas 
about how we can improve it.  One thing we could do is move the entire contents 
of it to the wiki to allow for broader editing.

I'd also be really happy to have a documentation submaintainer if anyone is 
interested in the role.  Other ideas?

Regards,

Anthony Liguori

>
> Thanks, Juan.
>
>

Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[Anthony Liguori]

On 05/07/2012 06:47 AM, Juan Quintela wrote:
>
> Hi
>
> Please send in any agenda items you are interested in covering.

- QEMU documentation

qemu-doc.texi is in a pretty awful state.  I'm wondering if anyone has any ideas 
about how we can improve it.  One thing we could do is move the entire contents 
of it to the wiki to allow for broader editing.

I'd also be really happy to have a documentation submaintainer if anyone is 
interested in the role.  Other ideas?

Regards,

Anthony Liguori

>
> Thanks, Juan.
>
>

Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[陳韋任]

> - QEMU documentation
> 
> qemu-doc.texi is in a pretty awful state.  I'm wondering if anyone has any ideas 
> about how we can improve it.  One thing we could do is move the entire contents 
> of it to the wiki to allow for broader editing.

  What's qemu-tech.texi status? ;)
 
> I'd also be really happy to have a documentation submaintainer if anyone is 
> interested in the role.  Other ideas?

  IMHO, one of the problem is there are documents scattering out there, not just
in one place. There are too many links on http://wiki.qemu.org/Manual. :/ If
people can focus on one document, then it's easier to make it a good shape.

Regards,
chenwj 

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj

Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[陳韋任]

> - QEMU documentation
> 
> qemu-doc.texi is in a pretty awful state.  I'm wondering if anyone has any ideas 
> about how we can improve it.  One thing we could do is move the entire contents 
> of it to the wiki to allow for broader editing.

  What's qemu-tech.texi status? ;)
 
> I'd also be really happy to have a documentation submaintainer if anyone is 
> interested in the role.  Other ideas?

  IMHO, one of the problem is there are documents scattering out there, not just
in one place. There are too many links on http://wiki.qemu.org/Manual. :/ If
people can focus on one document, then it's easier to make it a good shape.

Regards,
chenwj 

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj

Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[Anthony Liguori]

On 05/07/2012 06:47 AM, Juan Quintela wrote:
>
> Hi
>
> Please send in any agenda items you are interested in covering.

I've got a conflict at 9am as it turns out so I won't be able to attend.

Regards,

Anthony Liguori

>
> Thanks, Juan.
>
>

Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[Anthony Liguori]

On 05/07/2012 06:47 AM, Juan Quintela wrote:
>
> Hi
>
> Please send in any agenda items you are interested in covering.

I've got a conflict at 9am as it turns out so I won't be able to attend.

Regards,

Anthony Liguori

>
> Thanks, Juan.
>
>

Re: KVM call agenda for May, Tuesday 8th

[Alexander Graf]

On 08.05.2012, at 14:14, Anthony Liguori wrote:

> On 05/07/2012 06:47 AM, Juan Quintela wrote:
>> 
>> Hi
>> 
>> Please send in any agenda items you are interested in covering.
> 
> I've got a conflict at 9am as it turns out so I won't be able to attend.

We can always move it an hour earlier, no? :)


Alex

Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[Alexander Graf]

On 08.05.2012, at 14:14, Anthony Liguori wrote:

> On 05/07/2012 06:47 AM, Juan Quintela wrote:
>> 
>> Hi
>> 
>> Please send in any agenda items you are interested in covering.
> 
> I've got a conflict at 9am as it turns out so I won't be able to attend.

We can always move it an hour earlier, no? :)


Alex

Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[Luiz Capitulino]

On Tue, 08 May 2012 07:14:11 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:

> On 05/07/2012 06:47 AM, Juan Quintela wrote:
> >
> > Hi
> >
> > Please send in any agenda items you are interested in covering.
> 
> I've got a conflict at 9am as it turns out so I won't be able to attend.

Does this mean the call is canceled?

Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[Luiz Capitulino]

On Tue, 08 May 2012 07:14:11 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:

> On 05/07/2012 06:47 AM, Juan Quintela wrote:
> >
> > Hi
> >
> > Please send in any agenda items you are interested in covering.
> 
> I've got a conflict at 9am as it turns out so I won't be able to attend.

Does this mean the call is canceled?

Re: KVM call agenda for May, Tuesday 8th

[Juan Quintela]

Juan Quintela <quintela@redhat.com> wrote:
> Hi
>
> Please send in any agenda items you are interested in covering.

Anthony can't make the call, but we have one agenda:

- Status of the 1.1 release
  We can always blame Anthony, as he didn't attend.
- QEMU documentation
  We don't need him to know that it is in bad shape
- Coreboot and QEMU

Later, Juan.

Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[Juan Quintela]

Juan Quintela <quintela@redhat.com> wrote:
> Hi
>
> Please send in any agenda items you are interested in covering.

Anthony can't make the call, but we have one agenda:

- Status of the 1.1 release
  We can always blame Anthony, as he didn't attend.
- QEMU documentation
  We don't need him to know that it is in bad shape
- Coreboot and QEMU

Later, Juan.