qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Cleber Rosa" <crosa@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	qemu-discuss@nongnu.org,
	"David Gibson" <david@gibson.dropbear.id.au>
Subject: Re: QEMU 5.1: Can we require each new device/machine to provided a test?
Date: Fri, 15 May 2020 11:23:21 +0100	[thread overview]
Message-ID: <20200515102321.GH1300305@redhat.com> (raw)
In-Reply-To: <96440c8b-7f38-8fc4-0e9c-07ad878211e2@redhat.com>

On Fri, May 15, 2020 at 12:11:17PM +0200, Thomas Huth wrote:
> On 07/04/2020 12.59, Philippe Mathieu-Daudé wrote:
> > Hello,
> > 
> > Following Markus thread on deprecating unmaintained (untested) code
> > (machines) [1] and the effort done to gather the information shared in
> > the replies [2], and the various acceptance tests added, is it
> > feasible to require for the next release that each new device/machine
> > is provided a test covering it?
> > 
> > If no, what is missing?
> 
> If a qtest is feasible, yes, I think we should require one for new
> devices. But what about machines - you normally need a test image for
> this. In that case, there is still the question where testing images
> could be hosted. Not every developer has a web space where they could
> put their test images onto. And what about images that contain non-free
> code?

Yep, it isn't feasible to make this a hard rule.

IMHO this is where a support tier classification comes into play

 - Tier 1: actively maintained, qtest coverage available. Expected
           to work reliably at all times since every commit is CI
	   tested

  - Tier 2: actively maintained, no qtest coverage. Should usually
           work but regression may creep in due to reliance on the
	   maintainer to manually test on adhoc basis

  - Tier 3: not actively maintained, unknown state but liable to
            be broken indefinitely

Tier 1 is obviously the most desirable state we would like everthing to
be at. Contributors will have to fix problems their patches cause as
they will be blocked by CI.

Tier 2 is an admission that reality gets in the way. Ideally stuff in
this tier will graduate to Tier 1 at some point. Even if it doesn't
though, it is still valid to keep it in QEMU long term. Contributors
shouldn't gratuitously break stuff in these board, but if they do,
then the maintainer is ultimately responsible for fixing it, as the
contributors don't have a test rig for it.

Tier 3 is abandonware. If a maintainer doesn't appear, users should
not expect it to continue to exist long term. Contributors are free
to send patches which break this, and are under no obligation to
fix problems in these boards. We may deprecate & delete it after a
while


Over time we'll likely add more criteria to stuff in Tier 1. This
could lead to some things dropping from Tier 1 to Tier 2. This is
OK, as it doesn't make those things worse than they already were.
We're just saying that Tier 2 isn't as thoroughly tested as we
would like it to be in an ideal world.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  reply	other threads:[~2020-05-15 10:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-07 10:59 QEMU 5.1: Can we require each new device/machine to provided a test? Philippe Mathieu-Daudé
2020-05-15 10:11 ` Thomas Huth
2020-05-15 10:23   ` Daniel P. Berrangé [this message]
2020-05-18 19:56     ` John Snow
2020-05-19  9:04       ` Daniel P. Berrangé
2020-05-19 23:06         ` John Snow
2020-05-20  6:13           ` Thomas Huth
2020-05-20  9:02             ` Daniel P. Berrangé
2020-05-20 14:53             ` John Snow
2020-05-20  8:57           ` Daniel P. Berrangé
2020-05-15 10:51   ` Gerd Hoffmann
2020-05-15 11:24     ` Paolo Bonzini

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=20200515102321.GH1300305@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=crosa@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=ehabkost@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=kraxel@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-discuss@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 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).