xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Stefano Stabellini <sstabellini@kernel.org>
To: Julien Grall <Julien.Grall@arm.com>
Cc: "lars.kurth@citrix.com" <lars.kurth@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	"committers@xenproject.org" <committers@xenproject.org>,
	Ian Jackson <Ian.Jackson@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>, nd <nd@arm.com>
Subject: Re: [Xen-devel] Migrating key developer docs to xen.git sphinx docs and refreshing them in the process
Date: Mon, 24 Jun 2019 13:23:02 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.21.1906241317280.2468@sstabellini-ThinkPad-T480s> (raw)
In-Reply-To: <88dee4d2-d7cb-f342-118f-97c37f43f6ff@arm.com>

On Mon, 24 Jun 2019, Julien Grall wrote:
> Hi,
> 
> On 24/06/2019 19:03, Stefano Stabellini wrote:
> > On Mon, 24 Jun 2019, Lars Kurth wrote:
> > I think we all agree by now that maintaining up-to-date docs on the wiki
> > and keeping them in sync with code changes is hard. I see moving things
> > from the wiki to xen.git as a great improvement. We have a few Xen on
> > ARM docs that are worth importing from the wiki:
> > 
> > https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions
> 
> I agree for this but ...
> 
> > 
> > And all the board specific docs linked from it, such as:
> > 
> > https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/qemu-system-aarch64
> > https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/FastModels
> > https://wiki.xenproject.org/wiki/HiKey960
> 
> ... I think it is a pretty bad idea to import board specific docs. There 
> are a lot of way to build components for a given board and I am worry of 
> the overheard for the maintainers to look/maintain the documentation. It 
> also brings the question of the acceptance/removal of
> a board documentation.

That problem can be solved by specifying an appropriate maintenance
model for those documents.


> Instead we should provide generic guidance/troubleshoot to the user. 
> Anything board specific could be maintain on the wiki by someone caring 
> about the board without having us to gate it.

If we move the docs to xen.git it doesn't immediately imply that the
REST maintainers need to "gate" them. We could make the existing
curators of those pages the maintainers for those files, for example. We
can come up with mode ideas. We could even leave them unmaintained.

The point here is that we can be flexible and creative about the way to
maintain the docs on xen.git. But as a technology is certainly better
than the wiki: we don't have to keep them all up-to-date with the code,
but at least this way we have a chance (if we want to). If we leave them
on the wiki, there is no chance.


> We could try to revive a discussion we had a couple of years ago where 
> someone is responsible for a given board to test and document it. Today 
> it is informal, but I have been pushing for it recently for new boards.

Yes, this is a good idea and fit nicely with the maintenance model I
was suggesting.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-06-24 20:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-24 12:26 [Xen-devel] Migrating key developer docs to xen.git sphinx docs and refreshing them in the process Lars Kurth
2019-06-24 18:03 ` Stefano Stabellini
2019-06-24 19:21   ` Julien Grall
2019-06-24 20:23     ` Stefano Stabellini [this message]
2019-06-24 21:08       ` Julien Grall
2019-06-25  0:02         ` Stefano Stabellini
2019-06-25  9:03           ` Julien Grall
2019-06-25 12:15             ` Lars Kurth
2019-06-25 13:47               ` Andrew Cooper
2019-06-25 16:34                 ` Lars Kurth
2019-06-25 17:05                   ` Andrew Cooper
2019-06-25 19:35                   ` P S
2019-06-25 19:37                   ` Rich Persaud
2019-06-25 21:18             ` Stefano Stabellini
2019-06-25 22:04               ` Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.21.1906241317280.2468@sstabellini-ThinkPad-T480s \
    --to=sstabellini@kernel.org \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=Ian.Jackson@citrix.com \
    --cc=Julien.Grall@arm.com \
    --cc=cardoe@cardoe.com \
    --cc=committers@xenproject.org \
    --cc=lars.kurth@citrix.com \
    --cc=nd@arm.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).