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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ