From: Fengguang Wu <firstname.lastname@example.org> To: Dmitry Vyukov <email@example.com> Cc: Guenter Roeck <firstname.lastname@example.org>, LKML <email@example.com>, Theodore Ts'o <firstname.lastname@example.org>, "Eric W. Biederman" <email@example.com>, Greg Kroah-Hartman <firstname.lastname@example.org>, Andrew Morton <email@example.com>, Linus Torvalds <firstname.lastname@example.org>, syzkaller <email@example.com>, Stephen Rothwell <firstname.lastname@example.org>, David Miller <email@example.com> Subject: Re: what trees/branches to test on syzbot Date: Fri, 19 Jan 2018 09:48:03 +0800 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <CACT4Y+aGMoobn069+Lq1BT2YGqi9qYY9vHFtiXT2DLsJ5ZUh9Q@mail.gmail.com> Hi Dmitry, On Tue, Jan 16, 2018 at 10:58:51AM +0100, Dmitry Vyukov wrote: >On Tue, Jan 16, 2018 at 10:45 AM, Guenter Roeck <email@example.com> wrote: >> On Mon, Jan 15, 2018 at 11:51 PM, Dmitry Vyukov <firstname.lastname@example.org> wrote: >>> Hello, >>> >>> Several people proposed that linux-next should not be tested on >>> syzbot. While some people suggested that it needs to test as many >>> trees as possible. I've initially included linux-next as it is a >>> staging area before upstream tree, with the intention that patches are >>> _tested_ there, is they are not tested there, bugs enter upstream >>> tree. And then it takes much longer to get fix into other trees. >>> >>> So the question is: what trees/branches should be tested? Preferably >>> in priority order as syzbot can't test all of them. >>> >> >> I always thought that -next existed specifically to give people a >> chance to test the code in it. Maybe the question is where to report >> the test results ? > >FTR, from Guenter on another thread: > >> Interesting. Assuming that refers to linux-next, not linux-net, that >> may explain why linux-next tends to deteriorate. I wonder if I should >> drop it from my testing as well. I'll be happy to follow whatever the >> result of this exchange is and do the same. > >If we agree on some list of important branches, and what branches >specifically should not be tested with automatic reporting, I think it >will benefit everybody. >+Fengguang, can you please share your list and rationale behind it? 0-day aims to aggressively test as much tree and branches as possible, including various developer trees, maintainer, linux-next, mainline and stable trees. Here are the complete list of 800+ trees we monitored: https://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git/tree/repo/linux The rationale is obvious. IMHO what really matters here is about capability rather than rationale: that policy heavily relies on the fundamental capability of auto bisecting. Once regressions are bisected, we know the owners of problem to auto send report to, ie. the first bad commit's author and committer. For the bugs that cannot be bisected, they tend to be old ones and we report more often on mainline tree than linux-next. Thanks, Fengguang
next prev parent reply other threads:[~2018-01-19 1:48 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-01-16 7:51 Dmitry Vyukov 2018-01-16 9:45 ` Guenter Roeck 2018-01-16 9:58 ` Dmitry Vyukov 2018-01-16 16:58 ` Guenter Roeck 2018-01-16 17:02 ` Eric W. Biederman 2018-01-16 17:34 ` Greg Kroah-Hartman 2018-01-22 13:32 ` Dmitry Vyukov 2018-06-09 6:31 ` Tetsuo Handa 2018-06-09 22:17 ` Linus Torvalds 2018-06-10 1:51 ` Theodore Y. Ts'o 2018-06-10 6:11 ` Dmitry Vyukov 2018-06-11 1:22 ` Theodore Y. Ts'o 2018-06-15 9:54 ` Dmitry Vyukov 2018-06-18 4:52 ` Stephen Rothwell 2018-06-18 6:10 ` Eric W. Biederman 2018-06-18 13:54 ` Alan Cox 2018-06-26 10:54 ` Tetsuo Handa 2018-06-26 14:16 ` Theodore Y. Ts'o 2018-06-26 14:38 ` Dmitry Vyukov 2018-06-26 14:54 ` Guenter Roeck 2018-06-26 20:37 ` Tetsuo Handa 2018-07-05 10:49 ` Tetsuo Handa 2018-07-06 23:26 ` Tetsuo Handa 2018-07-10 0:35 ` Andrew Morton 2018-07-10 2:13 ` Tetsuo Handa 2018-01-19 1:48 ` Fengguang Wu [this message] 2018-01-22 13:34 ` Dmitry Vyukov
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: what trees/branches to test on syzbot' \ /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
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.