On Mon, Dec 19, 2011 at 12:02:59PM -0600, Anthony Liguori wrote:
On 12/19/2011 11:43 AM, Daniel P. Berrange wrote:
I hadn't raised it again, because I had mistakenly assumed QEMU will automatically pull in the newer SeaBios release before 1.0 came out. I could have more aggresively bugged people on qemu-devel to update SeaBios, but given your point above about not wanting to rebase Seabios its not clear that would have helped sort this out before 1.0
We really need to update SeaBIOS whenever there is a bug that we know requires an update. Things breakdown because of one or more of the following reasons:
- User submits a patch to seabios@, Kevin applies it. But that
doesn't necessarily trigger anything happening in QEMU.
Ideally, the above mentioned user would submit a submodule update once (1) happens.
- Kevin fixes something on his own or someone else changes
something in the broader SeaBIOS community. That may not even be visible in QEMU.
Syncing right before release isn't a good strategy either because that means we're pulling in something that hasn't been tested extensively at the very tail end of our release cycle.
I would like to point out that August -> October is a pretty long time period for a regression like this to exist. I think that really indicates that the primary problem is testing, not frequency of SeaBIOS updates.
One complication is that alot of us are not necessarily testing the SeaBIOS that is in QEMU GIT. Fedora rawhide includes qemu-kvm.git snapshots which are updated fairly frequently, but we don't use the SeaBIOS QEMU includes. Instead Fedora includes the latest SeaBIOS upstream release.
So Fedora 16/rawhide users would never have seen this particular bug for longer than a couple of weeks until the fixed SeaBIOS arrived.
Regards, Daniel