[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180410.152257.1812747859010556634.davem@davemloft.net>
Date: Tue, 10 Apr 2018 15:22:57 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: Alexander.Levin@...rosoft.com
Cc: jiri@...nulli.us, jiri@...lanox.com, netdev@...r.kernel.org,
idosch@...lanox.com, stable@...r.kernel.org,
gregkh@...uxfoundation.org
Subject: Re: [patch net] devlink: convert occ_get op to separate
registration
From: Sasha Levin <Alexander.Levin@...rosoft.com>
Date: Tue, 10 Apr 2018 19:08:20 +0000
> The bot tries to take the "dumb" part out of your way, by letting
> you know from the start which trees this applied/built on and what
> dependencies it might have. It comes for free, why not use it?
I do this already while I'm processing the -stable queue in patchwork
and it automatically falls right out of the process I use to extract
patches out of Linus's GIT tree.
I manually pull the commit out of Linus's tree, verify that it is
actually the commit I'm interested in, then I do two things:
1) I look at the exact tag that the commit landed in using
"git describe --contains SHA1_ID"
2) I look at the exact tag that the commit the Fixes: tag
points at landed using "git describe --contains SHA1_ID"
I double check #2 to see for cases whether the Fixes: tag
itself was backported to stable trees.
I use these two tag values to organize the -stable queue into
subdirectories. This guides my patch applying in order to minimize
useless work.
So I have to do all of this work anyways.
Even if the bot provided these values, I would still double
check them, every single one of them.
Therefore, the net result from my perspective is that for most
patches fixing bugs on this list, instead of N list postings,
there will now be at least N * 2.
Bots are starting to overwhelm actual content from human beings
on this list, and I want to put my foot on the brake right now
before it gets even more out of control.
Thank you.
Powered by blists - more mailing lists