netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sasha Levin <Alexander.Levin@microsoft.com>
To: David Miller <davem@davemloft.net>
Cc: "jiri@resnulli.us" <jiri@resnulli.us>,
	"jiri@mellanox.com" <jiri@mellanox.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"idosch@mellanox.com" <idosch@mellanox.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
Subject: Re: [patch net] devlink: convert occ_get op to separate registration
Date: Tue, 10 Apr 2018 20:43:31 +0000	[thread overview]
Message-ID: <20180410204329.GJ2341@sasha-vm> (raw)
In-Reply-To: <20180410.152257.1812747859010556634.davem@davemloft.net>

On Tue, Apr 10, 2018 at 03:22:57PM -0400, David Miller wrote:
>From: Sasha Levin <Alexander.Levin@microsoft.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.

Gotcha. I can keep it out from the regular patch flow. How could we
address commits that might have been missed? Let's say I look at commits
that are older than ~1 month, how can I get those looked at again?

>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.

I think we're just hitting the limitations of using a mailing list. Bots
aren't around to spam everyone for fun, right?

0day bot is spammy because patches fail to compile, syzbot is spammy
because we have tons of bugs users can hit and the stable bot is
spammy because we miss lots of commits that should be in stable.

As the kernel grows, not only the codebase is expanding but also the
tooling around it. While spammy, bots provide valuable input that in the
past would take blood, sweat and tears to acquire. We just need a better
way to consume it rather than blocking off these inputs.

Thanks!

  reply	other threads:[~2018-04-10 20:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-05 20:13 [patch net] devlink: convert occ_get op to separate registration Jiri Pirko
2018-04-05 20:55 ` David Ahern
2018-04-05 20:58   ` David Ahern
2018-04-05 21:17   ` Jiri Pirko
2018-04-08 16:46 ` David Miller
2018-04-10 13:49 ` Sasha Levin
2018-04-10 14:13   ` Jiri Pirko
2018-04-10 14:36     ` David Miller
2018-04-10 14:35   ` David Miller
2018-04-10 19:08     ` Sasha Levin
2018-04-10 19:22       ` David Miller
2018-04-10 20:43         ` Sasha Levin [this message]
2018-04-11  8:46           ` gregkh
2018-04-11 20:04             ` Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180410204329.GJ2341@sasha-vm \
    --to=alexander.levin@microsoft.com \
    --cc=davem@davemloft.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=idosch@mellanox.com \
    --cc=jiri@mellanox.com \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).