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:   Tue, 15 Dec 2020 07:18:38 +0200
From:   Leon Romanovsky <leon@...nel.org>
To:     Joe Perches <joe@...ches.com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Vasyl Gomonovych <gomonovych@...il.com>, tariqt@...dia.com,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        linux-rdma@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] net/mlx4: Use true,false for bool variable

On Mon, Dec 14, 2020 at 11:15:01AM -0800, Joe Perches wrote:
> On Mon, 2020-12-14 at 11:03 -0800, Jakub Kicinski wrote:
> > On Mon, 14 Dec 2020 13:16:08 +0200 Leon Romanovsky wrote:
> > > On Mon, Dec 14, 2020 at 11:30:08AM +0100, Vasyl Gomonovych wrote:
> > > > It is fix for semantic patch warning available in
> > > > scripts/coccinelle/misc/boolinit.cocci
> > > > Fix en_rx.c:687:1-17: WARNING: Assignment of 0/1 to bool variable
> > > > Fix main.c:4465:5-13: WARNING: Comparison of 0/1 to bool variable
> > > >
> > > > Signed-off-by: Vasyl Gomonovych <gomonovych@...il.com>
> > > > ---
> > > >  - Add coccicheck script name
> > > >  - Simplify if condition
> > > > ---
> > > >  drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
> > > >  drivers/net/ethernet/mellanox/mlx4/main.c  | 2 +-
> > > >  2 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > Please refrain from sending new version of patches as reply-to to
> > > previous variants. It makes to appear previous patches out-of-order
> > > while viewing in threaded mode.
> >
> > Yes, please! I'm glad I'm not the only one who feels this way! :)
>
> I'm the other way.
>
> I prefer revisions to single patches (as opposed to large patch series)
> in the same thread.

It depends which side you are in that game. From the reviewer point of
view, such submission breaks flow very badly. It unfolds the already
reviewed thread, messes with the order and many more little annoying
things.

>
> There is no other easy way for changes to a patch to be tracked AFAIK.

Not really,  I'm using very simple convention to keep tracking of
changes. The changelog together with lorifier does the trick.

https://github.com/danrue/lorifier
https://lore.kernel.org/linux-rdma/20201125064628.8431-1-leon@kernel.org/

So I'm simply adding link to the previous version when sending new one.

>
> Most email clients use both In-Reply-To: and References: headers as
> the mechanism to thread replies.

Right, and this is exactly what we don't want for vX patches.

>
> Keeping the latest messages at the bottom of a thread works well
> to see revision sequences.

I have a different workflow.

Thanks

Powered by blists - more mailing lists