On Sat, Nov 23, 2019 at 4:42 PM Paul Walmsley <paul.walmsley@xxxxxxxxxx> wrote: > > On Sat, 23 Nov 2019, Dan Williams wrote: > > > I took a look, and I think the content would just need to be organized > > into the proposed sections. The rules about what level of ratification a > > specification needs to receive before a patch will be received sounds > > like an extension to the Submit Checklist to me. So I'd say just format > > your first paragraph into the Overview section and the other 2 into > > Submit Checklist and call it good. > > I'm fine with doing that for this patch. > > Stepping back to the broader topic of the maintainer profile patches, one > comment there: unless you're planning to do automated processing on these > maintainer profile document sections, it's probably better to let > maintainers format their own profile documents as they wish. > > Just to use the arch/riscv document as an example: the last two > paragraphs, to me, don't belong in a "submit checklist" section, since > that implies that the text there only needs to be read before patches are > submitted. We'd really prefer that developers understand what patches > we'll take before they even start developing them. > > I imagine we wouldn't be the only ones that would prefer to create their > own section headings in this document, etc. I'm open to updating the headers to make a section heading that matches what you're trying to convey, however that header definition should be globally agreed upon. I don't want the document that tries to clarify per-subsystem behaviours itself to have per-subsystem permutations. I think we, subsystem maintainers, at least need to be able to agree on the topics we disagree on. Would it be sufficient if I just clarified that "Submit Checklist Addendum" also includes guidance about which patches are out of scope for submission in the first instance?
