linux-kernel - Re: GPU-DRM-STI: Fine-tuning for some function implementations

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:   Sat, 6 May 2017 08:33:04 -0400
From:   Sean Paul <seanpaul@...omium.org>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>
Cc:     Sean Paul <seanpaul@...omium.org>, dri-devel@...ts.freedesktop.org,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        David Airlie <airlied@...ux.ie>,
        Fabien Dessenne <fabien.dessenne@...com>,
        Vincent Abriou <vincent.abriou@...com>,
        kernel-janitors@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: GPU-DRM-STI: Fine-tuning for some function implementations

On Fri, May 05, 2017 at 05:04:40PM +0200, SF Markus Elfring wrote:
> > It seems like you're back to submitting cocci patches again :)
> 
> My contribution activities are varying also for Linux software over time.   ;-)
> 
> The corresponding source code search patterns get different popularity.
> 
> 
> > I don't want to waste your time by ignoring your patches, so please ensure that
> > your patches provide value and that they are tested.
> 
> Which benchmarks and system tests would you find representative for this patch series?
> 

Given your history of submitting changes which break working code, I want
assurance that you've actually run the code and verified that it does what you
want it to do.

> How do you think generally about the proposed change possibilities?

Generally speaking, I don't care about checkpatch/cocci changes that aren't
tested. They clutter the log and don't provide enough value to justify the risk
of breaking stuff. 

IMO, the only time this would be acceptable is if a new contributor wanted to
wet their feet with a couple cleanup patches before diving in to actual
functional changes. In that case, I wouldn't mind dealing with breakage since
we'll benefit from their contributions in the future. With your changes, we
don't have this upside.

Sean

> 
> Regards,
> Markus

-- 
Sean Paul, Software Engineer, Google / Chromium OS