> On Jul 22, 2019, at 15:20, Andrew Cooper <andrew.coop...@citrix.com> 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.coop...@citrix.com> > --- > CC: George Dunlap <george.dun...@eu.citrix.com> > CC: Ian Jackson <ian.jack...@citrix.com> > CC: Jan Beulich <jbeul...@suse.com> > CC: Stefano Stabellini <sstabell...@kernel.org> > CC: Tim Deegan <t...@xen.org> > CC: Wei Liu <w...@xen.org> > CC: Julien Grall <julien.gr...@arm.com> > CC: Lars Kurth <lars.ku...@citrix.com> > CC: Paul Durrant <paul.durr...@citrix.com> > CC: Roger Pau Monné <roger....@citrix.com> > > 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
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
