Planning for the 0.11.0 release

Planning for the 0.11.0 release

[Anthony Liguori]

Hi,

It's getting to be about the time to start thinking about the 0.11.0 
release.  0.10.0 was released on March 2nd so following with the 6 month 
release cycle, that would put 0.11.0 at September 2nd.

Based on the experiences with the stable releases, here's what I'd 
recommend:

 o On July 15th, fork master -> stable-0.11
 o Change version to 0.10.90
 o Release qemu-0.11.0-rc1
 o Release additional -rcN releases every 1-2 weeks
 o Introduce a new maintainer for stable-0.10 (via git pulls)
 o At least 1 week before release, hopefully we'll have the final -rcN 
that we can then declare 0.11.0.

I think we should really try hard to make these dates.  I only have a 
few things that I would like to see happen before forking stable-0.11.  
Namely:

 o Setup qemu.org infrastructure (git hosting, wiki)
 o Setup qemu bug tracker (see next mail)
 o Include all ROM source code in tree via git submodules.  This is a 
major headache for distributors and I think it's important to resolve 
before our next release.
 o Disable kqemu by default.  The intention is _not_ to remove kqemu 
support.  Enabling kqemu by default causes a few unpleasant side effects 
including errors if -m is greater than 1/2 of the host physical memory.

I don't expect the qdev conversion will be complete by 0.11.  I think we 
should try to get as much of the invasive changes as possible in to make 
stable-0.11 as maintainable as possible.  However, I think it would be a 
mistake to gate the release on qdev.

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] Planning for the 0.11.0 release

[Avi Kivity]

On 06/23/2009 02:57 AM, Anthony Liguori wrote:
> Hi,
>
> It's getting to be about the time to start thinking about the 0.11.0 
> release.  0.10.0 was released on March 2nd so following with the 6 
> month release cycle, that would put 0.11.0 at September 2nd.
>
> Based on the experiences with the stable releases, here's what I'd 
> recommend:
>

Seems sane to me.

> o Release qemu-0.11.0-rc1
> o Release additional -rcN releases every 1-2 weeks

I'll release qemu-kvm-0.11.0-rc* in parallel so we can get feedback from 
kvm users as well.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Planning for the 0.11.0 release

[Blue Swirl]

On 6/23/09, Anthony Liguori <aliguori@us.ibm.com> wrote:
> Hi,
>
>  It's getting to be about the time to start thinking about the 0.11.0
> release.  0.10.0 was released on March 2nd so following with the 6 month
> release cycle, that would put 0.11.0 at September 2nd.
>
>  Based on the experiences with the stable releases, here's what I'd
> recommend:
>
>  o On July 15th, fork master -> stable-0.11
>  o Change version to 0.10.90
>  o Release qemu-0.11.0-rc1
>  o Release additional -rcN releases every 1-2 weeks
>  o Introduce a new maintainer for stable-0.10 (via git pulls)
>  o At least 1 week before release, hopefully we'll have the final -rcN that
> we can then declare 0.11.0.

Sounds OK. I think OpenBIOS releases should follow similar schedule,
maybe even with matching SVN tags (1.1-rc1 for 0.11.0-rc1 etc).

>  I think we should really try hard to make these dates.  I only have a few
> things that I would like to see happen before forking stable-0.11.  Namely:
>
>  o Setup qemu.org infrastructure (git hosting, wiki)
>  o Setup qemu bug tracker (see next mail)
>  o Include all ROM source code in tree via git submodules.  This is a major
> headache for distributors and I think it's important to resolve before our
> next release.

I think this is great, but OpenBIOS still uses Subversion. Can git use
SVN submodules for example?

Re: [Qemu-devel] Planning for the 0.11.0 release

[Anthony Liguori]

Blue Swirl wrote:
> On 6/23/09, Anthony Liguori <aliguori@us.ibm.com> wrote:
>   
>> Hi,
>>
>>  It's getting to be about the time to start thinking about the 0.11.0
>> release.  0.10.0 was released on March 2nd so following with the 6 month
>> release cycle, that would put 0.11.0 at September 2nd.
>>
>>  Based on the experiences with the stable releases, here's what I'd
>> recommend:
>>
>>  o On July 15th, fork master -> stable-0.11
>>  o Change version to 0.10.90
>>  o Release qemu-0.11.0-rc1
>>  o Release additional -rcN releases every 1-2 weeks
>>  o Introduce a new maintainer for stable-0.10 (via git pulls)
>>  o At least 1 week before release, hopefully we'll have the final -rcN that
>> we can then declare 0.11.0.
>>     
>
> Sounds OK. I think OpenBIOS releases should follow similar schedule,
> maybe even with matching SVN tags (1.1-rc1 for 0.11.0-rc1 etc).
>
>   
>>  I think we should really try hard to make these dates.  I only have a few
>> things that I would like to see happen before forking stable-0.11.  Namely:
>>
>>  o Setup qemu.org infrastructure (git hosting, wiki)
>>  o Setup qemu bug tracker (see next mail)
>>  o Include all ROM source code in tree via git submodules.  This is a major
>> headache for distributors and I think it's important to resolve before our
>> next release.
>>     
>
> I think this is great, but OpenBIOS still uses Subversion. Can git use
> SVN submodules for example?
>   
No, but it's not too hard to make svn->git bridges.

Regards,

Anthony Liguori


-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] Planning for the 0.11.0 release

[Avi Kivity]

On 06/23/2009 06:09 PM, Blue Swirl wrote:
> I think this is great, but OpenBIOS still uses Subversion. Can git use
> SVN submodules for example?
>    

No, but we could have a git svn mirror and include that.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Planning for the 0.11.0 release

[Mark McLoughlin]

Hi Anthony,

On Mon, 2009-06-22 at 18:57 -0500, Anthony Liguori wrote:
> Hi,
> 
> It's getting to be about the time to start thinking about the 0.11.0 
> release.  0.10.0 was released on March 2nd so following with the 6 month 
> release cycle, that would put 0.11.0 at September 2nd.
> 
> Based on the experiences with the stable releases, here's what I'd 
> recommend:
> 
>  o On July 15th, fork master -> stable-0.11

Are you still planning on creating the 0.11 branch next week?

Cheers,
Mark.

Re: [Qemu-devel] Planning for the 0.11.0 release

[Anthony Liguori]

Mark McLoughlin wrote:
> Hi Anthony,
>
> On Mon, 2009-06-22 at 18:57 -0500, Anthony Liguori wrote:
>   
>> Hi,
>>
>> It's getting to be about the time to start thinking about the 0.11.0 
>> release.  0.10.0 was released on March 2nd so following with the 6 month 
>> release cycle, that would put 0.11.0 at September 2nd.
>>
>> Based on the experiences with the stable releases, here's what I'd 
>> recommend:
>>
>>  o On July 15th, fork master -> stable-0.11
>>     
>
> Are you still planning on creating the 0.11 branch next week?
>   

That's the plan although I need to make sure that all outstanding 
patches have been given adequate review before hand.  I want to give any 
patch that has been posted so far a reasonable chance to make it into 
0.11.  If I can get through the backlog today, then we'll stay on 
schedule.  Either way, there will be plenty of warning on the ML and 
opportunity for people to make suggestions.

Regards,

Anthony Liguori

> Cheers,
> Mark.
>
> --
> 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] Planning for the 0.11.0 release

[Markus Armbruster]

Anthony Liguori <anthony@codemonkey.ws> writes:

> Mark McLoughlin wrote:
>> Hi Anthony,
>>
>> On Mon, 2009-06-22 at 18:57 -0500, Anthony Liguori wrote:
>>   
>>> Hi,
>>>
>>> It's getting to be about the time to start thinking about the
>>> 0.11.0 release.  0.10.0 was released on March 2nd so following with
>>> the 6 month release cycle, that would put 0.11.0 at September 2nd.
>>>
>>> Based on the experiences with the stable releases, here's what I'd
>>> recommend:
>>>
>>>  o On July 15th, fork master -> stable-0.11
>>>     
>>
>> Are you still planning on creating the 0.11 branch next week?
>>   
>
> That's the plan although I need to make sure that all outstanding
> patches have been given adequate review before hand.  I want to give
> any patch that has been posted so far a reasonable chance to make it
> into 0.11.  If I can get through the backlog today, then we'll stay on
> schedule.  Either way, there will be plenty of warning on the ML and
> opportunity for people to make suggestions.
>
> Regards,
>
> Anthony Liguori

Any hope that -device can make the cut?

Re: [Qemu-devel] Planning for the 0.11.0 release

[Anthony Liguori]

Markus Armbruster wrote:
> Anthony Liguori <anthony@codemonkey.ws> writes:
>
> Any hope that -device can make the cut?
>   
I've got most of the outstanding patches in staging now.  The only thing 
missing is the PIIX refactoring from Isaku which I suspect is going to 
fuzz badly.  -device is there.

I'll be testing this today and I'll try to push it tomorrow.

I'm going to delay the 0.10.6 release to coincide with 0.11.0-rc1.  I 
think we're on track for 0.11.0-rc1 for next Wednesday.

Taking a look over staging would be helpful for anyone interested.

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] Planning for the 0.11.0 release

[Jan Kiszka]

Anthony Liguori wrote:
> Markus Armbruster wrote:
>> Anthony Liguori <anthony@codemonkey.ws> writes:
>>
>> Any hope that -device can make the cut?
>>   
> I've got most of the outstanding patches in staging now.  The only thing
> missing is the PIIX refactoring from Isaku which I suspect is going to
> fuzz badly.  -device is there.
> 
> I'll be testing this today and I'll try to push it tomorrow.
> 
> I'm going to delay the 0.10.6 release to coincide with 0.11.0-rc1.  I
> think we're on track for 0.11.0-rc1 for next Wednesday.
> 
> Taking a look over staging would be helpful for anyone interested.

Hmm, I must have missed this: Where is your staging tree hosted?

Jan

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

Re: [Qemu-devel] Planning for the 0.11.0 release

[Anthony Liguori]

Jan Kiszka wrote:
> Hmm, I must have missed this: Where is your staging tree hosted?
>   

Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan 
to move it to git.qemu.org in the next few days.

Regards,

Anthony Liguori

Re: [Qemu-devel] Planning for the 0.11.0 release

[Jan Kiszka]

Anthony Liguori wrote:
> Jan Kiszka wrote:
>> Hmm, I must have missed this: Where is your staging tree hosted?
>>   
> 
> Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan
> to move it to git.qemu.org in the next few days.

Ah, thanks.

OK, then I would like to know the status of my -boot patch queue [1] and
at least of patch 1..3 of my gdbstub queue [2] (though I'm still waiting
for the factual proof that patch 4 is unneeded - my last arguments
remained unanswered).

Jan

[1] http://thread.gmane.org/gmane.comp.emulators.qemu/46703
[2] http://thread.gmane.org/gmane.comp.emulators.qemu/46314

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

Re: [Qemu-devel] Planning for the 0.11.0 release

[Anthony Liguori]

Jan Kiszka wrote:
> Ah, thanks.
>
> OK, then I would like to know the status of my -boot patch queue [1]

I'm stilling waiting for 1/7 and 2/7.  Via the link you posted and in my 
inbox, I still don't see those.  I do see a 1/2 and a 2/2 but those are 
bios patches.  Did you have a numbering issue or did some patches get 
lost in the ether?

>  and
> at least of patch 1..3 of my gdbstub queue [2] (though I'm still waiting
> for the factual proof that patch 4 is unneeded - my last arguments
> remained unanswered).
>   

Paul expressed objection in the past to the debugging model of treating 
vcpus as threads vs. treating them as processes.  I'm not qualified to 
appreciate the difference so I'm inclined to side with Paul.  Am I 
missing something there?

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] Planning for the 0.11.0 release

[Jan Kiszka]

Anthony Liguori wrote:
> Jan Kiszka wrote:
>> Ah, thanks.
>>
>> OK, then I would like to know the status of my -boot patch queue [1]
> 
> I'm stilling waiting for 1/7 and 2/7.  Via the link you posted and in my
> inbox, I still don't see those.  I do see a 1/2 and a 2/2 but those are
> bios patches.  Did you have a numbering issue or did some patches get
> lost in the ether?

Something went wrong during transmission, and I missed that. Just sent
out those two as well.

> 
>>  and
>> at least of patch 1..3 of my gdbstub queue [2] (though I'm still waiting
>> for the factual proof that patch 4 is unneeded - my last arguments
>> remained unanswered).
>>   
> 
> Paul expressed objection in the past to the debugging model of treating
> vcpus as threads vs. treating them as processes.

That's nothing those patches changes (it's our current and only
debugging model for SMP until gdb provides a complete solution).

The recent discussion went around how to deal with some other gdb
limitation: debugging targets that run in x86's 16/32 bit mode vs. the
target arch being advertised as 64 bit. Existing qemu code doesn't work
with existing gdb in this scenario, and the question was how to deal
with it until gdb is improved.

>  I'm not qualified to
> appreciate the difference so I'm inclined to side with Paul.  Am I
> missing something there?

I interpreted [1] as that the rest is OK for Paul.

Jan

[1] http://permalink.gmane.org/gmane.comp.emulators.qemu/46399

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

Re: [Qemu-devel] Planning for the 0.11.0 release

[Anthony Liguori]

Jan Kiszka wrote:
> Something went wrong during transmission, and I missed that. Just sent
> out those two as well.
>   

Thanks, it's now all in staging.

> That's nothing those patches changes (it's our current and only
> debugging model for SMP until gdb provides a complete solution).
>   

It Paul agrees, I'll pull it.  But my understanding from the previous 
threads and posts was that Paul did not want to implement vCont even as 
a stop-gap and that he preferred to fix gdb properly.

> The recent discussion went around how to deal with some other gdb
> limitation: debugging targets that run in x86's 16/32 bit mode vs. the
> target arch being advertised as 64 bit. Existing qemu code doesn't work
> with existing gdb in this scenario, and the question was how to deal
> with it until gdb is improved.
>   

Right, that part I'm okay with.  But the vCont based gdb model presumes 
a unified address space which while usually true for kernel address 
spaces, isn't universally true and certainly not true when PC is in 
userspace.  That's what I understood to be the major objection to vCont.

>>  I'm not qualified to
>> appreciate the difference so I'm inclined to side with Paul.  Am I
>> missing something there?
>>     
>
> I interpreted [1] as that the rest is OK for Paul.
>   

Paul, can you clarify?

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] Planning for the 0.11.0 release

[Jan Kiszka]

Anthony Liguori wrote:
> Jan Kiszka wrote:
>> That's nothing those patches changes (it's our current and only
>> debugging model for SMP until gdb provides a complete solution).
>>   
> 
> It Paul agrees, I'll pull it.  But my understanding from the previous
> threads and posts was that Paul did not want to implement vCont even as
> a stop-gap and that he preferred to fix gdb properly.

We also need vCont for proper thread debugging in user mode emulation.

Jan

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

Re: [Qemu-devel] Planning for the 0.11.0 release

[Paul Brook]

> Right, that part I'm okay with.  But the vCont based gdb model presumes
> a unified address space which while usually true for kernel address
> spaces, isn't universally true and certainly not true when PC is in
> userspace.  That's what I understood to be the major objection to vCont.

The thread bits are the wrong way to do things, but are probably relatively 
harmless for now. Expect me to remove them at the first available opportunity.

The 32/64-bit switching is just plain wrong, and makes it absolutely 
impossible for a client debugger to work correctly.
If you really can't be bothered fixing gdb (and you *really* should), then it 
should be some form of user switch that tells qemu to always report a 32-bit 
register set.

Paul

Re: [Qemu-devel] Planning for the 0.11.0 release

[Anthony Liguori]

Paul Brook wrote:
>> Right, that part I'm okay with.  But the vCont based gdb model presumes
>> a unified address space which while usually true for kernel address
>> spaces, isn't universally true and certainly not true when PC is in
>> userspace.  That's what I understood to be the major objection to vCont.
>>     
>
> The thread bits are the wrong way to do things, but are probably relatively 
> harmless for now. Expect me to remove them at the first available opportunity.
>   

I'll queue 1-3 then and we'll leave 4 for post-0.11 debate.

Regards,

Anthony Liguori

Re: [Qemu-devel] Planning for the 0.11.0 release

[Jan Kiszka]

Paul Brook wrote:
> The 32/64-bit switching is just plain wrong, and makes it absolutely 
> impossible for a client debugger to work correctly.

As pointed out before, it doesn't break anything but adds a workaround
for scenarios which are _now_ broken (16/32 bit target code exported as
64 bit is widely useless for gdb today). Sorry, but you never explained
to me how user are _currently_ supposed to debug under that conditions,
namely 16/32 bit code executed by qemu-system-x86_64.

> If you really can't be bothered fixing gdb (and you *really* should), then it 

I do bother, but it's nothing for a long rainy afternoon.

> should be some form of user switch that tells qemu to always report a 32-bit 
> register set.

I could offer to add a monitor command so that one can additionally
set/override the register representation during runtime that way. I do
not see a use case for it based on all the scenarios I'm aware of or
personally ran through the last year, but if it helps acceptance.
However, only a command line switch locking down the mode would solve
just half of the real-world problems.

Jan

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

Re: [Qemu-devel] Planning for the 0.11.0 release

[Paul Brook]

> As pointed out before, it doesn't break anything but adds a workaround
> for scenarios which are _now_ broken (16/32 bit target code exported as
> 64 bit is widely useless for gdb today). Sorry, but you never explained
> to me how user are _currently_ supposed to debug under that conditions,
> namely 16/32 bit code executed by qemu-system-x86_64.

You're working around a gdb bug it in a way that means a fixed gdb can't 
possibly work.  IMO the cure is worse than the disease.  Changing the register 
set reported to gdb part way through a session will always break. There's no 
possible way for gdb to what state the target is going to be in until it 
actually queries it.

Paul

Re: [Qemu-devel] Planning for the 0.11.0 release

[Kevin Wolf]

Anthony Liguori schrieb:
> Jan Kiszka wrote:
>> Hmm, I must have missed this: Where is your staging tree hosted?
>>   
> 
> Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan 
> to move it to git.qemu.org in the next few days.

If I'm not mistaken, the patch "qemu-io: Implement
bdrv_get_buffer/bdrv_put_buffer" is missing from the queue.

Kevin

Re: [Qemu-devel] Planning for the 0.11.0 release

[Anthony Liguori]

Kevin Wolf wrote:
> Anthony Liguori schrieb:
>   
>> Jan Kiszka wrote:
>>     
>>> Hmm, I must have missed this: Where is your staging tree hosted?
>>>   
>>>       
>> Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan 
>> to move it to git.qemu.org in the next few days.
>>     
>
> If I'm not mistaken, the patch "qemu-io: Implement
> bdrv_get_buffer/bdrv_put_buffer" is missing from the queue.
>   

I just did a pull a few hours ago from Christoph's qemu-io tree.  I'm 
expecting qemu-io patches to go through his tree.

Regards,

Anthony Liguori

Re: [Qemu-devel] Planning for the 0.11.0 release

[Kevin Wolf]

Anthony Liguori schrieb:
> Kevin Wolf wrote:
>> Anthony Liguori schrieb:
>>   
>>> Jan Kiszka wrote:
>>>     
>>>> Hmm, I must have missed this: Where is your staging tree hosted?
>>>>   
>>>>       
>>> Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan 
>>> to move it to git.qemu.org in the next few days.
>>>     
>> If I'm not mistaken, the patch "qemu-io: Implement
>> bdrv_get_buffer/bdrv_put_buffer" is missing from the queue.
>>   
> 
> I just did a pull a few hours ago from Christoph's qemu-io tree.  I'm 
> expecting qemu-io patches to go through his tree.

Last time you said you don't want to get pull requests but rather
patches on the list.

Christoph, would you be so kind to push the patch to your queue and fill
the pull request form for Anthony in three copies, signed and with
official stamp...?

Kevin

Re: [Qemu-devel] Planning for the 0.11.0 release

[Anthony Liguori]

Kevin Wolf wrote:
> Last time you said you don't want to get pull requests but rather
> patches on the list.
>   
I'm clearly trying to purposefully confuse you :-)

Honestly, I'm just trying to work with people.  I saw the pull request, 
so I pulled it.  I would have been just as happy pulling in the patches 
from the mailing list.

> Christoph, would you be so kind to push the patch to your queue and fill
> the pull request form for Anthony in three copies, signed and with
> official stamp...?
>   

Don't forget to get it notarized after committee approval.

Regards,

Anthony Liguori

> Kevin
>   

Re: [Qemu-devel] Planning for the 0.11.0 release

[Christoph Hellwig]

On Fri, Jul 10, 2009 at 11:59:25AM -0500, Anthony Liguori wrote:
> >If I'm not mistaken, the patch "qemu-io: Implement
> >bdrv_get_buffer/bdrv_put_buffer" is missing from the queue.
> >  
> 
> I just did a pull a few hours ago from Christoph's qemu-io tree.  I'm 
> expecting qemu-io patches to go through his tree.

I hold that patch back for now as it will need a bit of work if
the ->bdrv_{get,put}_buffer renaming patch goes in.  Just looking at
the queue Anthony only has queued up the older non-renaming version.

Anthony was this an accident or do you dislike the renaming?

Re: [Qemu-devel] Planning for the 0.11.0 release

[Kevin Wolf]

Christoph Hellwig schrieb:
> On Fri, Jul 10, 2009 at 11:59:25AM -0500, Anthony Liguori wrote:
>>> If I'm not mistaken, the patch "qemu-io: Implement
>>> bdrv_get_buffer/bdrv_put_buffer" is missing from the queue.
>>>  
>> I just did a pull a few hours ago from Christoph's qemu-io tree.  I'm 
>> expecting qemu-io patches to go through his tree.
> 
> I hold that patch back for now as it will need a bit of work if
> the ->bdrv_{get,put}_buffer renaming patch goes in.

Ok, that makes sense. Will you take care of it once the renaming patch
is in or should I resend it then?

Kevin

Re: [Qemu-devel] Planning for the 0.11.0 release

[Christoph Hellwig]

On Fri, Jul 10, 2009 at 07:12:37PM +0200, Kevin Wolf wrote:
> Ok, that makes sense. Will you take care of it once the renaming patch
> is in or should I resend it then?

If Anthony prefers patches I'll stop doing the git trees and you'll
have to repost it.  If we continue with the git trees I can adapt it.

Re: [Qemu-devel] Planning for the 0.11.0 release

[Anthony Liguori]

Christoph Hellwig wrote:
> On Fri, Jul 10, 2009 at 11:59:25AM -0500, Anthony Liguori wrote:
>   
>>> If I'm not mistaken, the patch "qemu-io: Implement
>>> bdrv_get_buffer/bdrv_put_buffer" is missing from the queue.
>>>  
>>>       
>> I just did a pull a few hours ago from Christoph's qemu-io tree.  I'm 
>> expecting qemu-io patches to go through his tree.
>>     
>
> I hold that patch back for now as it will need a bit of work if
> the ->bdrv_{get,put}_buffer renaming patch goes in.  Just looking at
> the queue Anthony only has queued up the older non-renaming version.
>   

Sorry, I'm not able to follow you here.  What is currently queued and 
what do you think should be queued?  Can you provide links/commit hashes?

Regards,

Anthony Liguori

Re: [Qemu-devel] Planning for the 0.11.0 release

[Christoph Hellwig]

On Fri, Jul 10, 2009 at 12:29:25PM -0500, Anthony Liguori wrote:
> Sorry, I'm not able to follow you here.  What is currently queued and 
> what do you think should be queued?  Can you provide links/commit hashes?

Currenly queued:

	http://repo.or.cz/w/qemu/aliguori-queue.git?a=commitdiff;h=9ecf9f92d22f28eccf8a7682b18f01cf1c9f04ba

Updated version:

	http://marc.info/?l=qemu-devel&m=124706191805387&w=2

Re: [Qemu-devel] Planning for the 0.11.0 release

[Anthony Liguori]

Christoph Hellwig wrote:
> On Fri, Jul 10, 2009 at 12:29:25PM -0500, Anthony Liguori wrote:
>   
>> Sorry, I'm not able to follow you here.  What is currently queued and 
>> what do you think should be queued?  Can you provide links/commit hashes?
>>     
>
> Currenly queued:
>
> 	http://repo.or.cz/w/qemu/aliguori-queue.git?a=commitdiff;h=9ecf9f92d22f28eccf8a7682b18f01cf1c9f04ba
>
> Updated version:
>
> 	http://marc.info/?l=qemu-devel&m=124706191805387&w=2
>   

No Signed-off-by, not a top-level patch.  I removed the old one from the 
queue though and will add your new one once you resend.

No Signed-off-by is the killer though.  I cannot take a patch that 
doesn't have a Signed-off-by.

Regards,

Anthony Liguori

Re: [Qemu-devel] Planning for the 0.11.0 release

[Anthony Liguori]

Kevin Wolf wrote:
> Anthony Liguori schrieb:
>   
>> Jan Kiszka wrote:
>>     
>>> Hmm, I must have missed this: Where is your staging tree hosted?
>>>   
>>>       
>> Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan 
>> to move it to git.qemu.org in the next few days.
>>     
>
> If I'm not mistaken, the patch "qemu-io: Implement
> bdrv_get_buffer/bdrv_put_buffer" is missing from the queue.
>   

BTW, this is one of the challenges of doing pulls.  I did the pull and 
then deleted every qemu-io patch in my queue since I assumed that 
everything that should go in was part of hch's pull request.  In 
general, that's the only sane way to do pulls so if someone requests a 
pull in the future, please make sure that you've gone through and pulled 
any patch from the list first.

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] Planning for the 0.11.0 release

[Avi Kivity]

On 07/10/2009 08:06 PM, Anthony Liguori wrote:
> BTW, this is one of the challenges of doing pulls.  I did the pull and 
> then deleted every qemu-io patch in my queue since I assumed that 
> everything that should go in was part of hch's pull request.  In 
> general, that's the only sane way to do pulls so if someone requests a 
> pull in the future, please make sure that you've gone through and 
> pulled any patch from the list first.

Pulls and stale queues are incompatible.  So long as everything is in 
patches, it doesn't matter since duplicate patches won't apply.  However 
a branch can't be based on a queue (since that's liable to change any 
time), and the branch can't commit and patches in the queue (since the 
queue might be committed any time).  If you want to pull, you'll need to 
shorten your queues (that will improve many other people's quality of 
life, btw).


-- 
error compiling committee.c: too many arguments to function