linux-kernel - Re: [PATCH 0/3] Add GPIO support for the MAX6650/6651 ICs

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140108172240.GD14575@lee--X1>
Date:	Wed, 8 Jan 2014 17:22:40 +0000
From:	Lee Jones <lee.jones@...aro.org>
To:	Laszlo Papp <lpapp@....org>
Cc:	Guenter Roeck <linux@...ck-us.net>,
	Linus Walleij <linus.walleij@...aro.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] Add GPIO support for the MAX6650/6651 ICs

On Wed, 08 Jan 2014, Laszlo Papp wrote:

> In other words, I really do not know what format you prefer for design review.
> 
> Apparently, not as previously requested, so please tell me what format
> one _should_ submit design reviews in.
> 
> I personally still think that submitting "pseudo-code" is a good way
> of it if it is clearly marked so like in my case, so that it does not
> mislead anyone that I accidentally submit a clearly broken change for
> an integration candidate.
> 
> I hope it is understood that I am asking about design reviews before
> the lengthy implementation to potentially avoid a lot of additional
> work on both sides with writing and reviewing an implementation with a
> "wrong" approach...

The correct way to do this is to submit RFC patches. If you start your
$SUBJECT line with [PATCH RFC x/x], then we know that they're
development patches and we can treat them as such.

If you're submitting code, in form, which are you in this case, they
should still abide by the submission rules. I you'd like us to review
them, then they need to be in an easy to read format. Submitting
patches with lots of whitespace variation is off-putting and hard to
review. If you want people to put aside their time to help you, then
the least you can do is make it easy for them to read. Conforming to
the 3 documentation files (I know how much you love documentation)
will ensure you're giving yourself a snowball's chance in Hell of
'winning' the response you desire.

All this toing and froing is wasting everyone's time. Just submit
nice patches for us to review and you will receive the help you
crave.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/