[PATCH 1/3] net: dsa: Use true instead of 1 in the set_promisc() call

[Ramon Fried]

On Mon, Nov 1, 2021 at 12:04 AM Vladimir Oltean <vladimir.oltean at nxp.com> wrote:
>
> On Sat, Oct 30, 2021 at 04:31:48PM +0300, Ramon Fried wrote:
> > > > > > Ping for apply?
> > > > > I'll get to the patches today.
> > > > > thanks for waking me up :)
> > >
> > > Why don't you apply patches immediately after reviewing them?
> > It wouldn't make a difference. you were all working on the same file
> > in code, If I would have applied bin's patches before yours, then you
> > would need to rebase.
> > simple as that. Also the time when I'm applying and when I'm reviewing
> > is also meaningless because this problem would occur anyway.
>
> I know, I was reacting to the 'thanks for waking me up' part.
> Honestly I don't see the point of going through some patches, marking
> them as reviewed, then waiting for 2 more weeks to apply them (or even
> more in other cases). It slows down the process for a reason that I
> can't see.
>
> Maybe the thinking is along the lines of "I won't apply patches that
> haven't marinated for long enough". But my patches (the ones conflicting
> with Bin's) still had build warnings even after marinating for close to
> one month (fixes for which I've sent just now). During that time, I had
> also piled up a few non-critical fixes to those patches, but I wasn't
> going to modify the patch set already in flight anyway, for fear of
> waiting again for who knows how long. Incremental fixups are fine and
> surely are a valid way of doing development too, so that argument kinda
> falls off the table. What's left?
I do let patches marinate for a while, to give other people the
opportunity to review, test and comment.
After a few weeks, when the merge window is open, I pick-up all the
patches and apply them in turn.
That's my process, and I don't think there's anything wrong with it.

If you have a fix to a patch you already got reviewed-by, send the
patch again, and add reviewed-by.
That's the way it should work.