Hi,
I'm ready to cut another qemu stable release and I'm contemplating whether to update to 0.5.1 in stable. Generally speaking, we try to limit stable to bug fixes and changes that aren't user visible.
0.5.1 looks like a point on the master branch as opposed to a separate branch. I wonder what the thinking is within SeaBIOS about what sort of changes will be in the 0.5.x series vs. what would result in 0.6.0.
Regards,
Anthony Liguori
On Tue, Jan 12, 2010 at 01:43:47PM -0600, Anthony Liguori wrote:
Hi,
I'm ready to cut another qemu stable release and I'm contemplating whether to update to 0.5.1 in stable. Generally speaking, we try to limit stable to bug fixes and changes that aren't user visible.
0.5.1 looks like a point on the master branch as opposed to a separate branch. I wonder what the thinking is within SeaBIOS about what sort of changes will be in the 0.5.x series vs. what would result in 0.6.0.
Hi Anthony,
I didn't have a particular release numbering scheme in mind when I tagged 0.5.1. I'd probably lean towards making a "v0.5.0.x" branch if we want an update with just critical bug fixes.
However, there have only been a few bug fixes (mostly workarounds for compiler oddities), though the yield fix (fb214dc7) and ram over 4gig fix (669c991d) should go in.
If you're looking to pull in 32bit pcibios support, then I don't think it would be worthwhile to rebase to a stable branch, as the 32bit pcibios support is easily the biggest user visible change in v0.5.1 (in the sense that Linux will call 32bit pcibios if it's available).
A couple of other changes could be user visible (eg, mptable), but I think the risk here is pretty small (assuming we haven't introduced a regression).
So, I'm okay with a stable branch (eg, v0.5.0.x), but I'm not sure what you would like to see in that branch.
-Kevin
On 01/12/2010 10:51 PM, Kevin O'Connor wrote:
On Tue, Jan 12, 2010 at 01:43:47PM -0600, Anthony Liguori wrote:
Hi,
I'm ready to cut another qemu stable release and I'm contemplating whether to update to 0.5.1 in stable. Generally speaking, we try to limit stable to bug fixes and changes that aren't user visible.
0.5.1 looks like a point on the master branch as opposed to a separate branch. I wonder what the thinking is within SeaBIOS about what sort of changes will be in the 0.5.x series vs. what would result in 0.6.0.
Hi Anthony,
I didn't have a particular release numbering scheme in mind when I tagged 0.5.1. I'd probably lean towards making a "v0.5.0.x" branch if we want an update with just critical bug fixes.
However, there have only been a few bug fixes (mostly workarounds for compiler oddities), though the yield fix (fb214dc7) and ram over 4gig fix (669c991d) should go in.
I actually need the compiler fix to build on my laptop (F12) so I've included that too. Care to take a look at git://git.qemu.org/seabios.git stable-0.5.0? It survives some light testing and I'll be doing more thorough testing overnight.
If you want to add some more and/or tag a release, I'll resync again before cutting 0.12.2.
If you're looking to pull in 32bit pcibios support, then I don't think it would be worthwhile to rebase to a stable branch, as the 32bit pcibios support is easily the biggest user visible change in v0.5.1 (in the sense that Linux will call 32bit pcibios if it's available).
Unless there's a strong demand for it, I'd like to hold off on 32bit pcibios support.
Thanks,
Anthony Liguori
A couple of other changes could be user visible (eg, mptable), but I think the risk here is pretty small (assuming we haven't introduced a regression).
So, I'm okay with a stable branch (eg, v0.5.0.x), but I'm not sure what you would like to see in that branch.
-Kevin
On Wed, Jan 13, 2010 at 05:58:35PM -0600, Anthony Liguori wrote:
On 01/12/2010 10:51 PM, Kevin O'Connor wrote:
On Tue, Jan 12, 2010 at 01:43:47PM -0600, Anthony Liguori wrote:
Hi,
I'm ready to cut another qemu stable release and I'm contemplating whether to update to 0.5.1 in stable. Generally speaking, we try to limit stable to bug fixes and changes that aren't user visible.
0.5.1 looks like a point on the master branch as opposed to a separate branch. I wonder what the thinking is within SeaBIOS about what sort of changes will be in the 0.5.x series vs. what would result in 0.6.0.
Hi Anthony,
I didn't have a particular release numbering scheme in mind when I tagged 0.5.1. I'd probably lean towards making a "v0.5.0.x" branch if we want an update with just critical bug fixes.
However, there have only been a few bug fixes (mostly workarounds for compiler oddities), though the yield fix (fb214dc7) and ram over 4gig fix (669c991d) should go in.
I actually need the compiler fix to build on my laptop (F12) so I've included that too. Care to take a look at git://git.qemu.org/seabios.git stable-0.5.0? It survives some light testing and I'll be doing more thorough testing overnight.
If you want to add some more and/or tag a release, I'll resync again before cutting 0.12.2.
If you're looking to pull in 32bit pcibios support, then I don't think it would be worthwhile to rebase to a stable branch, as the 32bit pcibios support is easily the biggest user visible change in v0.5.1 (in the sense that Linux will call 32bit pcibios if it's available).
Unless there's a strong demand for it, I'd like to hold off on 32bit pcibios support.
I would really like to see either that, or support for bochsbios again. Hurd is not able to boot correctly without 32bit pcibios support, and I fear it will be the case of other OSes.
Also 085debd93f52d36381ea13ef27e7f72e87fe62f5 could be interesting in a new stable release, this fix comes from a problem detected on an image that was working with 0.11.x.
Hi,
If you're looking to pull in 32bit pcibios support, then I don't think it would be worthwhile to rebase to a stable branch, as the 32bit pcibios support is easily the biggest user visible change in v0.5.1 (in the sense that Linux will call 32bit pcibios if it's available).
Unless there's a strong demand for it, I'd like to hold off on 32bit pcibios support.
I think someone mentioned bochs-based pcbios in qemu 0.11 has 32bit pcibios support, so not having that in 0.12 would be a regression. Dunno how much this is a problem in practice though.
cheers, Gerd
On Wed, Jan 13, 2010 at 05:58:35PM -0600, Anthony Liguori wrote:
I actually need the compiler fix to build on my laptop (F12) so I've included that too. Care to take a look at git://git.qemu.org/seabios.git stable-0.5.0? It survives some light testing and I'll be doing more thorough testing overnight.
I'd also include: 2ceeec9d, and 085debd9. The first fixes a binutils oddity, and the second is a straight-forward bug fix.
If you want to add some more and/or tag a release, I'll resync again before cutting 0.12.2.
If you're looking to pull in 32bit pcibios support, then I don't think it would be worthwhile to rebase to a stable branch, as the 32bit pcibios support is easily the biggest user visible change in v0.5.1 (in the sense that Linux will call 32bit pcibios if it's available).
Unless there's a strong demand for it, I'd like to hold off on 32bit pcibios support.
That makes sense. I'll pull your branch into my tree as well. However, I don't think I'll get time to look much closer at this until tomorrow night.
-Kevin
On 01/14/2010 07:46 AM, Kevin O'Connor wrote:
On Wed, Jan 13, 2010 at 05:58:35PM -0600, Anthony Liguori wrote:
I actually need the compiler fix to build on my laptop (F12) so I've included that too. Care to take a look at git://git.qemu.org/seabios.git stable-0.5.0? It survives some light testing and I'll be doing more thorough testing overnight.
I'd also include: 2ceeec9d, and 085debd9. The first fixes a binutils oddity, and the second is a straight-forward bug fix.
If you want to add some more and/or tag a release, I'll resync again before cutting 0.12.2.
If you're looking to pull in 32bit pcibios support, then I don't think it would be worthwhile to rebase to a stable branch, as the 32bit pcibios support is easily the biggest user visible change in v0.5.1 (in the sense that Linux will call 32bit pcibios if it's available).
Unless there's a strong demand for it, I'd like to hold off on 32bit pcibios support.
That makes sense. I'll pull your branch into my tree as well. However, I don't think I'll get time to look much closer at this until tomorrow night.
Based on the importance of 32bit pcibios support, I think it makes sense for us to just go to 0.5.1. Post 0.12.2, I think we'll want to be more restrictive but this looks to be an important feature.
Regards,
Anthony Liguori
-Kevin
-
Anthony Liguori -
Aurelien Jarno -
Gerd Hoffmann -
Kevin O'Connor