From: Eryu Guan <eguan@redhat.com>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: fstests <fstests@vger.kernel.org>,
linux-xfs <linux-xfs@vger.kernel.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>, Jan Kara <jack@suse.cz>,
Dave Chinner <david@fromorbit.com>,
Dan Williams <dan.j.williams@intel.com>,
Amir Goldstein <amir73il@gmail.com>
Subject: Re: [fstests PATCH v6 2/2] generic: add test for DAX MAP_SYNC support
Date: Sun, 10 Dec 2017 14:15:25 +0800 [thread overview]
Message-ID: <20171210061525.GK2749@eguan.usersys.redhat.com> (raw)
In-Reply-To: <20171208174747.GA4308@linux.intel.com>
On Fri, Dec 08, 2017 at 10:47:47AM -0700, Ross Zwisler wrote:
> On Fri, Dec 08, 2017 at 02:36:10PM +0800, Eryu Guan wrote:
>
> > (Test was re-numbered as generic/470, BTW.)
>
> Thanks! For future reference, does the pattern of us submitting tests with
> high numbers (generic/999) to avoid merge conflicts and asking you to renumber
> them when you merge work for you? Or would you prefer that we number our
> tests to the next available, which may change from submission to submission?
For patch that adds a single test, either way is fine, I need to edit
the patch anyway on conflicts, as the group file conflicts. For patch or
patchset that adds multiple tests, starting with a high test seq number
would be better, I only need to edit the group file by hand, not the seq
numbers in each test (that can be done by ./tools/mvtest script).
But overall, the starting seq number doesn't matter that much. OTOH,
basing new tests on top of latest master as much as possible would be
perfered, that reduces the possibility of conflicts, as I only need to
resolve conflicts within all the new tests.
Thanks,
Eryu
prev parent reply other threads:[~2017-12-10 6:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-06 0:37 [fstests PATCH v5 0/2] add test for DAX MAP_SYNC support Ross Zwisler
2017-12-06 0:37 ` [fstests PATCH v5 1/2] dm-log-writes: only replay log to marks that exist Ross Zwisler
2017-12-06 12:53 ` Amir Goldstein
2017-12-06 0:37 ` [fstests PATCH v5 2/2] generic: add test for DAX MAP_SYNC support Ross Zwisler
2017-12-06 13:41 ` Amir Goldstein
2017-12-07 10:36 ` Eryu Guan
2017-12-07 22:58 ` Ross Zwisler
2017-12-07 23:19 ` [fstests PATCH v6 " Ross Zwisler
2017-12-08 6:36 ` Eryu Guan
2017-12-08 17:47 ` Ross Zwisler
2017-12-10 6:15 ` Eryu Guan [this message]
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=20171210061525.GK2749@eguan.usersys.redhat.com \
--to=eguan@redhat.com \
--cc=amir73il@gmail.com \
--cc=dan.j.williams@intel.com \
--cc=david@fromorbit.com \
--cc=fstests@vger.kernel.org \
--cc=jack@suse.cz \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-xfs@vger.kernel.org \
--cc=ross.zwisler@linux.intel.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;
as well as URLs for NNTP newsgroup(s).