From: Dave Chinner <david@fromorbit.com>
To: Xiong Zhou <xzhou@redhat.com>
Cc: Amir Goldstein <amir73il@gmail.com>,
fstests <fstests@vger.kernel.org>,
Miklos Szeredi <miklos@szeredi.hu>, Jan Kara <jack@suse.cz>
Subject: Re: [PATCH v3] generic: add stress test for fanotify and inotify
Date: Mon, 12 Feb 2018 16:08:40 +1100 [thread overview]
Message-ID: <20180212050840.GC7000@dastard> (raw)
In-Reply-To: <20180212043357.x6dhq67wghzgafrw@XZHOUW.usersys.redhat.com>
On Mon, Feb 12, 2018 at 12:33:57PM +0800, Xiong Zhou wrote:
> On Mon, Feb 12, 2018 at 05:50:21AM +0200, Amir Goldstein wrote:
> > Patchset is for a reason - the reason is that all patches should be
> > reviewed and merged together. But that's got nothing to do with the
> > reason you should list the fix commit in test description.
> > The reason for that is that testers needs to know if test is expected to
> > fail or pass on the kernel they are using.
>
> AFAIK, known issue tracking is not handled by fstests.
And by that reasoning, commit IDs for bug fixes should not be in
fstests at all.
However, it is useful to many people to have a reference to the fix
associated with the test (or at least it's initial commit). That can
either be a commit ID or a url that points to the patch on the
mailing list that will be committed to fix it.
> > Listing the cleanup patches does not serve this purpose.
> > In fact, it may confuse people testing stable kernels, because stable
> > kernel could have fix patches applied but not all cleanup patches.
>
> Interesting, I'm listing all of them and I'm saying "fixed by this series"
> not "fixed by this commit".
That's way too much irrelevant information, especially as "issue
tracking is not handled by fstests".
Please listen to Amir and follow the convention that everyone has
agreed on for referencing the fix a regression test relates to.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2018-02-12 5:09 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CCAOQ4uxh2ZmEJi8gbiDRsYefV+XC20TNLjW9OFOZM0=j0_0yf+Q@mail.gmail.com>
2018-02-11 6:59 ` [PATCH v3] generic: add stress test for fanotify and inotify Xiong Zhou
2018-02-11 20:03 ` Amir Goldstein
2018-02-12 0:41 ` Xiong Zhou
2018-02-12 3:50 ` Amir Goldstein
2018-02-12 4:33 ` Xiong Zhou
2018-02-12 5:08 ` Dave Chinner [this message]
2018-02-12 5:38 ` Xiong Zhou
2018-02-12 5:46 ` [PATCH v4] " Xiong Zhou
2018-02-12 7:02 ` Dave Chinner
2018-02-12 8:34 ` Xiong Zhou
2018-02-14 11:03 ` Jan Kara
2018-02-14 11:22 ` Amir Goldstein
2018-02-14 15:03 ` Eryu Guan
2018-02-15 8:33 ` Amir Goldstein
2018-02-15 0:49 ` Xiong Zhou
2018-02-15 9:23 ` Jan Kara
2018-02-16 0:38 ` Xiong Zhou
2018-02-16 9:52 ` Jan Kara
2018-02-17 1:21 ` Xiong Zhou
2018-02-12 5:17 ` [PATCH v3] " Xiong Zhou
2018-02-12 6:48 ` Amir Goldstein
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=20180212050840.GC7000@dastard \
--to=david@fromorbit.com \
--cc=amir73il@gmail.com \
--cc=fstests@vger.kernel.org \
--cc=jack@suse.cz \
--cc=miklos@szeredi.hu \
--cc=xzhou@redhat.com \
/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