Planning for the 0.11.0 release
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.
Signature · 3 lines
Regards, Anthony Liguori
Quoted 6 lines · 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:
Seems sane to me.
Quoted 2 lines
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.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 9 lines · 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:
Quoted 7 lines
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).
Quoted 8 lines
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?
Quoted 34 lines · Blue Swirl
Quoted 9 lines · 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:Quoted 8 lines
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).
Quoted 9 lines
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.
Quoted 3 lines
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
Signature · 3 lines
Regards, Anthony Liguori
Quoted 3 lines · Blue Swirl
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.
Signature · 1 line
error compiling committee.c: too many arguments to function
Hi Anthony,
Quoted 10 lines · 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
Are you still planning on creating the 0.11 branch next week?
Cheers,
Mark.
Quoted 6 lines · Mark McLoughlin
Hi Anthony,
Quoted 2 lines · Anthony Liguori
Hi,
Quoted 9 lines
Quoted 6 lines
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
Quoted 8 lines
Cheers,
Mark.--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 27 lines · Anthony Liguori
Quoted 10 lines · Mark McLoughlin
Hi Anthony,
Quoted 6 lines · 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.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 3 lines
Regards,
Anthony Liguori
Any hope that -device can make the cut?
Quoted 4 lines · Markus Armbruster
Anthony Liguori <[email protected]> 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.
Signature · 3 lines
Regards, Anthony Liguori
Quoted 9 lines · Anthony Liguori
Quoted 4 lines · Markus Armbruster
Anthony Liguori <[email protected]> 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.
Quoted 6 lines
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
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Quoted 2 lines · Jan Kiszka
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
Quoted 6 lines · Anthony Liguori
Quoted 2 lines · Jan Kiszka
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
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Quoted 3 lines · Jan Kiszka
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?
Quoted 5 lines
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?
Signature · 3 lines
Regards, Anthony Liguori
Quoted 9 lines · Anthony Liguori
Quoted 3 lines · Jan Kiszka
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.
Quoted 9 lines
Quoted 6 lines
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.
Quoted 3 lines
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
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Quoted 3 lines · Jan Kiszka
Something went wrong during transmission, and I missed that. Just sent out those two as well.
Thanks, it's now all in staging.
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 7 lines
Quoted 4 lines
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?
Signature · 3 lines
Regards, Anthony Liguori
Quoted 8 lines · Anthony Liguori
Quoted 3 lines · Jan Kiszka
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
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Quoted 4 lines
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
Quoted 8 lines · Paul Brook
Quoted 5 lines
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
Quoted 2 lines · Paul Brook
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.
Quoted 1 line
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.
Quoted 2 lines
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
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Quoted 5 lines
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
Quoted 6 lines · Anthony Liguori
Quoted 2 lines · Jan Kiszka
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
Quoted 4 lines · Kevin Wolf
Quoted 2 lines · Anthony Liguori
Jan Kiszka wrote:
Quoted 9 lines
Quoted 5 lines
Quoted 3 lines
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
Quoted 6 lines · Anthony Liguori
Quoted 3 lines
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?
Quoted 9 lines · Christoph Hellwig
Quoted 5 lines · Anthony Liguori
Quoted 3 lines
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
Quoted 2 lines · Kevin Wolf
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.
Quoted 6 lines · Christoph Hellwig
Quoted 4 lines · Anthony Liguori
Quoted 4 lines
If I'm not mistaken, the patch "qemu-io: Implement bdrv_get_buffer/bdrv_put_buffer" is missing from the queue.
Quoted 7 lines
Quoted 2 lines
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
Quoted 2 lines · Anthony Liguori
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
Quoted 5 lines · Christoph Hellwig
Quoted 2 lines · Anthony Liguori
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?
Quoted 8 lines
Currenly queued:
http://repo.or.cz/w/qemu/aliguori-queue.git?a=commitdiff;h=9ecf9f92d22f28eccf8a7682b18f01cf1c9f04baUpdated 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
Quoted 11 lines · Anthony Liguori
Quoted 10 lines · Kevin Wolf
Quoted 8 lines · Anthony Liguori
Quoted 3 lines · Jan Kiszka
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.
Quoted 6 lines
Quoted 3 lines
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
Quoted 3 lines · Kevin Wolf
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.
Quoted 4 lines
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
Quoted 2 lines
Kevin
Quoted 4 lines · Kevin Wolf
Quoted 2 lines · Anthony Liguori
Jan Kiszka wrote:
Quoted 9 lines
Quoted 5 lines
Quoted 3 lines
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.
Signature · 3 lines
Regards, Anthony Liguori
Quoted 1 line · Anthony Liguori
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).
Signature · 1 line
error compiling committee.c: too many arguments to function