[Qemu-devel] KVM call agenda for April 05

[Qemu-devel] KVM call agenda for April 05

[Juan Quintela]

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

Later, Juan.

Re: [Qemu-devel] KVM call agenda for April 05

[Anthony Liguori]

On 04/04/2011 02:22 PM, Juan Quintela wrote:
> Please, send in any agenda items you are interested in covering.

- KVM Forum -- do we have an ETA on CFP?

- Sub-maintainership -- how we can expand and improve upon it

- Trivial patch monkeys^Wteam -- this is an idea Stefan and I have been 
kicking around to help some of the trivial patches get more attention on 
the mailing list

- kvm-autotest -- I don't know if Lucas can join, but I'd like to get an 
update on what the future plans around kvm-autotest is and also have a 
discussion about what folks would like to see improved.

Regards,

Anthony Liguori

> Later, Juan.
>
>

Re: [Qemu-devel] KVM call agenda for April 05

[Lucas Meneghel Rodrigues]

On Mon, 2011-04-04 at 14:59 -0500, Anthony Liguori wrote:
> On 04/04/2011 02:22 PM, Juan Quintela wrote:
> > Please, send in any agenda items you are interested in covering.
> 
> - KVM Forum -- do we have an ETA on CFP?
> 
> - Sub-maintainership -- how we can expand and improve upon it
> 
> - Trivial patch monkeys^Wteam -- this is an idea Stefan and I have been 
> kicking around to help some of the trivial patches get more attention on 
> the mailing list
> 
> - kvm-autotest -- I don't know if Lucas can join, but I'd like to get an 
> update on what the future plans around kvm-autotest is and also have a 
> discussion about what folks would like to see improved.

Count me in!

> Regards,
> 
> Anthony Liguori
> 
> > Later, Juan.
> >
> >
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] KVM call agenda for April 05

[Brad Hards]

On Tue, 5 Apr 2011 05:59:27 am Anthony Liguori wrote:
> - Trivial patch monkeys^Wteam -- this is an idea Stefan and I have been
> kicking around to help some of the trivial patches get more attention on
> the mailing list
I saw a wiki page (http://wiki.qemu.org/Contribute/TrivialPatches) that I 
assumed was historical - bad assumption given the page history of course.

As an outsider / new contributor, it isn't easy to see how to get patches 
noticed, and how different things should feed into the tree(s). For instance, 
is my patch being ignored because I forgot the Signed-off-by line, or is the 
maintainer away for a month? Or am I just not "in the club"?

It isn't even easy to figure out what trees there are (apart from the main one) 
and a google search for "qemu git" produces some misleading links to savannah 
and places other than git://git.qemu.org/qemu.git. It would also be useful if 
http://git.qemu.org/git/qemu.git/ and http://git.qemu.org/qemu.git worked 
again. Perhaps a list of main trees on the wiki or in MAINTAINERS might help? 
Even a list of obsolete trees might be useful.

It would probably also help if there was a little more documentation on the 
process bits (e.g. whether I need a public git tree, or mailing patches is 
always preferred, and maybe some links to better-practice git setups to ensure 
patches make it through OK) and about what is expected in terms of code 
quality and resubmission. It would also help to have some explanatory text for 
some of the architectural docs that are available (e.g. there is a lot of 
words on the wiki about QED, and I guess its some kind of storage / disk 
thing, but I have no idea why its important, or even if I should know about 
it).

I've tried to expand 
http://wiki.qemu.org/Documentation/GettingStartedDevelopers to cover my 
personal "a-ha" moments, but if I knew enough to write it all, then I'd 
probably be more interested in getting code written too...

I'm sorry I have more complaints than useful suggestions here. I can only say 
I'll hang around (mail / IRC) as long as I feel somewhat welcome and write up 
any insights you can offer.

Brad

Re: [Qemu-devel] KVM call agenda for April 05

[Stefan Hajnoczi]

On Tue, Apr 5, 2011 at 7:01 AM, Brad Hards <bradh@frogmouth.net> wrote:
> On Tue, 5 Apr 2011 05:59:27 am Anthony Liguori wrote:
>> - Trivial patch monkeys^Wteam -- this is an idea Stefan and I have been
>> kicking around to help some of the trivial patches get more attention on
>> the mailing list
> I saw a wiki page (http://wiki.qemu.org/Contribute/TrivialPatches) that I
> assumed was historical - bad assumption given the page history of course.
>
> As an outsider / new contributor, it isn't easy to see how to get patches
> noticed, and how different things should feed into the tree(s). For instance,
> is my patch being ignored because I forgot the Signed-off-by line, or is the
> maintainer away for a month? Or am I just not "in the club"?
>
> It isn't even easy to figure out what trees there are (apart from the main one)
> and a google search for "qemu git" produces some misleading links to savannah
> and places other than git://git.qemu.org/qemu.git. It would also be useful if
> http://git.qemu.org/git/qemu.git/ and http://git.qemu.org/qemu.git worked
> again. Perhaps a list of main trees on the wiki or in MAINTAINERS might help?
> Even a list of obsolete trees might be useful.
>
> It would probably also help if there was a little more documentation on the
> process bits (e.g. whether I need a public git tree, or mailing patches is
> always preferred, and maybe some links to better-practice git setups to ensure
> patches make it through OK) and about what is expected in terms of code
> quality and resubmission. It would also help to have some explanatory text for
> some of the architectural docs that are available (e.g. there is a lot of
> words on the wiki about QED, and I guess its some kind of storage / disk
> thing, but I have no idea why its important, or even if I should know about
> it).
>
> I've tried to expand
> http://wiki.qemu.org/Documentation/GettingStartedDevelopers to cover my
> personal "a-ha" moments, but if I knew enough to write it all, then I'd
> probably be more interested in getting code written too...
>
> I'm sorry I have more complaints than useful suggestions here. I can only say
> I'll hang around (mail / IRC) as long as I feel somewhat welcome and write up
> any insights you can offer.

I sounds like you've looked into the wiki a lot and have found the
information incomplete, confusing, or outdated.  The good news is that
QEMU development is very active, there is a healthy community with
both long term and first-time contributors.  We just need to
communicate a coherent and up-to-date picture so it is easier to join
the community.

The guide to submitting patches is here (you've probably already seen it):
http://wiki.qemu.org/Contribute/SubmitAPatch

Anthony: Could you please add "Contribute/SubmitAPatch|Submit a patch"
to http://wiki.qemu.org/MediaWiki:Sidebar?  By making the page easily
discoverable (like "Report a bug") it will be easier for people to
submit patches correctly.  I don't have permission to edit the
sidebar, it seems to be a special page :).

Brad: Are there specific points you'd like to see documented to which
you don't know the answer?  Maybe I can help.

Stefan

Re: [Qemu-devel] KVM call agenda for April 05

[Alexander Graf]

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


On 05.04.2011, at 08:01, Brad Hards wrote:

> On Tue, 5 Apr 2011 05:59:27 am Anthony Liguori wrote:
>> - Trivial patch monkeys^Wteam -- this is an idea Stefan and I have been
>> kicking around to help some of the trivial patches get more attention on
>> the mailing list
> I saw a wiki page (http://wiki.qemu.org/Contribute/TrivialPatches) that I 
> assumed was historical - bad assumption given the page history of course.

Hrm. I don't even know that page. Where is it linked? Maybe it should be linked on the http://wiki.qemu.org/Contribute/StartHere page?

> As an outsider / new contributor, it isn't easy to see how to get patches 
> noticed, and how different things should feed into the tree(s). For instance, 
> is my patch being ignored because I forgot the Signed-off-by line, or is the 
> maintainer away for a month? Or am I just not "in the club"?

That's sometimes even hard for people who have been working on Qemu for ages :). I'm not sure how to improve the situation. I as a maintainer usually ask other people to take over for me when I'm off on vacation, so contributers don't get exactly that feeling. But some parts of Qemu are just plain unmaintained, so nobody feels responsible.

> It isn't even easy to figure out what trees there are (apart from the main one) 
> and a google search for "qemu git" produces some misleading links to savannah 
> and places other than git://git.qemu.org/qemu.git. It would also be useful if 
> http://git.qemu.org/git/qemu.git/ and http://git.qemu.org/qemu.git worked 
> again. Perhaps a list of main trees on the wiki or in MAINTAINERS might help? 
> Even a list of obsolete trees might be useful.

Yes, please add that to the wiki :). I'd also like to see the savannah one just deactivated. Last time I checked it wasn't synced, so you simply get an old snapshot which is the worst case scenario for everyone.

> It would probably also help if there was a little more documentation on the 
> process bits (e.g. whether I need a public git tree, or mailing patches is 
> always preferred, and maybe some links to better-practice git setups to ensure 

You don't need a public git tree. But try to imagine you're a maintainer. Usually, those people just tend to have full-time jobs and look at patches along the way. If you send in a patch set of 20 patches, it's a lot easier for them to clone your tree to at least try out the patches than to apply them manually.

So rule of thumb is: As of 5 patches, creating a git tree helps getting your patches tested/reviewed.

I usually just push my work to repo.or.cz. They offer their services for free and are available almost every time I've needed them :).

> patches make it through OK) and about what is expected in terms of code 

What exactly do you mean by better-practice git setups?

> quality and resubmission. It would also help to have some explanatory text for 
> some of the architectural docs that are available (e.g. there is a lot of 
> words on the wiki about QED, and I guess its some kind of storage / disk 
> thing, but I have no idea why its important, or even if I should know about 
> it).

Take a look at http://wiki.qemu.org/Contribute/StartHere. It links to (rudimentary) explanations for QED. We don't have a full-on architectural doc though. And I'm not sure we ever will - unless people volunteer to write documentation instead of code :).

> I've tried to expand 
> http://wiki.qemu.org/Documentation/GettingStartedDevelopers to cover my 
> personal "a-ha" moments, but if I knew enough to write it all, then I'd 
> probably be more interested in getting code written too...

Ah, very nice! Thank you!

> I'm sorry I have more complaints than useful suggestions here. I can only say 
> I'll hang around (mail / IRC) as long as I feel somewhat welcome and write up 
> any insights you can offer.

You certainly welcome :). And thanks a lot for helping out on the wiki!


Alex


[-- Attachment #2: Type: text/html, Size: 5336 bytes --]

Re: [Qemu-devel] KVM call agenda for April 05

[Stefan Hajnoczi]

On Tue, Apr 5, 2011 at 9:29 AM, Alexander Graf <agraf@suse.de> wrote:
>
> On 05.04.2011, at 08:01, Brad Hards wrote:
>
> On Tue, 5 Apr 2011 05:59:27 am Anthony Liguori wrote:
>
> - Trivial patch monkeys^Wteam -- this is an idea Stefan and I have been
>
> kicking around to help some of the trivial patches get more attention on
>
> the mailing list
>
> I saw a wiki page (http://wiki.qemu.org/Contribute/TrivialPatches) that I
> assumed was historical - bad assumption given the page history of course.
>
> Hrm. I don't even know that page. Where is it linked? Maybe it should be
> linked on the http://wiki.qemu.org/Contribute/StartHere page?

It's the new page that Anthony wanted to discuss today, that's why it
hasn't been linked or announced yet.

Stefan

Re: [Qemu-devel] KVM call agenda for April 05

[Alon Levy]

On Mon, Apr 04, 2011 at 02:59:27PM -0500, Anthony Liguori wrote:
> On 04/04/2011 02:22 PM, Juan Quintela wrote:
> >Please, send in any agenda items you are interested in covering.
> 
> - KVM Forum -- do we have an ETA on CFP?
> 
> - Sub-maintainership -- how we can expand and improve upon it
> 
> - Trivial patch monkeys^Wteam -- this is an idea Stefan and I have
> been kicking around to help some of the trivial patches get more
> attention on the mailing list
> 
> - kvm-autotest -- I don't know if Lucas can join, but I'd like to
> get an update on what the future plans around kvm-autotest is and
> also have a discussion about what folks would like to see improved.

I'd like to join to hear that. Support for doing remote client tests
with kvm-autotest would be very interesting (i.e. spice).

> 
> Regards,
> 
> Anthony Liguori
> 
> >Later, Juan.
> >
> >
> 
> 

Re: [Qemu-devel] KVM call agenda for April 05

[Brad Hards]

On Tue, 5 Apr 2011 06:29:48 pm Alexander Graf wrote:
> What exactly do you mean by better-practice git setups?
Some projects try to use special features in git. For example, KDE makes use 
of insteadOf and pushInsteadOf to allow checking out from anongit, and 
committing to the main server using a pseudo-URL. 

Should I have some magic git hooks enabled? Automatic use of checker scripts 
or sign-off?

Is there some way to maintain those version change logs I need if I have to 
submit my patch v26?

Brad

Re: [Qemu-devel] KVM call agenda for April 05

[Alexander Graf]

On 05.04.2011, at 11:44, Brad Hards wrote:

> On Tue, 5 Apr 2011 06:29:48 pm Alexander Graf wrote:
>> What exactly do you mean by better-practice git setups?
> Some projects try to use special features in git. For example, KDE makes use 
> of insteadOf and pushInsteadOf to allow checking out from anongit, and 
> committing to the main server using a pseudo-URL. 

Oh? I guess there's always something new to discover with git :). Never heard of those features.

> Should I have some magic git hooks enabled? Automatic use of checker scripts 
> or sign-off?

We don't have any. That doesn't mean that you can't write any and provide them to others :). Signed-off-by is mandatory when sending patches, but I haven't seen a git hook used for that - I simply use commit -s :).

> Is there some way to maintain those version change logs I need if I have to 
> submit my patch v26?

I usually put "---" at the end of my patch description and then add a log on the changes between versions. On git am, the lines below --- just disappear, leaving the history for reviews, but not for the actual commit.


Alex

Re: [Qemu-devel] KVM call agenda for April 05

[Stefan Hajnoczi]

On Tue, Apr 5, 2011 at 10:44 AM, Brad Hards <bradh@frogmouth.net> wrote:
> On Tue, 5 Apr 2011 06:29:48 pm Alexander Graf wrote:
>> What exactly do you mean by better-practice git setups?
> Some projects try to use special features in git. For example, KDE makes use
> of insteadOf and pushInsteadOf to allow checking out from anongit, and
> committing to the main server using a pseudo-URL.
>
> Should I have some magic git hooks enabled? Automatic use of checker scripts
> or sign-off?

scripts/checkpatch.pl is mentioned in CODING_STYLE.  I have a git-hook
to automatically run it:
http://blog.vmsplice.net/2011/03/how-to-automatically-run-checkpatchpl.html

That hook is just a personal tool I use.  It is not required but we
could document it more prominently for people getting set up with QEMU
development.

Stefan

Re: [Qemu-devel] KVM call agenda for April 05

[Brad Hards]

On Tue, 5 Apr 2011 08:53:21 pm Stefan Hajnoczi wrote:
> scripts/checkpatch.pl is mentioned in CODING_STYLE.  I have a git-hook
> to automatically run it:
> http://blog.vmsplice.net/2011/03/how-to-automatically-run-checkpatchpl.html
> 
> That hook is just a personal tool I use.  It is not required but we
> could document it more prominently for people getting set up with QEMU
> development.
Thanks. Added to 
http://wiki.qemu.org/Documentation/GettingStartedDevelopers#Code
along with some other notes from this thread.

Brad

Re: [Qemu-devel] KVM call agenda for April 05

[Brad Hards]

On Tue, 5 Apr 2011 06:29:48 pm Alexander Graf wrote:
> > quality and resubmission. It would also help to have some explanatory
> > text for some of the architectural docs that are available (e.g. there
> > is a lot of words on the wiki about QED, and I guess its some kind of
> > storage / disk thing, but I have no idea why its important, or even if I
> > should know about it).
> 
> Take a look at http://wiki.qemu.org/Contribute/StartHere. It links to
> (rudimentary) explanations for QED. We don't have a full-on architectural
> doc though. And I'm not sure we ever will - unless people volunteer to
> write documentation instead of code :).
I take it you meant http://wiki.qemu.org/Features/QED (and the pages that link 
from there). I still don't know what QED does. I'm guessing something related 
to block devices (blocks get mentioned) and it is different to something called 
"raw", but I still don't know what QED does (or does differently / better than 
something else).

There is detail on why things are the way they are, but no context to help 
situate that detail.

The problem isn't with QED in particular. That is just an example of the issue 
- it could be applied equally to sheepdog, or VNC / Splice / SDL display, or 
some of the other things I don't even know that I don't know.

I personally found the qdev presentation style pretty approachable:
 - here is how it used to be...
 - that sucks for all the obvious reasons, and some you didn't think about...
 - here is how we do it now / should do it...
 - that sucks (less) for these reasons...
 - here is what you should do...

That isn't going to replace reading the code and copying examples. There 
should only be enough detail to tell people "you should know X and Y, and look 
here for more".

Brad

Re: [Qemu-devel] KVM call agenda for April 05

[Stefan Hajnoczi]

On Tue, Apr 5, 2011 at 1:21 PM, Brad Hards <bradh@frogmouth.net> wrote:
> On Tue, 5 Apr 2011 06:29:48 pm Alexander Graf wrote:
>> > quality and resubmission. It would also help to have some explanatory
>> > text for some of the architectural docs that are available (e.g. there
>> > is a lot of words on the wiki about QED, and I guess its some kind of
>> > storage / disk thing, but I have no idea why its important, or even if I
>> > should know about it).
>>
>> Take a look at http://wiki.qemu.org/Contribute/StartHere. It links to
>> (rudimentary) explanations for QED. We don't have a full-on architectural
>> doc though. And I'm not sure we ever will - unless people volunteer to
>> write documentation instead of code :).
> I take it you meant http://wiki.qemu.org/Features/QED (and the pages that link
> from there). I still don't know what QED does. I'm guessing something related
> to block devices (blocks get mentioned) and it is different to something called
> "raw", but I still don't know what QED does (or does differently / better than
> something else).

QED is an image format.  Like qcow2, vmdk, vpc, vdi, and others.

> There is detail on why things are the way they are, but no context to help
> situate that detail.
>
> The problem isn't with QED in particular. That is just an example of the issue
> - it could be applied equally to sheepdog, or VNC / Splice / SDL display, or
> some of the other things I don't even know that I don't know.
>
> I personally found the qdev presentation style pretty approachable:
>  - here is how it used to be...
>  - that sucks for all the obvious reasons, and some you didn't think about...
>  - here is how we do it now / should do it...
>  - that sucks (less) for these reasons...
>  - here is what you should do...
>
> That isn't going to replace reading the code and copying examples. There
> should only be enough detail to tell people "you should know X and Y, and look
> here for more".

This stems from the fact that development is centered around the
mailing list.  Some folks have put technical documentation on the wiki
but a lot simply happens on the mailing list.

Once the discussions have finished and code is merged the people
involved have that knowledge but I agree that it isn't easy for
newcomers to gain that knowledge.  Searching mailing list archives
should help you get that knowledge but it's more tedious than an
organized wiki.

I'm unsure how we can sustainably keep the wiki up-to-date on detailed
code internals knowledge.  Any suggestions, any examples of projects
doing this successfully?

Stefan

Re: [Qemu-devel] KVM call agenda for April 05

[Peter Maydell]

On 5 April 2011 14:14, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> This stems from the fact that development is centered around the
> mailing list.  Some folks have put technical documentation on the wiki
> but a lot simply happens on the mailing list.

> I'm unsure how we can sustainably keep the wiki up-to-date on detailed
> code internals knowledge.  Any suggestions, any examples of projects
> doing this successfully?

Another approach would be to try to increase the use of docs/
for technical code internals information. The advantage would be
that we could choose to require docs/ updates for design changes
in order for a code change to pass patch review; the disadvantage
would be that it's inevitably more of a pain to update.

-- PMM

Re: [Qemu-devel] KVM call agenda for April 05

[Anthony Liguori]

On 04/05/2011 03:25 PM, Peter Maydell wrote:
> On 5 April 2011 14:14, Stefan Hajnoczi<stefanha@gmail.com>  wrote:
>> This stems from the fact that development is centered around the
>> mailing list.  Some folks have put technical documentation on the wiki
>> but a lot simply happens on the mailing list.
>> I'm unsure how we can sustainably keep the wiki up-to-date on detailed
>> code internals knowledge.  Any suggestions, any examples of projects
>> doing this successfully?
> Another approach would be to try to increase the use of docs/
> for technical code internals information. The advantage would be
> that we could choose to require docs/ updates for design changes
> in order for a code change to pass patch review; the disadvantage
> would be that it's inevitably more of a pain to update.

We've been unofficially doing that for a lot of recent stuff.

I don't know that that really helps with the problem of keeping it up to 
date though.

Regards,

Anthony Liguori

> -- PMM
>

Re: [Qemu-devel] KVM call agenda for April 05

[Harsh Bora]

On 04/06/2011 02:00 AM, Anthony Liguori wrote:
> On 04/05/2011 03:25 PM, Peter Maydell wrote:
>> On 5 April 2011 14:14, Stefan Hajnoczi<stefanha@gmail.com> wrote:
>>> This stems from the fact that development is centered around the
>>> mailing list. Some folks have put technical documentation on the wiki
>>> but a lot simply happens on the mailing list.
>>> I'm unsure how we can sustainably keep the wiki up-to-date on detailed
>>> code internals knowledge. Any suggestions, any examples of projects
>>> doing this successfully?

Well, Libvirt community does follow the practice of requiring the patch 
submitter to provide enough documentation within docs/ folder or in the 
patch itself. The commiter ensures that the docs/ are updated with the 
patch desc if docs/ are not updated as a part of the patch.
See http://libvirt.org/hacking.html#patches

>> Another approach would be to try to increase the use of docs/
>> for technical code internals information. The advantage would be
>> that we could choose to require docs/ updates for design changes
>> in order for a code change to pass patch review; the disadvantage
>> would be that it's inevitably more of a pain to update.

Yes, Its better to have code and docs being updated together with the 
patches coming in, however, it will become more difficult to follow this 
practice if it is not followed regularly, for. eg, if patch A doesnt 
updates the docs as required, and a patch B which is based on Patch A 
wants to update docs, it needs to get the required docuemntation for 
patch A first before putting documentation for the patch B itself.

>
> We've been unofficially doing that for a lot of recent stuff.
>
> I don't know that that really helps with the problem of keeping it up to
> date though.

Well, as we have been doing it unofficially for recent stuff, it will be 
better to have it officially now :). It shall definitely help, as it 
gives an opportunity to even update an obsolete piece of info as 
compared to having no docs to update.
As they say, something is better than nothing !

regards,
Harsh

>
> Regards,
>
> Anthony Liguori
>
>> -- PMM
>>
>
>
>