On Mon, Nov 25, 2019 at 7:51 AM Jonathan Corbet <corbet@xxxxxxx> wrote: > > On Sun, 24 Nov 2019 12:59:42 -0800 > Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > > > Changes since v2 [1]: > > - Drop any consideration for coding style concerns in the profile. It > > was a minor aspect of the proposal that generated the bulk of the > > feedback on v2. Lets make progress on the rest. > > > > - Clarify that the "Submit Checklist Addendum" can also include details > > that submitters need to take into account before even beginning to > > craft a patch. This is in response to the RISC-V use case of > > declaring specification readiness as a patch gate, and is now also used > > by the libnvdimm subsystem to clarify details about ACPI NVDIMM Device > > Specific Method specifications. (Paul) > > > > - Non-change from v2: Kees had asked for a common directory for all > > profiles to live, but Mauro noted that this could be handled later > > with some scripting to post-process the MAINTAINERS file, or otherwise > > converting MAINTAINERS to ReST. > > > > - Clarify the cover letter to focus on the contributor focused > > Maintainer Entry Profiles, and defer discussion of a maintainer > > focused Handbook. > > OK, some notes... > > I wish you'd done this against docs-next, that would have saved me > resolving a few conflicts on the MAINTAINERS file. > > I thought we'd agreed to move this to the process book? That said, I now > wonder about that...today I read the document as information for > maintainers on how to create their profile, so its location in the > maintainers manual is appropriate. > > There were a number RST issues and warnings that I fixed up with the > following add-on patch; it was mostly a matter of adding blank lines where > needed. > > One other warning resulted from the nvdimm profile document not being > linked into the TOC tree. I've added a TOC section to the new document to > bring these things together for now. This is almost certainly not what we > want in the longer term. > > It was tempting to ask for this stuff to be fixed up, but I didn't want to > delay this work any longer. So it's applied to docs-next; unless something > explodes in the very near future, I intend to push this for 5.5. Apologies for all of the above. I rushed it without considering the docs submission basics. Thanks for moving this forward.
