Xen project Mailing List

On Jul 22, 2019, at 15:20, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:

a.k.a. (at least in this form) Andrew's "work which might be offloadable to
someone else" list.

Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
---
CC: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
CC: Ian Jackson <ian.jackson@xxxxxxxxxx>
CC: Jan Beulich <JBeulich@xxxxxxxx>
CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
CC: Tim Deegan <tim@xxxxxxx>
CC: Wei Liu <wl@xxxxxxx>
CC: Julien Grall <julien.grall@xxxxxxx>
CC: Lars Kurth <lars.kurth@xxxxxxxxxx>
CC: Paul Durrant <paul.durrant@xxxxxxxxxx>
CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>

RFC for obvious reasons.

A rendered version of this can be found at:
https://andrewcoop-xen.readthedocs.io/en/docs-wishlist/misc/wishlist.html

During XenSummit in Chicago, it was expressed several times that having some
todo lists would be a benefit, to help coordinate work in related areas.

Here is an attempt to start one. For now, it covers one single
item (xenstored's use of non-stable APIs) to get some feedback about the
general approach. I have plenty to get stuck into in Xen itself if this way
of expressing them isn't deemed unacceptable.

As for the wishlist itself, I think it is important that it be restricted to
concrete actions (i.e. already partially groomed, if you speak agile), which
are identified problems, and suggested fixes.

In particular, I don't think it is appropriate to devolve into a bullet point
list of new features, or tasks like "document $whotsit". It should be
restricted to things which are real problems, on existing systems, which have
some forward plan of action. That way, any developer should be able to
cross-reference at least at a high level, and see if there are areas of
overlapping work, or whether a slightly tweaked approach might be suitable for
multiple areas.

Anyway - thoughts from the peanut gallery?

Would you consider a permissive, documentation-oriented license, e.g. Creative Commons CC-BY 4.0, for Xen's Sphinx/RST documentation?

https://creativecommons.org/licenses/by/4.0/

As Xen moves beyond cloud computing into multi-vendor, edge/embedded supply chains [1], the audience and context for Xen's technical docs is expanding. Beyond operating system user/dev/admin, there may be: nested hypervisor user/dev/admin, certification (FuSA), security, firmware/device/accelerator dev, processor architects, formal verification (e.g. TLA+ models), ecosystem building (e.g. blogs, books, videos, training, research) and commercial maintenance manuals for long-lived products with multiple Xen configs and embedded processors.

A permissive license would encourage reuse and tailoring of Xen docs. With healthy OSS projects, there will remain an incentive to contribute long-lived improvements upstream, even if those improvements are not mandated by the CC license. The Xen wiki license is historically CC-BY-SA 3.0, so that content would be incompatible with CC-BY 4.0. But Xen's Sphinx/RST docs appear to be focused on new content, so we have an opportunity to choose a license which reflects current community priorities.

Rich

[1] https://dornerworks.com/blog/high-performance-space-computing-platform-nasa-sbir

Re: [Xen-devel] [PATCH] docs/sphinx: todo/wishlist