[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC v2 for-4.6 0/2] In-tree feature documentation
> On 27 Aug 2015, at 15:52, Ian Jackson <ian.jackson@xxxxxxxxxxxxx> wrote: > > Andrew Cooper writes ("[RFC v2 for-4.6 0/2] In-tree feature documentation"): >> An issue which Xen has is an uncertain support statement for features. >> Given the success seen with docs/misc/xen-command-line.markdown, and in >> particular keeping it up to date, introduce a similar system for >> features. >> >> Patch 1 introduces a proposed template (and a makefile tweak to include >> the new docs/features subdirectory), while patch 2 is a feature document >> covering the topic of migration. >> >> v2 Adds %Revision and #History table, following feedback from v1. >> >> This is tagged RFC as I expect people to have different views as to what >> is useful to include. I would particilarly appreciate feedback on the >> template before it starts getting used widely. >> >> Lars: Does this look like a reasonable counterpart to your formal >> support statement document? >> >> Jim: Per your request at the summit for new information, is patch 2 >> suitable? > > I have read both patches. Me too > I do wonder whether cross-referencing all the "issues" is a good idea. > It seems like it might be a lot of work to keep them in step. There is a risk that these may go stale. I am wondering, whether if we do have features, we can come up with some conventions that allow us to grep for the issues on the list. Just an idea. We could have a unique feature ID in the #basics section. Migration (as in the first line of migration.pandoc) is probably too generic in this example (too many false negatives). But if there was a unique enough feature identifier that can be grep'ed in commit logs, on xen-devel@, ... that may help. > Overall I think this is a good template. The extra overhead may even > be negative. The work of writing up a feature in the style of this > document may obviate the need to put much of the same information in a > 0/N or a design document, and the existing template is quite > lightweight. I agree. I don't really have any additional comments Andrew. So feel free to We may need some extra tags/headings, if we were to include things such as _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |