From: Peter Maydell <peter.maydell@linaro.org>
To: Max Reitz <mreitz@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Thomas Huth <thuth@redhat.com>,
John Snow <jsnow@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Qemu-block <qemu-block@nongnu.org>
Subject: Re: [PATCH v5 1/5] iotests: remove 'linux' from default supported platforms
Date: Fri, 4 Oct 2019 14:16:17 +0100 [thread overview]
Message-ID: <CAFEAcA-4-ttpQ5S-HuEtv86TeNjBnFzp77D5ML1D9CZMYGR5Ow@mail.gmail.com> (raw)
In-Reply-To: <d194e22c-7125-e558-0a80-131a28a87419@redhat.com>
On Fri, 4 Oct 2019 at 13:45, Max Reitz <mreitz@redhat.com> wrote:
> > In the end, I don't care what code these patches touched. I do an
> > innocent git pull, and when I finally see that it's master that breaks
> > iotests and not my patches on top of it, I'm annoyed.
>
> Hm. Part of my point was that this still happens all the time.
>
> Which is why I’d prefer more tests to run in CI than a handful of not
> very useful ones in make check.
>
> (Of course, running it in a CI won’t prevent iotest failures on your
> machine, but in practice neither does the current model.)
If you want the tree to be defended against problems, then
you need to run tests in 'make check'. Nothing else gets consistently
run and has failures spotted either before code goes into the
tree or quickly afterwards. 'make check' does have the restriction
that we don't want the tests to take too long to run, but in
general the block layer should be running some reasonable subset
of tests in the project's standard "run the tests please" command.
(I have no opinion on exactly what that subset ought to be, beyond
that it would be good if that subset doesn't have known intermittent
failures in it.)
> I still think that I personally would prefer the iotests to not run as
> part of make check, but just as CI.
'make check' *is* our CI gate, to a first approximation. Most of
the various travis and other setups are simply a front-end for
"build QEMU in various configurations and on various hosts
and then run 'make check'". The travis setup at the moment is
a bit odd, because it runs tests but it's not a gate on our
merging changes. Ideally I would like to fix this so that
rather than me personally running "make check" via a bunch
of scripts we have one CI setup that we trust (gitlab seems
the current favoured contender) and that gates changes flowing
into master rather than me doing it manually. We might then turn
travis off if it's not providing anything for us that the gitlab
setup doesn't.
thanks
-- PMM
next prev parent reply other threads:[~2019-10-04 13:19 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-17 23:45 [Qemu-devel] [PATCH v5 0/5] iotests: use python logging John Snow
2019-09-17 23:45 ` [Qemu-devel] [PATCH v5 1/5] iotests: remove 'linux' from default supported platforms John Snow
2019-09-18 13:16 ` Vladimir Sementsov-Ogievskiy
2019-09-23 13:09 ` Max Reitz
2019-09-23 17:21 ` John Snow
2019-09-27 23:35 ` John Snow
2019-10-01 18:44 ` Max Reitz
2019-10-02 4:46 ` Thomas Huth
2019-10-02 11:57 ` Max Reitz
2019-10-02 13:11 ` Thomas Huth
2019-10-02 13:36 ` Max Reitz
2019-10-02 14:26 ` Thomas Huth
2019-10-02 16:44 ` Kevin Wolf
2019-10-02 17:47 ` Max Reitz
2019-10-04 10:19 ` Kevin Wolf
2019-10-04 12:44 ` Max Reitz
2019-10-04 13:16 ` Peter Maydell [this message]
2019-10-04 13:50 ` Max Reitz
2019-10-04 14:05 ` Peter Maydell
2019-10-04 14:40 ` Max Reitz
2019-10-07 12:16 ` Thomas Huth
2019-10-07 12:38 ` Peter Maydell
2019-10-07 12:52 ` Max Reitz
2019-10-07 13:11 ` Thomas Huth
2019-10-07 16:28 ` Thomas Huth
2019-10-07 16:55 ` Max Reitz
2019-10-02 17:54 ` Thomas Huth
2019-10-03 0:16 ` John Snow
2019-09-17 23:45 ` [Qemu-devel] [PATCH v5 2/5] iotests: add script_initialize John Snow
2019-09-18 13:48 ` Vladimir Sementsov-Ogievskiy
2019-09-23 13:30 ` Max Reitz
2019-09-23 13:34 ` Max Reitz
2019-09-17 23:45 ` [Qemu-devel] [PATCH v5 3/5] iotest 258: use script_main John Snow
2019-09-23 13:33 ` Max Reitz
2019-09-17 23:45 ` [Qemu-devel] [PATCH v5 4/5] iotests: specify protocol support via initialization info John Snow
2019-09-23 13:35 ` Max Reitz
2019-09-17 23:45 ` [Qemu-devel] [PATCH v5 5/5] iotests: use python logging for iotests.log() John Snow
2019-09-18 14:52 ` Vladimir Sementsov-Ogievskiy
2019-09-18 17:11 ` John Snow
2019-09-23 13:57 ` Max Reitz
2019-10-04 15:39 ` [PATCH v5 0/5] iotests: use python logging Max Reitz
2019-10-11 23:39 ` John Snow
2020-02-24 11:15 ` Max Reitz
2020-02-25 21:50 ` John Snow
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=CAFEAcA-4-ttpQ5S-HuEtv86TeNjBnFzp77D5ML1D9CZMYGR5Ow@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@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 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.