Howdy, I was touching up the virt release[1] notes a little bit. There are currently 5 virtualization related features[2] for F11:
* KVM_PCI_Device_Assignment * KVM_and_QEMU_merge * Shared Network Interface * SVirt Mandatory Access Control * Virtualization VNC Authentication
Only KVM PCI Device Assignment has been accepted[3] so far. The feature freeze is coming up in one week[4] (March 3rd). I assume if they are not listed as accepted at that time they shan't be included, barring fesco exception.
Would the owners of the above features care to chime in about their (un)likelihood of inclusion in F11, or give em a little shove towards "acceptance"?
[1] http://fedoraproject.org/wiki/Docs/Beats/Virtualization [2] http://fedoraproject.org/wiki/Category:F11_Virt_Features [3] http://fedoraproject.org/wiki/Releases/11/FeatureList [4] http://fedoraproject.org/wiki/Releases/11/Schedule -- Dale Bewley - Unix Administrator - Shields Library - UC Davis GPG: 0xB098A0F3 0D5A 9AEB 43F4 F84C 7EFD 1753 064D 2583 B098 A0F3
On Tue, 2009-02-24 at 22:23 -0800, Dale Bewley wrote:
Howdy, I was touching up the virt release[1] notes a little bit. There are currently 5 virtualization related features[2] for F11:
Here's a quick take on the current status of these:
* KVM_PCI_Device_Assignment
- VT-d is enabled by default again in the kernel, KVM support seems to work well
- libvirt patches posted upstream yesterday
- Cole is going to look at using the new libvirt APIs to allow NIC assignment in virt-manager and virt-install
* KVM_and_QEMU_merge
- Glauber has done awesome work to update QEMU to latest upstream, split out sub-packages and create BIOS packages
- The rumour mill has it that there will be a QEMU release at the end of this week or start of next week
- Unclear as to whether we have time to switch to building QEMU from the kvm-userspace tarball; there may yet be dragons lurking there
* Shared Network Interface
- David Lutterkort is working hard on the netcf library and is still relatively optimistic about getting it into F11
* SVirt Mandatory Access Control
- Dan Walsh has been working to get the patch merged into libvirt and add support in virtinst
- Looks likely this will make F11
* Virtualization VNC Authentication
- Dan Berrange posted his patches to qemu-devel a week or two ago; unclear as to the current status
Only KVM PCI Device Assignment has been accepted[3] so far. The feature freeze is coming up in one week[4] (March 3rd). I assume if they are not listed as accepted at that time they shan't be included, barring fesco exception.
Would the owners of the above features care to chime in about their (un)likelihood of inclusion in F11, or give em a little shove towards "acceptance"?
Yep - that absolutely needs to be done very soon.
Glauber, Dan (Walsh) and David could you read:
https://fedoraproject.org/wiki/Features/Policy
then update your page and add it to the FeatureReadyForWrangler category. At that point it will be queued up for FESCo review. FESCo meet on Fridays AFAIR.
(Dan Berrange - I fixed VNCAuth to really be in ReadyForWrangler :-)
Cheers, Mark.
On Wed, 2009-02-25 at 11:14 +0000, Mark McLoughlin wrote:
Glauber, Dan (Walsh) and David could you read:
https://fedoraproject.org/wiki/Features/Policy
then update your page and add it to the FeatureReadyForWrangler category. At that point it will be queued up for FESCo review. FESCo meet on Fridays AFAIR.
Done.
David
Hi, I'm not sure it's clear to anyone why we have this feature approval and feature freeze process, so I thought I'd point to some wiki pages with the background. See below.
IMHO this boils down to communication:
- we want people to know in advance what new virt features we're adding in F11
- if we miss the feature freeze with any of those features we should be planning realistically whether to continue pushing for F11 or whether to punt to F12 because it won't have had time to stabilise it for the F11 release
- if we feel that we can include it post freeze and stabilise it in time, we should ask for an exception (a second opinion, basically) from rel-eng confirming that that's a sane plan
- it's only right to keep rel-eng in the loop; they are the ones with a global view of the Fedora release. I've found them very sane in the past when considering exceptions
Anyway, the bits from the wiki:
https://fedoraproject.org/wiki/Features/Policy/Background
The value of having features defined up front is many-fold:
* Everyone has an idea of what everyone else is working on. This provides the opportunity for feedback and suggestions for improvement. * You get people interested--perhaps even helping out * You get some idea of areas that are going to need testing so that testers can build up experience and knowledge about the area * You generate excitement around what's being worked on * You avoid surprises at the end * Public accountability to do what we say we are going to do * Easier Release Notes creation for new features--everything needed is on the individual feature pages. * Ability to list out a set of features to be picked up or when talking to the media/press. Fedora ambassadors and any promotional efforts would find a feature list useful.
http://fedoraproject.org/wiki/ReleaseEngineering/FeatureFreezePolicy
As of the feature freeze for a release, no new features or major version bumps are allowed for packages already in the Fedora collection ... Note that ignoring the freeze process and introducing new features anyway will lead to your package being reverted and a reduction of the chances of an exception being made.
Cheers, Mark.