lkml.org 
[lkml]   [2019]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v3 0/3] Maintainer Entry Profiles
On Mon, Nov 25, 2019 at 7:51 AM Jonathan Corbet <corbet@lwn.net> wrote:
>
> On Sun, 24 Nov 2019 12:59:42 -0800
> Dan Williams <dan.j.williams@intel.com> 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.

\
 
 \ /
  Last update: 2019-11-25 17:41    [W:0.071 / U:3.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site