[Qemu-devel] An organizational suggestion

[Qemu-devel] An organizational suggestion

[Balazs Attila-Mihaly (Cd-MaN)]

Hello all,

Since I've been subscribed to the list (a year or so), people have complained several times that patches did not get committed and they didn't know why. PostgreSQL (an open source database) currently uses a development process which I think the Qemu community could adopt and which could resolve these issues: every month they hold a so-called "commit-fest" when they, for a week, only work on committing patches. Now the exact time intervals are not important (it can be every three months a two week period for example), however in my opininion this would give a clear time-frame regarding the patches.

Of course if there is interest in adopting this kind of approach, some mechanism would be needed to manage the patch-queue (the patches which have not been committed yet) and I think that a closed Wiki (ie only members of the mailing list could edit it) would be a good tool. I would suggest Dokuwiki (http://wiki.splitbrain.org/wiki:dokuwiki) because it is written in PHP (which is available at almost all webhosts) and requires no database backend. If you (and specifically Farbric) are interested I would be happy to assist in installing (and maintaining) it, since I already manage a Dokuwiki installation at work.

Best regards



      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

Re: [Qemu-devel] An organizational suggestion

[Ian Jackson]

Balazs Attila-Mihaly \(Cd-MaN\) writes ("[Qemu-devel] An organizational suggestion"):
> Since I've been subscribed to the list (a year or so), people have
> complained several times that patches did not get committed and they
> didn't know why.

Of course in a Free Software project people tend to do the work that
they enjoy, and there's a risk that by cricising maintainers for not
taking patches we'll just make the work of dealing with patches less
enjoyable.

Since the current committers evidently don't have reviewing and
committing these patches as a high priority, I think a better approach
would be for the current team to ask for volunteers to help out with
that task, and then from the responses (of which I think there will
probably be enough) select one or two appropriate people as new
committers with the specific responsibility for reviewing, committing
and if necessary reworking patches.

>   PostgreSQL (an open source database) currently uses
> a development process which I think the Qemu community could adopt
> and which could resolve these issues: every month they hold a
> so-called "commit-fest" when they, for a week, only work on
> committing patches. Now the exact time intervals are not important
> (it can be every three months a two week period for example),
> however in my opininion this would give a clear time-frame regarding
> the patches.

I'm not sure that the Qemu project generally appreciates this kind of
very formally structured approach.  I'm sure it works fine for
PostgreSQL.

> Of course if there is interest in adopting this kind of approach,
> some mechanism would be needed to manage the patch-queue (the
> patches which have not been committed yet) and I think that a closed
> Wiki [...]

You're suggesting using a wiki as a patch tracking system.  I think an
issue tracker, with a rule to only submit patches and not just bug
reports or feature requests, would probably be much less pain.

Ian.

Re: [Qemu-devel] An organizational suggestion

[Jamie Lokier]

Ian Jackson wrote:
> Of course in a Free Software project people tend to do the work that
> they enjoy, and there's a risk that by cricising maintainers for not
> taking patches we'll just make the work of dealing with patches less
> enjoyable.

Perhaps they are simply too busy or doing other things.

>From MAINTAINERS:

x86                       Fabrice Bellard (new maintainer needed)
pc.c                      Fabrice Bellard (new maintainer needed)
Dynamic translator        Fabrice Bellard (new maintainer needed)
Main loop                 Fabrice Bellard (new maintainer needed)
IDE device                ?
PCI layer                 ?
USB layer                 ?
Block layer               ?
Graphic layer             ?
Character device layer    ?
Network device layer      ?
GDB stub                  ?
Linux user                ?
Darwin user               ?
SLIRP                     ?

To which I would add, from using it:

Documentation             ? (maintainer needed)
Built-in help             ? (maintainer needed)
Command-line / config     ? (maintainer needed)

Perhaps it's simply not enough people are paid to do this and
volunteers have other interests.  From what I've seen elsewhere, patch
tracking doesn't help much if there's nobody actively working on
integration and setting overall vision/direction.

Fabrice has indicated that there's room for a new maintainer (or
presumably more than one, if they cooperate).  It'll be interesting to
see if anyone steps forward, and if they can agree with Fabrice on
direction for the project.  If there are any companies out there
commercially dependent on QEMU and it's sister projects (KVM, Xen),
consider hiring for it.

I do suspect this project could now benefit from a more "open" style
of development - as in open to fresh ideas and more open discussion,
not just of specific patches.

-- Jamie

Re: [Qemu-devel] An organizational suggestion

[Ian Jackson]

Jamie Lokier writes ("Re: [Qemu-devel] An organizational suggestion"):
> Ian Jackson wrote:
> > Of course in a Free Software project people tend to do the work that
> > they enjoy, and there's a risk that by cricising maintainers for not
> > taking patches we'll just make the work of dealing with patches less
> > enjoyable.
> 
> Perhaps they are simply too busy or doing other things.

Indeed so.

> Perhaps it's simply not enough people are paid to do this and
> volunteers have other interests.  From what I've seen elsewhere, patch
> tracking doesn't help much if there's nobody actively working on
> integration and setting overall vision/direction.

Well, I'm certainly willing.  Perhaps I haven't made my availability
clear enough.

> Fabrice has indicated that there's room for a new maintainer (or
> presumably more than one, if they cooperate).  It'll be interesting to
> see if anyone steps forward, and if they can agree with Fabrice on
> direction for the project.  If there are any companies out there
> commercially dependent on QEMU and it's sister projects (KVM, Xen),
> consider hiring for it.

Xen (the whole ecosystem) is indeed very dependent on Qemu and the
divergence between our tree and the upstream one is far too great.
Many of our changes are entirely applicable to upstream.

I was hired by Xensource (now Citrix) specifically to work on the open
source Xen project.  I think one of the biggest tasks for that project
is trying to make some kind of sanity in our relationship (both code
and people) with Qemu upstream.  So we (specifically, I) have effort
available to help Qemu in general if this means that I can spend less
time trying to reconcile incompatible changes to our different
codebases.

Ian.

Re: [Qemu-devel] An organizational suggestion

[Jamie Lokier]

Ian Jackson wrote:
> > Perhaps it's simply not enough people are paid to do this and
> > volunteers have other interests.  From what I've seen elsewhere, patch
> > tracking doesn't help much if there's nobody actively working on
> > integration and setting overall vision/direction.
> 
> Well, I'm certainly willing.  Perhaps I haven't made my availability
> clear enough.

A private mail to Fabrice may be in order, if you're interested in
core maintenance.  Try to involve KVM folks too, that way lies sanity.

Given the commercial tension at present between Citrix (Xen) and
Qumranet (KVM) perhaps neither of you should be the sole primary
maintainer of core systems :-)

> Xen (the whole ecosystem) is indeed very dependent on Qemu and the
> divergence between our tree and the upstream one is far too great.
> Many of our changes are entirely applicable to upstream.

I agree, and the same applies to KVM's QEMU branch, but perhaps that
diverges less than Xen's.

> I was hired by Xensource (now Citrix) specifically to work on the open
> source Xen project.  I think one of the biggest tasks for that project
> is trying to make some kind of sanity in our relationship (both code
> and people) with Qemu upstream.  So we (specifically, I) have effort
> available to help Qemu in general if this means that I can spend less
> time trying to reconcile incompatible changes to our different
> codebases.

Good plan.  I suggest not just reducing code divergence, but
clarifying QEMU's future vision with Fabrice would help too.

-- Jamie

Re: [Qemu-devel] An organizational suggestion

[Ian Jackson]

Jamie Lokier writes ("Re: [Qemu-devel] An organizational suggestion"):
> A private mail to Fabrice may be in order, if you're interested in
> core maintenance.  Try to involve KVM folks too, that way lies sanity.

Quite.  I'll mail Fabrice - but generally I prefer to do things in
public where possible because it can avoid some political problems.

> Given the commercial tension at present between Citrix (Xen) and
> Qumranet (KVM) perhaps neither of you should be the sole primary
> maintainer of core systems :-)

I think it's important that we get a consensus about the architecture
and have a healthy approach to deciding what to do about technical
questions where we disagree.  I certainly wouldn't want to do anything
that didn't have reasonably broad support.  So I think that calls for
an open approach and open discussion.

I've generally found that it's quite possible for people whose
employers have in some sense competing interests, to work well
together improving code that they are all depending on.  I think
provided we can avoid trying to block each other's contributions out
of spite there shouldn't be a problem.

I think the most important thing for any new commiter is to have a
clear shared understanding of what kind of commits, and when, are
acceptable.

> Andreas Färber wrote:
> > Xen (the whole ecosystem) is indeed very dependent on Qemu and the
> > divergence between our tree and the upstream one is far too great.
> > Many of our changes are entirely applicable to upstream.
> 
> I agree, and the same applies to KVM's QEMU branch, but perhaps that
> diverges less than Xen's.

I've had a brief look at it but I haven't a clear idea of the amount
of divergence in the KVM branch.

> Good plan.  I suggest not just reducing code divergence, but
> clarifying QEMU's future vision with Fabrice would help too.

Yes.

Jan Kiszka writes ("[Qemu-devel] Re: An organizational suggestion"):
> Another remark: If potential new maintainers should be affiliated with
> any of the, to some degree, competing QEMU "accelerators" Xen and KVM, I
> would be happy to see a public agreement beforehand on the general
> architectural roadmap to cover those two requirement domains (+ the one
> of KQEMU) in the future QEMU design. It would be bad for this project if
> one side overrules the other via the (non-technical) preference of a
> maintainer. Really, that's nothing against Ian personally or against
> Xen/Citrix, the same would apply to KVM/Qumranet!

Oh, certainly I don't think I would want to be in that position.

I'm not sure we need an `architectural roadmap' agreed in advance; it
might be better to discuss individual architectural questions one at a
time.

We should probably start with some easy tasks - for example,
straightforward and uncontroversial improvements to the various device
models (of which we have some languishing in our Xen branch).

The Xen- and KVM-specific changes are more complicated but I think we
should be able to agree at the very least interfaces, hooks, or coding
conventions which allow our respective changes to become much less
intrustive.

Ian.

[Qemu-devel] Re: An organizational suggestion

[Jan Kiszka]

Ian Jackson wrote:
> Jan Kiszka writes ("[Qemu-devel] Re: An organizational suggestion"):
>> Another remark: If potential new maintainers should be affiliated with
>> any of the, to some degree, competing QEMU "accelerators" Xen and KVM, I
>> would be happy to see a public agreement beforehand on the general
>> architectural roadmap to cover those two requirement domains (+ the one
>> of KQEMU) in the future QEMU design. It would be bad for this project if
>> one side overrules the other via the (non-technical) preference of a
>> maintainer. Really, that's nothing against Ian personally or against
>> Xen/Citrix, the same would apply to KVM/Qumranet!
> 
> Oh, certainly I don't think I would want to be in that position.
> 
> I'm not sure we need an `architectural roadmap' agreed in advance; it
> might be better to discuss individual architectural questions one at a
> time.

I think we don't need this agreement-in-advance if the people who
finally decide about commits are neutral due to their affiliation or
have proven to be neutral despite of it, both politically as well as
technically - someone being deeply involved in one of both approaches
/may/ look biased at things, naturally.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] Re: An organizational suggestion

[Jamie Lokier]

Jan Kiszka wrote:
> I think we don't need this agreement-in-advance if the people who
> finally decide about commits are neutral due to their affiliation or
> have proven to be neutral despite of it, both politically as well as
> technically - someone being deeply involved in one of both approaches
> /may/ look biased at things, naturally.

As a user (not really a contributor), it looks like vague neutrality
is what we have now.  E.g. the command-line and (proposed) config file
are really messy, it looks like people try to do 'just technical'
patches to those because they might be accepted, rather than a
coherent design.  That's just an example, but a visible one.

But I'm probably not seeing a lot that goes on off-list.

I think the project would benefit from some more vision for it's next
step, so that _potential_ contributors (like me) have an idea what
it's worth looking it, and how best to ensure contributions are useful.

Right now, there are several bugs, improvements (if you agree :-) and
documentation I'm curious to look at, but I'm not going to waste my
time if I think it won't be used.  Writing notes on a disorganised
wiki does not count as worth my time.

I think encouraging more subsystem maintainers would be good.  I have
a problem with USB tablet at the moment - Windows Server 2003's driver
doesn't work with it - and no idea who to send to.  Bugs like that
reported to the list often don't get a response, but I'm sure someone
cares.  Assuming so, it suggests they might like to be a contact -
even if it's as specific as "USB tablet: <person>" so they don't have
to deal with much, just occasional rare feedback.

-- Jamie

Re: [Qemu-devel] An organizational suggestion

[Anthony Liguori]

Ian Jackson wrote:
> Jamie Lokier writes ("Re: [Qemu-devel] An organizational suggestion"):
>   
>> A private mail to Fabrice may be in order, if you're interested in
>> core maintenance.  Try to involve KVM folks too, that way lies sanity.
>>     
>
> Quite.  I'll mail Fabrice - but generally I prefer to do things in
> public where possible because it can avoid some political problems.
>   

I can't stress this enough so I'll say it again.  More committers isn't 
going to magically fix things.  We need more people reviewing patches.


>> I agree, and the same applies to KVM's QEMU branch, but perhaps that
>> diverges less than Xen's.
>>     
>
> I've had a brief look at it but I haven't a clear idea of the amount
> of divergence in the KVM branch.
>   

Xen is really a fundamental fork.  Quite a lot has been removed from the 
tree and there are some major architectural changes (like the map-cache, 
and the different save/restore formats).  KVM tries very hard to remain 
true to QEMU.  Patches that aren't directly related to KVM support are 
required to go to qemu-devel.  I think the one day, Xen could use an 
upstream QEMU for it's device model, but that's going to require 
significant changes in how Xen does things.

We have a fair bit of clean-up work to do in order to get things 
upstream but we'll get there.

There's nothing preventing the KVM changes from going into upstream QEMU 
AFAIK other than our lack of focus on doing that.  We're working on it 
though.

Regards,

Anthony Liguori

Re: [Qemu-devel] An organizational suggestion

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 908 bytes --]

Hi,

On Tue, 3 Jun 2008, Ian Jackson wrote:

> Jamie Lokier writes ("Re: [Qemu-devel] An organizational suggestion"):
> 
> > Perhaps it's simply not enough people are paid to do this and 
> > volunteers have other interests.  From what I've seen elsewhere, patch 
> > tracking doesn't help much if there's nobody actively working on 
> > integration and setting overall vision/direction.
> 
> Well, I'm certainly willing.  Perhaps I haven't made my availability 
> clear enough.

>From the commit messages on trunk and a summarizing shortlog of the 
committers, it is relatively easy to see that frequent contributors became 
committers, because they earned trust.

>From my short analysis, the most obvious candidates are:

     50 malc
     36 Robert Reif
     24 Hervé Poussineau
     21 Jan Kiszka
     16 Ralf Baechle
     15 Jason Wessel

(Obvious committers already removed from the list).

Hth,
Dscho

Re: [Qemu-devel] An organizational suggestion

[Ian Jackson]

Johannes Schindelin writes ("Re: [Qemu-devel] An organizational suggestion"):
> On Tue, 3 Jun 2008, Ian Jackson wrote:
> > Jamie Lokier writes ("Re: [Qemu-devel] An organizational suggestion"):
> > > Perhaps it's simply not enough people are paid to do this and 
> > > volunteers have other interests.  From what I've seen elsewhere, patch 
> > > tracking doesn't help much if there's nobody actively working on 
> > > integration and setting overall vision/direction.
> > 
> > Well, I'm certainly willing.  Perhaps I haven't made my availability 
> > clear enough.
> 
> From the commit messages on trunk and a summarizing shortlog of the 
> committers, it is relatively easy to see that frequent contributors became 
> committers, because they earned trust.
> 
> From my short analysis, the most obvious candidates are: [...]

It is obviously for the current team to decide who they trust, and I
won't be offended if that turns out not to be me.  I was offering -
because Jamie suggested that there was a lack of willing volunteers -
and certainly not demanding.

But I do think it is important that we have _some_ new committer(s)
who are keen to do the kind of routine patch review and inclusion,
which is sadly currently not getting the necessary prompt attention.

Ian.

Re: [Qemu-devel] An organizational suggestion

[Paul Brook]

> But I do think it is important that we have _some_ new committer(s)
> who are keen to do the kind of routine patch review and inclusion,
> which is sadly currently not getting the necessary prompt attention.

I'd just like to point out that committing patches is easy. The hard (and time 
consuming) bit is identifying, rejecting, fixing and/or making constructive 
comments on all the bogus patches. The are lots of patches that fall into 
this latter category, e.g. patches that have clearly only ever been tested on 
x86 targets. It doesn't take any special privileges to do this patch review.

Paul

Re: [Qemu-devel] An organizational suggestion

[Jamie Lokier]

Paul Brook wrote:
> I'd just like to point out that committing patches is easy. The hard
> (and time consuming) bit is identifying, rejecting, fixing and/or
> making constructive comments on all the bogus patches. The are lots
> of patches that fall into this latter category, e.g. patches that
> have clearly only ever been tested on x86 targets. It doesn't take
> any special privileges to do this patch review.

So true, very good point.

I don't see a lot of patches posted to this list though.  It seems
rather fewer than the number of commits.  Are these patches being sent
somewhere else instead?  Where should I send patches?

Cheers,
-- Jamie

Re: [Qemu-devel] An organizational suggestion

[Paul Brook]

> I don't see a lot of patches posted to this list though.  It seems
> rather fewer than the number of commits.  Are these patches being sent
> somewhere else instead?  Where should I send patches?

All patches should be sent to this list.
Patches committed without going with this list tend to be work done by the 
committers themselves. Personally I tend to just delete things that are sent 
to me directly without being sent to the list.

Paul

Re: [Qemu-devel] An organizational suggestion

[Jamie Lokier]

Paul Brook wrote:
> > I don't see a lot of patches posted to this list though.  It seems
> > rather fewer than the number of commits.  Are these patches being sent
> > somewhere else instead?  Where should I send patches?
> 
> All patches should be sent to this list.
> Patches committed without going with this list tend to be work done by the 
> committers themselves.

Ok.  Ian Jackson has found, patches to _some_ subsystems sent here
seem to be ignored by those able to commit them.  Even patches that
involved significant work and might be useful to many.

I don't think that's like it seems.  Every so often, there's a burst
of commits of reworked patches sent long earlier.  But it must be
confusing for the people sending patches here, and hard for them to
polish those patches, since they don't know if they should.

So how does one become a committer?

-- Jamie

(*) Or I noticed sometimes dismissed by a terse response.

Re: [Qemu-devel] An organizational suggestion

[Laurent Vivier]

Le mardi 03 juin 2008 à 15:35 +0100, Paul Brook a écrit :
> > But I do think it is important that we have _some_ new committer(s)
> > who are keen to do the kind of routine patch review and inclusion,
> > which is sadly currently not getting the necessary prompt attention.
> 
> I'd just like to point out that committing patches is easy. The hard (and time 
> consuming) bit is identifying, rejecting, fixing and/or making constructive 
> comments on all the bogus patches. The are lots of patches that fall into 
> this latter category, e.g. patches that have clearly only ever been tested on 
> x86 targets. It doesn't take any special privileges to do this patch review.

The real question is: who do you trust ?

Regards,
Laurent
-- 
------------- Laurent.Vivier@bull.net ---------------
"The best way to predict the future is to invent it."
- Alan Kay

Re: [Qemu-devel] An organizational suggestion

[Ian Jackson]

Paul Brook writes ("Re: [Qemu-devel] An organizational suggestion"):
> I'd just like to point out that committing patches is easy. The hard
> (and time consuming) bit is identifying, rejecting, fixing and/or
> making constructive comments on all the bogus patches. The are lots
> of patches that fall into this latter category, e.g. patches that
> have clearly only ever been tested on x86 targets.

Yes.

>  It doesn't take any special privileges to do this patch review.

That's true, but it doesn't tell the whole story.  Anyone can
criticise a patch (and we do).  But while review by a non-committer is
very helpful, it still doesn't mean that the committer doesn't have to
do review of their own.  After all the committer is actually the
gatekeeper and has the personal responsibility to commit good code.

Also, review and improvement of patches by non-committer contributors
depends on the contributors' expectation that patch will be accepted
when it is good.  There is no point in people reviewing and commenting
on and improving patches if the maintainers don't have the time or
inclination to get those refined patches actually reviewed by them and
committed.

As I've written earlier (in, for example, this message which never
even got a response despite being essentially a repost[1]) I've found
trying to contribute here it a very frustrating experience.  I've
submitted over the past months a number of patches to test the waters
and found that even with the best will it is extremely hard work to
get the attention necessary.

It is easy to get (largely constructive) critical comments on the
list, but when all of the problems are resolved and you think you have
consensus, you end up posting repeated begging messages saying
`please, is there something wrong with my patch, why aren't you
committing it?'.

This is very discouraging for people trying to contribute.  I imagine
it is also discouraging for the Qemu committer team because they are
constantly faced with these pleading nagging messages.

It also reduces the quality of the incoming patches, because it is not
worth spending a lot of effort double-checking and testing a
contribution if the likelihood is that it will be ignored for weeks or
months until it no longer applies cleanly.

Do you really think there isn't a problem ?  I see plenty of pleading
messages from other people but if I like their patch I'm powerless to
help.  I also see occasional outbursts of frustration, which obviously
happen even though people prefer not to complain.  After all,
complaining usually doesn't help because it just makes everyone
more demotivated.

Ian.

[1] http://lists.gnu.org/archive/html/qemu-devel/2008-05/msg00809.html

Re: [Qemu-devel] An organizational suggestion

[Jamie Lokier]

Ian Jackson wrote:
> for example, this message which never even got a response despite
> being essentially a repost[1]

It's the Linus Torvalds school of flow control.  If you don't get a
reply, try again.

-- Jamie

Re: [Qemu-devel] An organizational suggestion

[Ian Jackson]

Jamie Lokier writes ("Re: [Qemu-devel] An organizational suggestion"):
> It's the Linus Torvalds school of flow control.  If you don't get a
> reply, try again.

I see.  That seems rather rude to me, so I don't do it.  Am I really
supposed to keep a list of my outstanding patches and retransmit them
like some kind of bandwidth-hogging peer-to-peer application ?

If everyone did that, then the number of patches accepted would go
down rather than up, surely ?  Because everyone would be spending
their time wading through all these resends, rather than paying
attention to the content.

Also - implicit in your comment that it's a form of `flow control' is
that it's caused by a lack of upstream capacity.  I think that part is
very true.  We do have a lack of capacity, which can be solved in this
case by adding one or more people I think.

Qemu is not a very large project in the grand scheme of things, and we
can hopefully avoid the kind of very cumbersome and heavyweight
processes which surround the Linux kernel.

Ian.

Re: [Qemu-devel] An organizational suggestion

[Anthony Liguori]

Ian Jackson wrote:
> Jamie Lokier writes ("Re: [Qemu-devel] An organizational suggestion"):
>   
>> It's the Linus Torvalds school of flow control.  If you don't get a
>> reply, try again.
>>     
>
> I see.  That seems rather rude to me, so I don't do it.  Am I really
> supposed to keep a list of my outstanding patches and retransmit them
> like some kind of bandwidth-hogging peer-to-peer application ?
>   

The DCO process can really help here.  The simple fact is that most of 
the committers to QEMU are not paid to be full-time maintainers.  As 
such, their time is limited.  There is a lot of noise on qemu-devel 
(this thread being a good example ;-)).

If you review a patch, and are happy with it, offer an Acked-by.  When 
comitters go through reviewing patches to commit, it makes it much 
easier for them to determine whether a patch should be committed or not.

> If everyone did that, then the number of patches accepted would go
> down rather than up, surely ?  Because everyone would be spending
> their time wading through all these resends, rather than paying
> attention to the content.
>   

Try marking the subject with [RESEND].  Quite a lot of projects require 
patches to be resent.  In fact, in the early days of Xen, this was often 
the case.  [RESEND] tends to be a polite way to help maintainers be more 
responsive too.

> Also - implicit in your comment that it's a form of `flow control' is
> that it's caused by a lack of upstream capacity.  I think that part is
> very true.  We do have a lack of capacity, which can be solved in this
> case by adding one or more people I think.
>   

There are already a lot of committers in QEMU.  There are 9 people with 
commit access to QEMU.  There is only 1 person with commit access to KVM 
and that includes a full copy of QEMU.  What's needed is someone to take 
the time, on a day-by-day basis, to review patches, and queue them.

Magnus posted a list of outstanding patches a while ago, I think that's 
the right approach.  I'll spend some time today to try and collect 
outstanding patches.

Regards,

Anthony Liguori

> Qemu is not a very large project in the grand scheme of things, and we
> can hopefully avoid the kind of very cumbersome and heavyweight
> processes which surround the Linux kernel.
>
> Ian.
>
>
>   

Re: [Qemu-devel] An organizational suggestion

[Jamie Lokier]

Ian Jackson wrote:
> Jamie Lokier writes ("Re: [Qemu-devel] An organizational suggestion"):
> > It's the Linus Torvalds school of flow control.  If you don't get a
> > reply, try again.
> 
> I see.  That seems rather rude to me, so I don't do it.  Am I really
> supposed to keep a list of my outstanding patches and retransmit them
> like some kind of bandwidth-hogging peer-to-peer application ?

Exponential backoff - find the natural pace others can work at.  You
don't have to be a bandwidth hog :-)  But I was joking.  For the Linux
kernel, Linus has said that's what _he_ prefers, back in the days
before Git, but I don't know what's preferred here.

Some patches get a good response quickly, just look at recent threads.

I would guess it depends on which subsystem and whether it's in the
areas of interest of currently active developer-commiters.

> Also - implicit in your comment that it's a form of `flow control' is
> that it's caused by a lack of upstream capacity.  I think that part is
> very true.  We do have a lack of capacity, which can be solved in this
> case by adding one or more people I think.

Perhaps.  It's not necessarily easy to do that well.

-- Jamie

Re: [Qemu-devel] An organizational suggestion

[Laurent Vivier]

Le mardi 03 juin 2008 à 16:04 +0100, Ian Jackson a écrit :
[...]
> As I've written earlier (in, for example, this message which never
> even got a response despite being essentially a repost[1]) I've found
> trying to contribute here it a very frustrating experience.  I've
> submitted over the past months a number of patches to test the waters
> and found that even with the best will it is extremely hard work to
> get the attention necessary.
[...]

This kind of issue is inherent to every open-source project:

 http://lkml.org/lkml/2008/5/27/381

;-)

Regards,
Laurent
-- 
------------- Laurent.Vivier@bull.net ---------------
"The best way to predict the future is to invent it."
- Alan Kay

Re: [Qemu-devel] An organizational suggestion

[Anthony Liguori]

Ian Jackson wrote:
> Paul Brook writes ("Re: [Qemu-devel] An organizational suggestion"):
>   
>> I'd just like to point out that committing patches is easy. The hard
>> (and time consuming) bit is identifying, rejecting, fixing and/or
>> making constructive comments on all the bogus patches. The are lots
>> of patches that fall into this latter category, e.g. patches that
>> have clearly only ever been tested on x86 targets.
>>     
>
> Yes.
>
>   
>>  It doesn't take any special privileges to do this patch review.
>>     
>
> That's true, but it doesn't tell the whole story.  Anyone can
> criticise a patch (and we do).  But while review by a non-committer is
> very helpful, it still doesn't mean that the committer doesn't have to
> do review of their own.  After all the committer is actually the
> gatekeeper and has the personal responsibility to commit good code.
>
> Also, review and improvement of patches by non-committer contributors
> depends on the contributors' expectation that patch will be accepted
> when it is good.  There is no point in people reviewing and commenting
> on and improving patches if the maintainers don't have the time or
> inclination to get those refined patches actually reviewed by them and
> committed.
>   

Here's a couple things I notice that often cause a patch to be dropped:

1) It has something wrong, but not sufficiently interesting enough for 
anyone to offer feedback

2) It has something wrong, there's a thread with discussion and 
resubmissions of the patch, and the thread eventually cools off with a 
patch people are happy with

3) It's lost in the noise

#3 is something that happens.  A contributer has to resend patches to 
any project.  I don't think this happens very often on QEMU.

More often, I think the problem is #1.  This is something that we all 
can fix by just reviewing patches.  This has been an important issue for 
a while now and I'm willing to dedicate a portion of my time to 
reviewing patches.  For anyone submitting a patch to qemu-devel, feel 
free to CC me to make sure I review it.  I'm not saying that my review 
will guarantee acceptance, but I will keep track of patches I've reviewed.

#2 is a process problem.  It's unclear in this sort of thread, who's 
happy with the patch, and whether a conclusion has been reached.  The 
best thing to do is here to make use of Reviewed-by or Acked-by tags and 
to resubmit the patch as a top-level posting once consensus has been 
reached.

With a few more people dedicating time to patch review I think we can 
improve things quite a bit.

Regards,

Anthony Liguori

Re: [Qemu-devel] An organizational suggestion

[Anthony Liguori]

Ian Jackson wrote:
> Johannes Schindelin writes ("Re: [Qemu-devel] An organizational suggestion"):
>   
>> On Tue, 3 Jun 2008, Ian Jackson wrote:
>>     
>>> Jamie Lokier writes ("Re: [Qemu-devel] An organizational suggestion"):
>>>       
>>>> Perhaps it's simply not enough people are paid to do this and 
>>>> volunteers have other interests.  From what I've seen elsewhere, patch 
>>>> tracking doesn't help much if there's nobody actively working on 
>>>> integration and setting overall vision/direction.
>>>>         
>>> Well, I'm certainly willing.  Perhaps I haven't made my availability 
>>> clear enough.
>>>       
>> From the commit messages on trunk and a summarizing shortlog of the 
>> committers, it is relatively easy to see that frequent contributors became 
>> committers, because they earned trust.
>>
>> From my short analysis, the most obvious candidates are: [...]
>>     
>
> It is obviously for the current team to decide who they trust, and I
> won't be offended if that turns out not to be me.  I was offering -
> because Jamie suggested that there was a lack of willing volunteers -
> and certainly not demanding.
>
> But I do think it is important that we have _some_ new committer(s)
> who are keen to do the kind of routine patch review and inclusion,
> which is sadly currently not getting the necessary prompt attention.
>   

I just spent an hour or so going through patches from the last two 
weeks.  Quite a few have already been merged.  Of the dozen or so that 
weren't merged, I only counted 2 that were mergable in their current 
form, and they were both one liners.

More patch review is needed.  We can all help out here.  Go through 
patches and comment on them.  When you are satisfied and would apply 
them yourself, offer an Acked-by or Reviewed-by tag.  It'll become 
obvious to the current maintainers who has good taste and will also make 
it easier for them to commit patches.

The problem is definitely lack of patch review, not how quickly good 
patches are being committed.

Regards,

Anthony Liguori

> Ian.
>
>
>   

Re: [Qemu-devel] An organizational suggestion

[Andreas Färber]

Am 03.06.2008 um 12:00 schrieb Jamie Lokier:

> From what I've seen elsewhere, patch
> tracking doesn't help much if there's nobody actively working on
> integration and setting overall vision/direction.

The advantage of a patch tracking system such as Bugzilla would still  
be to make the list of unapplied patches more easily accessible  
(rather than searching list archives) and to allow clearly obsoleting  
patches with newer versions, as well as modelling dependencies.

Savannah has bug tracking capability - can't this be activated and  
emails directed to this list? Having that possibility would still  
allow submission via mailing list for immediate fixes or those who  
prefer.

Andreas

[Qemu-devel] Re: An organizational suggestion

[Jan Kiszka]

Andreas Färber wrote:
> 
> Am 03.06.2008 um 12:00 schrieb Jamie Lokier:
> 
>> From what I've seen elsewhere, patch
>> tracking doesn't help much if there's nobody actively working on
>> integration and setting overall vision/direction.
> 
> The advantage of a patch tracking system such as Bugzilla would still be
> to make the list of unapplied patches more easily accessible (rather
> than searching list archives) and to allow clearly obsoleting patches
> with newer versions, as well as modelling dependencies.
> 
> Savannah has bug tracking capability - can't this be activated and
> emails directed to this list? Having that possibility would still allow
> submission via mailing list for immediate fixes or those who prefer.

Would that tracker be able to pick up (via some CC?) review comments
that should likely continue to be sent to the list? However, this is
just a technical measure that may or may not improve some aspects. I
personally have no problems resending my patches after a while if they
were lost but are still relevant (patches bitrot quickly anyway). What
is more critical, IMHO, is that there are the resources (maintainer
time) to review and give concrete feedback on patches as long as they
are "fresh". Otherwise, a tracker will just shift the work around.

At this chance: I often see "silent merges" of patches, long after they
have been posted. Also in these cases, specifically but not only when
modifications were made to the original submission, I would appreciate a
short note to the patch submitter via the list. That gives direct, more
personal credits and, in case of modifications, can help to clarify what
should have been done differently.

Another remark: If potential new maintainers should be affiliated with
any of the, to some degree, competing QEMU "accelerators" Xen and KVM, I
would be happy to see a public agreement beforehand on the general
architectural roadmap to cover those two requirement domains (+ the one
of KQEMU) in the future QEMU design. It would be bad for this project if
one side overrules the other via the (non-technical) preference of a
maintainer. Really, that's nothing against Ian personally or against
Xen/Citrix, the same would apply to KVM/Qumranet!

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] Re: An organizational suggestion

[Ian Jackson]

Jan Kiszka writes ("[Qemu-devel] Re: An organizational suggestion"):
> What is more critical, IMHO, is that there are the resources
> (maintainer time) to review and give concrete feedback on patches as
> long as they are "fresh". Otherwise, a tracker will just shift the
> work around.

Quite.  I think that the key problem we have at the moment is lack of
maintainer time, not lack of appropriate tools.

> Another remark: If potential new maintainers should be affiliated with
> any of the, to some degree, competing QEMU "accelerators" Xen and KVM, I
> would be happy to see a public agreement beforehand on the general
> architectural roadmap to cover those two requirement domains (+ the one
> of KQEMU) in the future QEMU design. It would be bad for this project if
> one side overrules the other via the (non-technical) preference of a
> maintainer. Really, that's nothing against Ian personally or against
> Xen/Citrix, the same would apply to KVM/Qumranet!

I replied to this in my other message, but once again:  I think
actually that the Xen people and the KVM people will get on fine.

I'm certainly looking forward to seeing many more of the KVM changes
appearing as proposals and patches here, when we have an effective
system for getting such things discussed, reviewed, and committed.

Ian.

Re: [Qemu-devel] Re: An organizational suggestion

[Daniel P. Berrange]

On Tue, Jun 03, 2008 at 01:36:11PM +0100, Ian Jackson wrote:
> Jan Kiszka writes ("[Qemu-devel] Re: An organizational suggestion"):
> > What is more critical, IMHO, is that there are the resources
> > (maintainer time) to review and give concrete feedback on patches as
> > long as they are "fresh". Otherwise, a tracker will just shift the
> > work around.
> 
> Quite.  I think that the key problem we have at the moment is lack of
> maintainer time, not lack of appropriate tools.
> 
> > Another remark: If potential new maintainers should be affiliated with
> > any of the, to some degree, competing QEMU "accelerators" Xen and KVM, I
> > would be happy to see a public agreement beforehand on the general
> > architectural roadmap to cover those two requirement domains (+ the one
> > of KQEMU) in the future QEMU design. It would be bad for this project if
> > one side overrules the other via the (non-technical) preference of a
> > maintainer. Really, that's nothing against Ian personally or against
> > Xen/Citrix, the same would apply to KVM/Qumranet!
> 
> I replied to this in my other message, but once again:  I think
> actually that the Xen people and the KVM people will get on fine.

Alot of them are even the same people :-) Getting Xen and KVM more closely
following QEMU would be a huge benefit to everyone involved in all three
projects.

It is in no one's interests to maintain forked code long term - I feel the 
pain having to deal with security updates for Fedora - the last one needed
me to modify & release 9 different RPMs - 3 KVM, 3 QEMU and 3 Xen RPMs,
all with subtlely different versions of the code.


Daniel.
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] An organizational suggestion

[Balazs Attila-Mihaly (Cd-MaN)]

> Of course in a Free Software project people tend to do the work that
> they enjoy, and there's a risk that by cricising maintainers for not
> taking patches we'll just make the work of dealing with patches less
> enjoyable.

Let me be very clear: I really, really appreciate the work the comitters are doing and know that balancing a job, family and contributing to open source projects is very difficult. I'm not trying to say that they should do even more.

> Since the current committers evidently don't have reviewing and
> committing these patches as a high priority, I think a better approach
> would be for the current team to ask for volunteers to help out with
> that task, and then from the responses (of which I think there will
> probably be enough) select one or two appropriate people as new
> committers with the specific responsibility for reviewing, committing
> and if necessary reworking patches.

Great idea. However (imho) this means that some kind of description should be put together about the "accepted coding standard". I imagine that at the beginning this could be something very minimalistic (like "follow the identation style from the source you are modifying") and could evolve over time to include more complex issues (like what functions / headers you should / shouldn't use to have cross platform compilability, etc)

>   I'm not sure that the Qemu project generally appreciates this kind of
>   very formally structured approach.  I'm sure it works fine for
>   PostgreSQL.

I don't know it either, but hopefully we'll get some feedback. 

>   You're suggesting using a wiki as a patch tracking system.  I think an
>   issue tracker, with a rule to only submit patches and not just bug
>   reports or feature requests, would probably be much less pain.

Yes, an issue tracker would be great, however a wiki is more versatile (it could contain for example the "accepted coding standard" document I was talking about earlier).

I'm interested in peoples opinion about this matter. As mentioned earlier I would be glad to assis with setting up a wiki / issue tracker. An other thing I thought about doing (and would like to see if there is interest) is an automated testing infrastructure for Qemu (which takes checkins from SVN and does different tests with it, like compiling with different compilers, performance tests, etc) since it seems to me that regression testing is an other no-so-strong point of Qemu.

Best regards.



      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

Re: [Qemu-devel] An organizational suggestion

[Balazs Attila-Mihaly (Cd-MaN)]

> I'd just like to point out that committing patches is easy. The hard (and time 
> consuming) bit is identifying, rejecting, fixing and/or making constructive 
> comments on all the bogus patches. The are lots of patches that fall into 
> this latter category, e.g. patches that have clearly only ever been tested on 
> x86 targets.

I agree 100%. However I would like to point out that not all people have (easy) access to other architectures. This could be resolved partially by an automated testing framework (as I mentioned earlier) and/or (preferably and) by a central repository of "do's" and "dont's" (on a wiki for example :-). I want to be very clear: my (and hopefully everybodys) intention with this discussion is to find an acceptable solution, not to play politics or something like that. I'm very grateful to all of the developers, because without them, we wouldn't be here. But it is always good (in my opinion at least) to aim high.

To make the discussion more focused, I propose that we come up with a list of yes/no questions and committers (especially Fabrice) express their opinion and we'll see what solutions are acceptable. What I've seen so far:

- Should patches be tracked (via an issue tracker, wiki or some other solution)?
- Should there exists a document describing "do's" and "dont's" for Qemu source code?
- Would an automated testing framework be useful?

Please list your own questions (yes/no to keep it simple) and after we have a somewhat comprehensive list, we can ask the committers to respond to them to see which is a workable alternative...

Best regards.


      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

Re: [Qemu-devel] An organizational suggestion

[Andreas Färber]

Am 03.06.2008 um 17:36 schrieb Balazs Attila-Mihaly (Cd-MaN):

>> I'd just like to point out that committing patches is easy. The  
>> hard (and time
>> consuming) bit is identifying, rejecting, fixing and/or making  
>> constructive
>> comments on all the bogus patches. The are lots of patches that  
>> fall into
>> this latter category, e.g. patches that have clearly only ever been  
>> tested on
>> x86 targets.
>
> I agree 100%. However I would like to point out that not all people  
> have (easy) access to other architectures. This could be resolved  
> partially by an automated testing framework (as I mentioned earlier)  
> and/or (preferably and) by a central repository of "do's" and  
> "dont's" (on a wiki for example :-).

> To make the discussion more focused, I propose that we come up with  
> a list of yes/no questions and committers (especially Fabrice)  
> express their opinion and we'll see what solutions are acceptable.  
> What I've seen so far:
>
> - Should patches be tracked (via an issue tracker, wiki or some  
> other solution)?
> - Should there exists a document describing "do's" and "dont's" for  
> Qemu source code?
> - Would an automated testing framework be useful?
>
> Please list your own questions (yes/no to keep it simple)

I don't think yes/no is helpful here.

Obviously patches need to be tracked, the question is not yes/no but  
how. "[PATCH]" in the subject has been one strategy to aid the  
maintainers in tracking them.

A document with contributor information might be a good idea. Whether  
this needs to be an external resource such as a Wiki is another  
question. A simple "CONTRIBUTING" text file in SVN trunk could do.(*)  
After all, it's the maintainers who decide, and it's the simplest way  
to diffuse the info into working copies and mirrors.

An automated testing framework is always useful, yes. Questions are  
who writes it, where does it run and what does it do. There are a  
couple of tests in the tests/ directory, but they do not seem portable  
(they don't compile on OSX/i386). Furthermore, some patches discussed  
recently were about theoretical situations that cannot easily be tested.

(*) Among the info that I would find useful is more transparency on  
whether there is a certain "objection time" before patches get  
committed, leading to said batch commits at unexpected times. Also  
some other events came surprising, such as the 0.9.1 release - other  
projects follow a procedure of branching and issuing a call for  
testing, or at least giving an advance notice for pending patches to  
be applied.

Andreas