From Fedora Project Wiki

< FWN‎ | Beats

(reset for 171)
Line 20: Line 20:
 
[http://www.redhat.com/mailman/listinfo/fedora-virt fedora-virt list].
 
[http://www.redhat.com/mailman/listinfo/fedora-virt fedora-virt list].
  
==== ====
+
==== Virtualization Technology Preview Repo ====
 +
[[DanielBerrange|Daniel Berrange]]
 +
 
 +
<ref>http://www.redhat.com/archives/fedora-virt/2009-April/msg00008.html</ref>
 +
 
 +
<pre>
 +
The obvious problem with what we do for libvirt at the moment, is
 +
that we are introducing major new features into the stable release
 +
stream here. This risks destabalizing the stable Fedora streams,
 +
and also compromises our 'Feature' process because stuff we're
 +
pushing for Fedora 11 appears in Fedora 9 / 10 before F11 even comes
 +
out.
 +
 
 +
I think it would be desirable to get the stable Fedora releases onto a
 +
pretty strong bugfix only policy,...
 +
</pre>
 +
 
 +
<pre>
 +
under the umbrella of the
 +
Fedora Virtualization SIG. Specifically, to provide a 'virt-preview' YUM
 +
repo for the most recent stable stream (ie F10, but not F9).
 +
</pre>
 +
<pre>
 +
So in summary
 +
 
 +
- All new upstream releases built in rawhide
 +
- New upstream releases also built in stable preview branch if possible
 +
- Only bugfixes built in stable updates/updates-testing branch
 +
- In exceptional circumstances, rebase for preview branch can be
 +
  built to updates/updates-testing after alot of positive testing
 +
 
 +
This would
 +
 
 +
- Ensure users of stable Fedora release have high confidence in
 +
  quality of the updates/updates-testing stream
 +
- Allow users to trivially test new upstream rebases while
 +
  staying on the stable distro stream
 +
- Improve testing coverage of major new rawhide features without using
 +
  the stable release stream users as guinea pigs
 +
</pre>
 +
 
 +
[[MarkMcLoughlin|Mark McLoughlin]]
 +
thought<ref>http://www.redhat.com/archives/fedora-virt/2009-April/msg00010.html</ref>
 +
"this would be hugely useful to people interested in the latest
 +
virt bits, but without a testing machine for running rawhide." And even
 +
proposed a name for the repo "How about 'virt-hide' ? :)".
 +
 
 +
<pre>
 +
When libvirt-0.6.0 hit my laptop through updates-testing and was
 +
significantly broken, my reaction was along the lines of "wait, I didn't
 +
sign up for this!" - I suspect other people in that situation might
 +
disable updates-testing as a result. That damages not only testing of
 +
virt packages, but testing of the whole distro.
 +
 
 +
I think it was after that update that I wrote these guidelines<ref>http://fedoraproject.org/wiki/PackageMaintainers/Package_update_guidelines</ref> and had
 +
it approved by FESCo.
 +
</pre>
 +
 
 +
 
 
<references />
 
<references />
  

Revision as of 00:13, 10 April 2009


Virtualization

In this section, we cover discussion on the @et-mgmnt-tools-list, @fedora-xen-list, and @libvirt-list of Fedora virtualization technologies.

Contributing Writer: Dale Bewley

Enterprise Management Tools List

This section contains the discussion happening on the et-mgmt-tools list


Fedora Virtualization List

This section contains the discussion happening on the fedora-virt list.

Virtualization Technology Preview Repo

Daniel Berrange

[1]

The obvious problem with what we do for libvirt at the moment, is
that we are introducing major new features into the stable release
stream here. This risks destabalizing the stable Fedora streams, 
and also compromises our 'Feature' process because stuff we're 
pushing for Fedora 11 appears in Fedora 9 / 10 before F11 even comes
out.

I think it would be desirable to get the stable Fedora releases onto a 
pretty strong bugfix only policy,...
under the umbrella of the
Fedora Virtualization SIG. Specifically, to provide a 'virt-preview' YUM
repo for the most recent stable stream (ie F10, but not F9).
So in summary

 - All new upstream releases built in rawhide
 - New upstream releases also built in stable preview branch if possible
 - Only bugfixes built in stable updates/updates-testing branch
 - In exceptional circumstances, rebase for preview branch can be
   built to updates/updates-testing after alot of positive testing

This would

 - Ensure users of stable Fedora release have high confidence in 
   quality of the updates/updates-testing stream
 - Allow users to trivially test new upstream rebases while 
   staying on the stable distro stream
 - Improve testing coverage of major new rawhide features without using
   the stable release stream users as guinea pigs

Mark McLoughlin thought[2] "this would be hugely useful to people interested in the latest virt bits, but without a testing machine for running rawhide." And even proposed a name for the repo "How about 'virt-hide' ? :)".

When libvirt-0.6.0 hit my laptop through updates-testing and was
significantly broken, my reaction was along the lines of "wait, I didn't
sign up for this!" - I suspect other people in that situation might
disable updates-testing as a result. That damages not only testing of
virt packages, but testing of the whole distro.

I think it was after that update that I wrote these guidelines<ref>http://fedoraproject.org/wiki/PackageMaintainers/Package_update_guidelines</ref> and had
it approved by FESCo.


Fedora Xen List

This section contains the discussion happening on the fedora-xen list.

Experimental Dom0 Kernel Update

Michael Young I asked MY where he got his dom0 patches:

The patches were generated using git from the git repository 
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git combined with 
a mainline kernel git repository such as 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git
possibly with a bit of manual merging. So there isn't a single URL. I am 
not sure which is the best branch of the xen git to use at the moment, 
because the effort is focused on egtting the patches into the main kernel 
during the merge window.
If it helps Jeremy commented about the state of the xen repository in this 
email 
http://lists.xensource.com/archives/html/xen-devel/2009-04/msg00151.html
My most recent kernel was built using the push2/xen/dom0/master branch, 
though I think I might wait a week or so to see what gets merged before 
doing another update.


Libvirt List

This section contains the discussion happening on the libvir-list.