docs: add Xen PV Drivers Lifecycle
authorStefano Stabellini <sstabellini@kernel.org>
Fri, 13 Jan 2017 01:47:14 +0000 (17:47 -0800)
committerStefano Stabellini <sstabellini@kernel.org>
Fri, 13 Jan 2017 01:51:28 +0000 (17:51 -0800)
Add a document that details the lifecycle of new PV drivers.

Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
docs/misc/pv-drivers-lifecycle.markdown [new file with mode: 0644]

diff --git a/docs/misc/pv-drivers-lifecycle.markdown b/docs/misc/pv-drivers-lifecycle.markdown
new file mode 100644 (file)
index 0000000..c79abf0
--- /dev/null
@@ -0,0 +1,57 @@
+# Xen PV Drivers lifecycle
+
+## Purpose
+
+Getting new PV drivers accepted in Xen, upstream code bases, and ABI
+stable in the quickest and most efficient way possible.
+
+
+## Design Phase
+
+The first step toward acceptance of a new PV protocol is to write a
+design document and send it to xen-devel. It should cover the xenstore
+handshake mechanism, the ABI, how the protocol works and anything else
+which is required to write an implementation of it. The usage of C-like
+structs to describe language and platform agnostic protocols is
+discouraged.
+
+An attempt should be made to design the ABI such that it will be OS
+agnostic, that future versions will not need to introduce
+backward-incompatible changes, and so on; but these are not yet hard
+requirements.
+
+After the high level design of the protocol has been discussed and
+agreed, the document is committed to xen.git.
+
+
+## Prototype Stage
+
+The contributor sends patches to implement the PV drivers for the new
+protocol to the relevant open source mailing lists, such as LKML,
+qemu-devel and xen-devel.
+
+The code is expected to work, be good quality and faithfully implement
+the spec. However, there are no promises about ABI and cross-platform
+compatibility yet.
+
+After careful review by the relevant maintainers, the code is committed
+to the upstream code bases. The drivers are considered experimental.
+
+
+## Production Stage
+
+The quality of the drivers and the spec is improved. Bugs are fixed.
+The protocol version is likely bumped. More testing leads to confidence
+that the spec and the drivers are ready for production usage. Promises
+about backward compatibility and cross-platform compatibility are
+clearly spelled out.
+
+
+## How to move forward from a stage to the next
+
+The PV protocols Czar is responsible for determining the transitions
+between stages. Our governance principles specify "lazy consensus" for
+most things. It applies to this case too. New PV protocols should move
+from one stage to the next within a reasonable time frame unless someone
+has specific technical objections and voices them in a responsive
+manner.