linux-kernel - Re: vmbus: Delete an error message for a failed memory allocation in vmbus_device

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 12 May 2017 00:52:20 -0700
From:   Joe Perches <joe@...ches.com>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>,
        Dan Carpenter <dan.carpenter@...cle.com>
Cc:     Stephen Hemminger <stephen@...workplumber.org>,
        Wolfram Sang <wsa@...-dreams.de>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        kernel-janitors@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>, devel@...uxdriverproject.org
Subject: Re: vmbus: Delete an error message for a failed memory allocation
 in vmbus_device_create()

On Fri, 2017-05-12 at 09:32 +0200, SF Markus Elfring wrote:
> Will patches be picked up also from contributors who got a special
> development reputation anyhow?

Yes.

Developer reputation matters for somewhat controversial
patches being applied as well as non-controversial and
obviously correct patches being ignored.

Your reputation means most all of your patches fall into
the latter category.

Look up "wheat and chaff".

Your patches are mostly chaff.

You have produced many trivial patches that have caused
new defects.  That is simply unacceptable.  Especially
when you don't immediately fix the problems you cause.

If you would stop producing the trivial and instead
channel your efforts into actual bug fixing and logic
corrections and not just style modifications with no
code impact, your patch acceptance rate would increase.

Yes, your daily patch production rate would fall.
Likely every reader of LKML but you would be happy.

I have given you many suggestions for actual structural
improvements to kernel code.

You have ignored _all_ of them and I am unlikely to try
to interact with you any longer until your wheat:chaff
ratio changes.