netdev - Re: [PATCH V2] net: dsa: ksz: Add reset GPIO handling

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:   Mon, 10 Dec 2018 14:26:51 +0100
From:   Marek Vasut <marex@...x.de>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, f.fainelli@...il.com,
        vivien.didelot@...oirfairelinux.com, Woojung.Huh@...rochip.com,
        UNGLinuxDriver@...rochip.com,
        "David S . Miller" <davem@...emloft.net>,
        Tristram Ha <Tristram.Ha@...rochip.com>
Subject: Re: [PATCH V2] net: dsa: ksz: Add reset GPIO handling

On 12/08/2018 12:11 PM, Andrew Lunn wrote:
>> This actually is an individual patch, it doesn't depend on anything.
>> Or do you mean a series with the DT documentation change ?
> 
> Yes, i mean together with the DT documentation change. Those two
> belong together, they are one functional change.

Fine

> Part of this is also to do with scalability. It takes less effort to
> merge one patchset of two patches, as two individual patches. The
> truth is, developer time is cheap, maintainer time is expensive

This is _not_ fine and I am actually offended by this statement.
The way I read this is that maintainer time has more value than
developer time, which justifies spending the developer time by
maintainers without having any appreciation for it. I hope I am
misreading your statement ?

>, so
> the process is optimized towards making the maintainers life easy.
> 
> So sometimes you do combine orthogonal changes together into one
> patchset, if there is a high purpose, eg. adding support for a new
> device on a new board. However, given the situation of two overlapping
> patchsets, it might be better to submit smaller patchsets.
> 
> 	   Andrew
> 


-- 
Best regards,
Marek Vasut