All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: Hanna Reitz <hreitz@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	qemu-block@nongnu.org
Subject: Re: Running 297 from GitLab CI
Date: Fri, 1 Oct 2021 10:21:36 +0200	[thread overview]
Message-ID: <YVbFEDOgo4Onb15L@redhat.com> (raw)
In-Reply-To: <CAFn=p-bYOvg17MQ-NBDyBv_vqPgFH9MaxTO6yyKWpp1hZY4U+Q@mail.gmail.com>

Am 30.09.2021 um 23:28 hat John Snow geschrieben:
> Hiya, I was talking this over with Hanna in review to '[PATCH v3 00/16]
> python/iotests: Run iotest linters during Python CI' [1] and I have some
> doubt about what you'd personally like to see happen, here.
> 
> In a nutshell, I split out 'linters.py' from 297 and keep all of the
> iotest-bits in 297 and all of the generic "run the linters" bits in
> linters.py, then I run linters.py from the GitLab python CI jobs.
> 
> I did this so that iotest #297 would continue to work exactly as it had,
> but trying to serve "two masters" in the form of two test suites means some
> non-beautiful design decisions. Hanna suggested we just outright drop test
> 297 to possibly improve the factoring of the tests.
> 
> I don't want to do that unless you give it the go-ahead, though. I wanted
> to hear your feelings on if we still want to keep 297 around or not.

My basic requirement is that the checks are run somewhere in my local
testing before I prepare a pull request. This means it could be done by
iotests in any test that runs for -raw or -qcow2, or in 'make check'.

So if you have a replacement somewhere in 'make check', dropping 297 is
fine with me. If I have to run something entirely different, you may
need to invest a bit more effort to convince me. ;-)

Kevin



  reply	other threads:[~2021-10-01  8:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30 21:28 Running 297 from GitLab CI John Snow
2021-10-01  8:21 ` Kevin Wolf [this message]
2021-10-01 19:24   ` John Snow
2021-10-01 20:36   ` Eric Blake

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=YVbFEDOgo4Onb15L@redhat.com \
    --to=kwolf@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.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 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.