Re: [PATCH v2] net/mlx4: Use true,false for bool variable

[Leon Romanovsky]

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@xxxxxxxxx>
> > > > ---
> > > >  - 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@xxxxxxxxxx/

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