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.