Getting new PV drivers accepted in Xen, upstream code bases, and ABI stable in the quickest and most efficient way possible.
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.
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.
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.
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.