linux-kernel - Re: [PATCH] net: aquantia: fix aq_ndev_start

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] [day] [month] [year] [list]

Date:   Thu, 26 Apr 2018 22:37:34 +0200
From:   Luc Van Oostenryck <luc.vanoostenryck@...il.com>
To:     David Miller <davem@...emloft.net>
Cc:     linux-kernel@...r.kernel.org, igor.russkikh@...antia.com,
        netdev@...r.kernel.org
Subject: Re: [PATCH] net: aquantia: fix aq_ndev_start_xmit()'s return type

On Tue, Apr 24, 2018 at 10:42:50AM -0400, David Miller wrote:
> 
> Luc please don't submit such a huge number of patches all at one time.
> 
> ...
> 
> Finally, make this a true patch series.  It is so much easier for
> maintainers to work with a set of changes all doing the same thing if
> you make them a proper patch series with an appropriate "[PATCH 0/N] ..."
> header posting.
> 
> Thank you.

I suppose these sort of patches are as much a PITA for the sender
than for the receivers.

I hesitated between a single patch, a series or separated patches.
In a sense, the single patch would have been the easier for both sides
but I guessed it would not have been very well welcomed. Since for a
series, you're supposed to CC the whole series to everyone involved,
it would have been, or at least at thought so, maximaly noisy for no
good reasons. Finally, as all of these patches are totally independent,
I thought it would be the best to send them as separated patches, 
each drivers maintainers being then free to accept, reject or ignore
the patch(es) concerning him/her. It seems it was a bad guess, and
yes, I see the point of having a series for this.

I'll remember all this for the next time (if next time there is,
of course, I was already quite hesitant to spend time to prepare
and send patches for these issues with enum/integer mix-up).

Sorry for the annoyance,
-- Luc