All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Walmsley <paul.walmsley@sifive.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
	linux-riscv@lists.infradead.org, palmer@dabbelt.com,
	aou@eecs.berkeley.edu, krste@berkeley.edu,
	waterman@eecs.berkeley.edu,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Doc Mailing List <linux-doc@vger.kernel.org>
Subject: Re: [PATCH] Documentation: riscv: add patch acceptance guidelines
Date: Sat, 23 Nov 2019 16:42:49 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.21.9999.1911231637510.14532@viisi.sifive.com> (raw)
In-Reply-To: <CAPcyv4hBNfabaZmKs0XF+UT9Py8zJqpNdu5KsToqp305NASKNA@mail.gmail.com>

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.


- Paul

WARNING: multiple messages have this Message-ID (diff)
From: Paul Walmsley <paul.walmsley@sifive.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: krste@berkeley.edu, aou@eecs.berkeley.edu,
	waterman@eecs.berkeley.edu, Jonathan Corbet <corbet@lwn.net>,
	Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	palmer@dabbelt.com, linux-riscv@lists.infradead.org
Subject: Re: [PATCH] Documentation: riscv: add patch acceptance guidelines
Date: Sat, 23 Nov 2019 16:42:49 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.21.9999.1911231637510.14532@viisi.sifive.com> (raw)
In-Reply-To: <CAPcyv4hBNfabaZmKs0XF+UT9Py8zJqpNdu5KsToqp305NASKNA@mail.gmail.com>

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.


- Paul

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2019-11-24  0:42 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-23  2:44 [PATCH] Documentation: riscv: add patch acceptance guidelines Paul Walmsley
2019-11-23  2:44 ` Paul Walmsley
2019-11-23  3:58 ` Matthew Wilcox
2019-11-23  3:58   ` Matthew Wilcox
2019-11-23 23:38   ` Paul Walmsley
2019-11-23 23:38     ` Paul Walmsley
2019-11-23 16:39 ` Jonathan Corbet
2019-11-23 16:39   ` Jonathan Corbet
2019-11-23 23:27   ` Paul Walmsley
2019-11-23 23:27     ` Paul Walmsley
2019-11-23 23:35     ` Dan Williams
2019-11-23 23:35       ` Dan Williams
2019-11-23 23:49       ` Paul Walmsley
2019-11-23 23:49         ` Paul Walmsley
2019-11-24  0:01         ` Dan Williams
2019-11-24  0:01           ` Dan Williams
2019-11-24  0:42           ` Paul Walmsley [this message]
2019-11-24  0:42             ` Paul Walmsley
2019-11-24  3:38             ` Dan Williams
2019-11-24  3:38               ` Dan Williams
2019-11-25  2:48               ` Paul Walmsley
2019-11-25  2:48                 ` Paul Walmsley
2019-11-25  3:20                 ` Dan Williams
2019-11-25  3:20                   ` Dan Williams
2019-11-25 15:57                 ` Jonathan Corbet
2019-11-25 15:57                   ` Jonathan Corbet
2019-11-23 18:29 ` Palmer Dabbelt
2019-11-23 18:29   ` Palmer Dabbelt

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.9999.1911231637510.14532@viisi.sifive.com \
    --to=paul.walmsley@sifive.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=krste@berkeley.edu \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=waterman@eecs.berkeley.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.