linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Scott Branden <scott.branden@broadcom.com>
To: Jonathan Corbet <corbet@lwn.net>,
	Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Subject: Re: [PATCH] Documentation: SubmittingPatches: Add note about Reviewed-by tags
Date: Mon, 15 Feb 2016 10:10:40 -0800	[thread overview]
Message-ID: <56C214A0.9070401@broadcom.com> (raw)
In-Reply-To: <20160215104330.22cbd8c9@lwn.net>

Hi Jon,

Comments below

On 16-02-15 09:43 AM, Jonathan Corbet wrote:
> On Thu, 11 Feb 2016 18:12:58 -0800
> Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>> As is now common in a lot of organization having an internal code review
>> process (be it through Gerritt or other tools), patches extracted from
>> this review process and submitted to public mailing-lists will have
>> pre-existing Reviewed-by tags. Add a note about why these tags exists,
>> and what a maintainer could be doing with those. Some maintainers did
>> complain before that these tags had to be added when the patches get
>> submitted to the public, while some just ignored and took the patches
>> as-is.
>
> So I'll confess, I'm not quite sold on this one.  This is a document for
> people looking to learn about how to submit patches; it is already far
> too long, complex, and bureaucratic.

I agree - the patch submission process is too complicated with the email 
review and approval process in place.  If it could be streamlined in any 
way I'm all for it.  But the documentation associated with this process 
is not detailed enough and needs updating whenever possible.  It is too 
vague and leaves things open for interpretation.  This causes different 
Maintainers to have different opinions on the patch submission format 
right now.  When clarification is needed it should be added in the 
documentation.

> I'm not at all convinced that
> adding suggestions for maintainers is appropriate here.
>
> Is there a real problem that this patch is trying to solve?
Yes - the patch submission documentation does not detail what to do with 
<Reviewed-by> fields from internal code reviews of patches.
>
> Thanks,
>
> jon
>
Regards,
  Scott

      reply	other threads:[~2016-02-15 18:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-12  2:12 [PATCH] Documentation: SubmittingPatches: Add note about Reviewed-by tags Florian Fainelli
2016-02-12  3:07 ` Anup Patel
2016-02-12 18:24 ` Markus Mayer
2016-02-15 17:43 ` Jonathan Corbet
2016-02-15 18:10   ` Scott Branden [this message]

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=56C214A0.9070401@broadcom.com \
    --to=scott.branden@broadcom.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=corbet@lwn.net \
    --cc=f.fainelli@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).