[libvirt PATCH 2/5] docs: platforms: Convert to reStructuredText

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx>
---
 docs/platforms.html.in | 119 -----------------------------------------
 docs/platforms.rst     | 100 ++++++++++++++++++++++++++++++++++
 2 files changed, 100 insertions(+), 119 deletions(-)
 delete mode 100644 docs/platforms.html.in
 create mode 100644 docs/platforms.rst

diff --git a/docs/platforms.html.in b/docs/platforms.html.in
deleted file mode 100644
index c50279bffd..0000000000
--- a/docs/platforms.html.in
+++ /dev/null
@@ -1,119 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml";>
-  <body>
-    <h1>Supported host platforms</h1>
-
-    <ul id="toc"></ul>
-
-    <p>
-      Libvirt aims to support building and executing on multiple host OS
-      platforms, as well as working with multiple hypervisors. This document
-      outlines which platforms are targeted for each of these areas.
-    </p>
-
-    <h2>Build targets</h2>
-
-    <p>
-      These platforms are used as the basis for deciding
-      upon the minimum required versions of 3rd party software libvirt depends
-      on. If a platform is not listed here, it does not imply that libvirt
-      won't work. If an unlisted platform has comparable software versions
-      to a listed platform, there is every expectation that it will work.
-      Bug reports are welcome for problems encountered on unlisted platforms
-      unless they are clearly older vintage than what is described here.
-    </p>
-
-    <p>
-      Note that when considering software versions shipped in distros as
-      support targets, libvirt considers only the version number, and assumes
-      the features in that distro match the upstream release with the same
-      version. In other words, if a distro backports extra features to the
-      software in their distro, libvirt upstream code will not add explicit
-      support for those backports, unless the feature is auto-detectable in
-      a manner that works for the upstream releases too.
-    </p>
-
-    <p>
-      The Repology site is a useful resource to identify currently shipped
-      versions of software in various operating systems, though it does not
-      cover all distros listed below.
-    </p>
-
-    <ul>
-      <li><a href="https://repology.org/metapackage/libvirt/versions";>libvirt</a></li>
-      <li><a href="https://repology.org/metapackage/qemu/versions";>qemu</a></li>
-      <li><a href="https://repology.org/metapackage/qemu-kvm/versions";>qemu-kvm</a></li>
-    </ul>
-
-
-    <h3>Linux OS</h3>
-
-    <p>
-      For distributions with frequent, short-lifetime releases, the project
-      will aim to support all versions that are not end of life by their
-      respective vendors. For the purposes of identifying supported software
-      versions, the project will look at Fedora, Ubuntu, and openSUSE distros.
-      Other short-lifetime distros will be assumed to ship similar software
-      versions.
-    </p>
-
-    <p>
-      For distributions with long-lifetime releases, the project will aim to
-      support the most recent major version at all times. Support for the
-      previous major version will be dropped 2 years after the new major
-      version is released. For the purposes of identifying supported software
-      versions, the project will look at RHEL, Debian, Ubuntu LTS, and SLES
-      distros. Other long-lifetime distros will be assumed to ship similar
-      software versions.
-    </p>
-
-    <h3>Windows</h3>
-
-    <p>
-      The project supports building with current versions of the MinGW
-      toolchain, hosted on Linux.
-    </p>
-
-    <h3>macOS</h3>
-
-    <p>
-      The project aims to support the most recent major version
-      at all times. Support for the previous major version will
-      be dropped 2 years after the new major version is released.
-    </p>
-
-    <p>
-      Note that to compile libvirt will require extra packages
-      to be made available on the macOS host. It is recommended
-      to use <a href="https://brew.sh/";>HomeBrew</a> since this
-      is what libvirt CI tests with, however, <a herf="https://www.macports.org/";>MacPorts</a>
-      is an alternative option that is likely to work.
-    </p>
-
-    <h3>FreeBSD</h3>
-
-    <p>
-      The project aims to support the most recent major version
-      at all times. Support for the previous major version will
-      be dropped 2 years after the new major version is released.
-    </p>
-
-    <h2>Virtualization platforms</h2>
-
-    <p>
-      For <a href="drivers.html">hypervisor drivers</a> which execute
-      locally (QEMU, LXC, VZ, libxl, etc), the set of supported operating
-      system platforms listed above will inform choices as to the minimum
-      required versions of 3rd party libraries and hypervisor management
-      APIs.
-    </p>
-    <p>
-      If a hypervisor is not commonly shipped directly by any distro
-      listed above, (VMware ESX, HyperV, VZ), the project aims to
-      support versions up to 5 years, or until the vendor discontinues
-      support, whichever comes first.
-    </p>
-
-  </body>
-</html>
diff --git a/docs/platforms.rst b/docs/platforms.rst
new file mode 100644
index 0000000000..2845ac40ea
--- /dev/null
+++ b/docs/platforms.rst
@@ -0,0 +1,100 @@
+========================
+Supported host platforms
+========================
+
+.. contents::
+
+Libvirt aims to support building and executing on multiple host OS platforms,
+as well as working with multiple hypervisors. This document outlines which
+platforms are targeted for each of these areas.
+
+
+Build targets
+=============
+
+These platforms are used as the basis for deciding upon the minimum required
+versions of 3rd party software libvirt depends on. If a platform is not listed
+here, it does not imply that libvirt won't work. If an unlisted platform has
+comparable software versions to a listed platform, there is every expectation
+that it will work.  Bug reports are welcome for problems encountered on
+unlisted platforms unless they are clearly older vintage than what is described
+here.
+
+Note that when considering software versions shipped in distros as support
+targets, libvirt considers only the version number, and assumes the features in
+that distro match the upstream release with the same version. In other words,
+if a distro backports extra features to the software in their distro, libvirt
+upstream code will not add explicit support for those backports, unless the
+feature is auto-detectable in a manner that works for the upstream releases
+too.
+
+The `Repology`_ site is a useful resource to identify currently shipped
+versions of software in various operating systems, though it does not cover all
+distros listed below.
+
+* `libvirt on Repology`_
+* `qemu on Repology`_
+* `qemu-kvm on Repology`_
+
+Linux OS
+--------
+
+For distributions with frequent, short-lifetime releases, the project will aim
+to support all versions that are not end of life by their respective vendors.
+For the purposes of identifying supported software versions, the project will
+look at Fedora, Ubuntu, and openSUSE distros.  Other short-lifetime distros
+will be assumed to ship similar software versions.
+
+For distributions with long-lifetime releases, the project will aim to support
+the most recent major version at all times. Support for the previous major
+version will be dropped 2 years after the new major version is released. For
+the purposes of identifying supported software versions, the project will look
+at RHEL, Debian, Ubuntu LTS, and SLES distros. Other long-lifetime distros will
+be assumed to ship similar software versions.
+
+Windows
+-------
+
+The project supports building with current versions of the MinGW toolchain,
+hosted on Linux.
+
+macOS
+-----
+
+The project aims to support the most recent major version at all times. Support
+for the previous major version will be dropped 2 years after the new major
+version is released.
+
+Note that to compile libvirt will require extra packages to be made available
+on the macOS host. It is recommended to use `HomeBrew`_ since this is what
+libvirt CI tests with, however, `MacPorts`_ is an alternative option that is
+likely to work.
+
+FreeBSD
+-------
+
+The project aims to support the most recent major version at all times. Support
+for the previous major version will be dropped 2 years after the new major
+version is released.
+
+
+Virtualization platforms
+========================
+
+For `hypervisor drivers`_ which execute locally (QEMU, LXC, VZ, libxl, etc),
+the set of supported operating system platforms listed above will inform
+choices as to the minimum required versions of 3rd party libraries and
+hypervisor management APIs.
+
+If a hypervisor is not commonly shipped directly by any distro listed above,
+(VMware ESX, HyperV, VZ), the project aims to support versions up to 5 years,
+or until the vendor discontinues support, whichever comes first.
+
+
+.. _HomeBrew: https://brew.sh/
+.. _MacPorts: https://www.macports.org/
+.. _Repology: https://repology.org/
+.. _hypervisor drivers: drivers.html
+.. _libvirt on Repology: https://repology.org/metapackage/libvirt/versions
+.. _qemu on Repology: https://repology.org/metapackage/qemu/versions
+.. _qemu-kvm on Repology: https://repology.org/metapackage/qemu-kvm/versions
-- 
2.25.4




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux