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, 21 May 2008 21:42:32 +0200
From:	Johannes Weiner <hannes@...urebad.de>
To:	Cyrill Gorcunov <gorcunov@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Theodore Tso <tytso@....edu>,
	Christoph Hellwig <hch@...radead.org>,
	Al Viro <viro@...IV.linux.org.uk>,
	linux-kernel@...r.kernel.org, davem@...emloft.net
Subject: Re: CFD: linux-wanking@...r.kernel.org (was [PATCH] Standard indentation of arguments)

Hi,

Cyrill Gorcunov <gorcunov@...il.com> writes:

> [Andrew Morton - Wed, May 21, 2008 at 10:46:44AM -0700]
> | On Wed, 21 May 2008 08:09:39 -0400 Theodore Tso <tytso@....edu> wrote:
> | 
> | > On Wed, May 21, 2008 at 06:32:06AM -0400, Christoph Hellwig wrote:
> | > > On Wed, May 21, 2008 at 01:50:37AM -0700, Andrew Morton wrote:
> | > > > Oh, what a marvellous way to encourage new contributors that was. Thank
> | > > > you so much.
> | > > > 
> | > > > For the record: Al speaks only for himself and a lack of expressed
> | > > > disagrement from others should not be taken as agreement.
> | > > 
> | > > But I'd like to second the opinion.  This is getting a little too far.
> | > > We should rather try to at least enforce very basic standards a lot of
> | > > the crap shoved in doesn't follow instead of wanking around about exact
> | > > placement of whitespaces.
> | > 
> | > The real question is whether people who are wanking about whitespace
> | > and spelling fixes in comments will graduate to writing real, useful
> | > patches.  If they won't, there's no point to encouraging them.
> | > 
> | 
> | Guys, get a clue.  It doesn't matter what that person did.  It is the
> | effect upon *all* other potential developers which is so damaging here.
> | Not upon this individual.
> | 
>
> Btw, we have CodingStyle, SubmittingPatches and other, but why don't
> we have something like KernelNewbieGuide? Don't get me wrong, but
> there could be written all rules about - what is good to do, what is bad.
> So a newbiew who wants to be usefull for kernel could read it and decide
> what should be done. /Don't beat me ;) / And of course I know about
> kernelnewbie.org but this (even quite short) document could help I
> think.

How about the following?

---

From: Johannes Weiner <hannes@...urebad.de>
Subject: [PATCH] CodingStyle: no more trivial coding style fixes, please

Add a note to CodingStyle that style cleanups should only be done if the
code is really offending and violating the kernel conventions heavily.
But no more oneliners fixing indentation and the like.

Signed-off-by: Johannes Weiner <hannes@...urebad.de>
---

 Documentation/CodingStyle |   12 ++++++++++++
 1 file changed, 12 insertions(+)

--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -783,6 +783,18 @@ own custom mode, or may have some other 
 work correctly.
 
 
+		Chapter 19:  No coding style patches, please
+
+While all these conventions should be honored when writing new code
+please do not send patches that fix minimal coding style issues only.
+
+If a whole file or several logically connected ones are in a really
+bad shape (i.e. violating several points named here), a patch cleaning
+them up in one go is okay.
+
+But do not send patches that fix indentation of two lines.  It is not
+worth the effort.
+
 
 		Appendix I: References

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