From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, MIME_QP_LONG_LINE,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B508C76186 for ; Mon, 29 Jul 2019 03:15:52 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4E5D22075B for ; Mon, 29 Jul 2019 03:15:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="gjSYH7rp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4E5D22075B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1hrw86-0007cI-Q3; Mon, 29 Jul 2019 03:15:18 +0000 Received: from us1-rack-dfw2.inumbo.com ([104.130.134.6]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1hrw84-0007cD-UW for xen-devel@lists.xenproject.org; Mon, 29 Jul 2019 03:15:16 +0000 X-Inumbo-ID: 1541c1a1-b1af-11e9-8980-bc764e045a96 Received: from mail-qk1-x741.google.com (unknown [2607:f8b0:4864:20::741]) by us1-rack-dfw2.inumbo.com (Halon) with ESMTPS id 1541c1a1-b1af-11e9-8980-bc764e045a96; Mon, 29 Jul 2019 03:15:14 +0000 (UTC) Received: by mail-qk1-x741.google.com with SMTP id s145so43163449qke.7 for ; Sun, 28 Jul 2019 20:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cqELUuUgn6xF1hqWiHemT+K7u4rAfejW/+c7WkSqNuQ=; b=gjSYH7rp2F1geaSX8dKZ8/NWM6liQyOKJ70hSwa55wdHiAEMVYw4WPG0ty9Do0zXV3 G65NnguvkWYyNxrc8q3QnQmo9PVLQEf/gk4UrduNRPvnFsfV3jeOjSPYRTAKe0Hg+zJQ 9LNvMDOSfrQqj7/kTExdVW28sYBtIMm7kLLrntEAHH5a6inQE+dlS1AMjVHTQmWsgQEH gFzWcMhRuKQ0eUFLk1dAeaUQnKn/l+6Z979aGJI2FgDjXTD/3VD+bpAqhwhma8vjJQ3O OinDuB9Dh6ep+I2ETLew/qouuxt6jTSGy8qD9bydEg4s4zkNqedvsJmdZgl7yRuSwYhy UHHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cqELUuUgn6xF1hqWiHemT+K7u4rAfejW/+c7WkSqNuQ=; b=dv7/pYXYAe9RWV6mvDj4PQ6RcLbJ3vSwNvEUWPFhjf7EMJZDmvpIMP4t06bO8WFeGq PokJ4SJCs8BQp2K8Bt6vWj2Rb4u3ItBr2kprW3FvtLOdYHrMpFQmb0qJ717wypm4IX2X dnLiJp7rpCZzN9SUIdT9Jn5FivKQAyxQq1TG7lH0edYj/rx65Wtc5OfIRpHucUTQGSlq 1fvYc4LIG6FAHSDlSew3MWz5TzPNUk8UMXZKiwTpyszHUfRdj8h+gfwbmjvJRXV5i5fm 2WT4d6kjBvpc4Ia+IP9wa9on88vqWTxMzPCAr2iQcuFMWR25nLRf8+qPTDR68iHjh/fV vbwA== X-Gm-Message-State: APjAAAUQYTg8exJW5SCxfZOEqd2mthL8p7tBrWUTYy+qvkrcCoNkt5Rx HztMYzT1i7GDMZCCi/RL/OY= X-Google-Smtp-Source: APXvYqxU0mtmBiLL9cFOu8Ut6CAawETc4A9ITuJ5d4SVaFR9K80MM69TFzIs4Aem5xdVx3ZPAStUaA== X-Received: by 2002:ae9:ec0d:: with SMTP id h13mr71426461qkg.26.1564370114177; Sun, 28 Jul 2019 20:15:14 -0700 (PDT) Received: from [192.168.50.2] (cpe-24-90-150-194.nyc.res.rr.com. [24.90.150.194]) by smtp.gmail.com with ESMTPSA id b4sm24684196qtp.77.2019.07.28.20.15.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Jul 2019 20:15:13 -0700 (PDT) Mime-Version: 1.0 (1.0) From: Rich Persaud X-Mailer: iPad Mail (16G77) In-Reply-To: <20190722192056.15816-1-andrew.cooper3@citrix.com> Date: Sun, 28 Jul 2019 23:15:12 -0400 Message-Id: References: <20190722192056.15816-1-andrew.cooper3@citrix.com> To: Andrew Cooper , Lars Kurth Subject: Re: [Xen-devel] [PATCH] docs/sphinx: todo/wishlist X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , George Dunlap , Tim Deegan , Julien Grall , Paul Durrant , Jan Beulich , Ian Jackson , Xen-devel , =?utf-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: multipart/mixed; boundary="===============7169474232152767511==" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --===============7169474232152767511== Content-Type: multipart/alternative; boundary=Apple-Mail-83056C63-A861-4B1A-9742-3898A3BDBAA1 Content-Transfer-Encoding: 7bit --Apple-Mail-83056C63-A861-4B1A-9742-3898A3BDBAA1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Jul 22, 2019, at 15:20, Andrew Cooper wrote= : >=20 > a.k.a. (at least in this form) Andrew's "work which might be offloadable t= o > someone else" list. >=20 > Signed-off-by: Andrew Cooper > --- > CC: George Dunlap > CC: Ian Jackson > CC: Jan Beulich > CC: Stefano Stabellini > CC: Tim Deegan > CC: Wei Liu > CC: Julien Grall > CC: Lars Kurth > CC: Paul Durrant > CC: Roger Pau Monn=C3=A9 >=20 > RFC for obvious reasons. >=20 > A rendered version of this can be found at: > https://andrewcoop-xen.readthedocs.io/en/docs-wishlist/misc/wishlist.html >=20 > During XenSummit in Chicago, it was expressed several times that having so= me > todo lists would be a benefit, to help coordinate work in related areas. >=20 > 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 w= ay > of expressing them isn't deemed unacceptable. >=20 > As for the wishlist itself, I think it is important that it be restricted t= o > concrete actions (i.e. already partially groomed, if you speak agile), whi= ch > are identified problems, and suggested fixes. >=20 > In particular, I don't think it is appropriate to devolve into a bullet po= int > list of new features, or tasks like "document $whotsit". It should be > restricted to things which are real problems, on existing systems, which h= ave > 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. >=20 > Anyway - thoughts from the peanut gallery? Would you consider a permissive, documentation-oriented license, e.g. Creati= ve 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 c= hains [1], the audience and context for Xen's technical docs is expanding. B= eyond operating system user/dev/admin, there may be: nested hypervisor user/= dev/admin, certification (FuSA), security, firmware/device/accelerator dev, p= rocessor architects, formal verification (e.g. TLA+ models), ecosystem build= ing (e.g. blogs, books, videos, training, research) and commercial maintenan= ce manuals for long-lived products with multiple Xen configs and embedded pr= ocessors. A permissive license would encourage reuse and tailoring of Xen docs. With h= ealthy OSS projects, there will remain an incentive to contribute long-lived= improvements upstream, even if those improvements are not mandated by the C= C license. The Xen wiki license is historically CC-BY-SA 3.0, so that conten= t 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 wh= ich reflects current community priorities. Rich [1] https://dornerworks.com/blog/high-performance-space-computing-platform-n= asa-sbir --Apple-Mail-83056C63-A861-4B1A-9742-3898A3BDBAA1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Jul 22, 2019, at 15:20,= Andrew Cooper <andrew.coope= r3@citrix.com> wrote:

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

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: George Dunlap <George.Dunlap@eu.citrix.com>
CC: Ian J= ackson <ian.jackson@citrix.com<= /a>>
CC: Jan Beulich <JBeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Tim Deegan <tim@xen.org= >
CC: Wei Liu <wl@xen.or= g>
CC: Julien Grall <julien.grall@arm.com>
CC: Lars Kurth <<= a href=3D"mailto:lars.kurth@citrix.com">lars.kurth@citrix.com>=
CC: Paul Durrant <pa= ul.durrant@citrix.com>
CC: Roger Pau Monn=C3=A9 <<= a href=3D"mailto:roger.pau@citrix.com">roger.pau@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 expre= ssed several times that having some
todo lists would be a be= nefit, 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 feedbac= k about the
general approach.  I have plenty to get stu= ck into in Xen itself if this way
of expressing them isn't d= eemed unacceptable.

As for the wishlist its= elf, I think it is important that it be restricted to
concre= te 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 "documen= t $whotsit".  It should be
restricted to things which a= re real problems, on existing systems, which have
some forwa= rd plan of action.  That way, any developer should be able tocross-reference at least at a high level, and see if there are areas o= f
overlapping work, or whether a slightly tweaked approach m= ight be suitable for
multiple areas.
=
Anyway - thoughts from the peanut gallery?

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

As Xen moves b= eyond cloud computing into multi-vendor, edge/embedded supply chains [1], th= e audience and context for Xen's technical docs is expanding.  Beyond o= perating system user/dev/admin, there may be: nested hypervisor user/dev/adm= in, certification (FuSA), security, firmware/device/accelerator dev, process= or architects, formal verification (e.g. TLA+ models), ecosystem building (e= .g. blogs, books, videos, training, research) and commercial maintenance man= uals for long-lived products with multiple Xen configs and embedded processo= rs.

A permissive license would encourage reuse and t= ailoring of Xen docs.  With healthy OSS projects, there will remain an i= ncentive to contribute long-lived improvements upstream, even if those impro= vements are not mandated by the CC license. The Xen wiki license is historic= ally CC-BY-SA 3.0, so that content would be incompatible with CC-BY 4.0. &nb= sp;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 priorit= ies.

Rich


= --Apple-Mail-83056C63-A861-4B1A-9742-3898A3BDBAA1-- --===============7169474232152767511== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cHM6Ly9saXN0 cy54ZW5wcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hlbi1kZXZlbA== --===============7169474232152767511==--