linux-kernel - Re: [PATCH] Documentation: SubmittingPatches: Add note about Reviewed-by tags

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <56C214A0.9070401@broadcom.com>
Date:	Mon, 15 Feb 2016 10:10:40 -0800
From:	Scott Branden <scott.branden@...adcom.com>
To:	Jonathan Corbet <corbet@....net>,
	Florian Fainelli <f.fainelli@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	bcm-kernel-feedback-list@...adcom.com
Subject: Re: [PATCH] Documentation: SubmittingPatches: Add note about
 Reviewed-by tags

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@...il.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