From: Lucas Meneghel Rodrigues <lmr@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Michael Goldish <mgoldish@redhat.com>,
kvm@vger.kernel.org, autotest@test.kernel.org
Subject: Re: [PATCH] KVM: tests_base.cfg: major guest OS cleanup
Date: Sun, 07 Feb 2010 23:59:01 -0200 [thread overview]
Message-ID: <1265594341.2409.49.camel@localhost.localdomain> (raw)
In-Reply-To: <20100208004430.GA9874@amt.cnet>
On Sun, 2010-02-07 at 22:44 -0200, Marcelo Tosatti wrote:
> On Sun, Feb 07, 2010 at 09:26:21PM -0200, Lucas Meneghel Rodrigues wrote:
> > * Removing older versions of distributions like Fedora have good reason:
> > The support cycle of them is very short (18 months), by their very
> > nature (Fedora is a technology preview, we are allways moving on).
> > So it's not reasonable to keep testing guest OS that might have bugs
> > that no one will care to fix.
>
> Disagree. Testing of older guests can trigger KVM bugs which are not
> seen during testing of newer ones.
Ok, that's a fair concern, we need to make sure that bugs found on older
guests will get enough attention though.
> > So in terms of maintance, we are better of keeping unattended installs
> > for the OSs we know how to do it, but keep up to date step files for the
> > guest OSs that we can't use with unattended. Like, bump the versions for
> > all the OSs that we can't do unattended version, and have up to date
> > step files for those.
>
> Why don't keep both?
Mostly because it was my understanding that we only cared about bugs on
the latest versions of each supported OS, given that premise it made
sense to me to keep only unattended install, which depends less on OS
details (for example, the same kickstart and answer files could be used
verbatim to both old and new versions of the OSes).
But now I see your point and Michael's, sorry, will bring back all the
step file install parameters back.
> > We could keep them, but like I've said, we should focus our testing
> > resources using the latest versions provided by the OS vendors.
>
> Agree, but please keep the old step file method around in the reposity
> for all guests. Not only they can be useful if problems arise with
> unattended install, but the screen comparison method that is used can
> find bugs that unattended install cannot (issues that involves drawing
> the screen).
All righty, will get them all back during the morning!
Lucas
next prev parent reply other threads:[~2010-02-08 1:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <916935176.1156301265564705305.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
2010-02-07 18:24 ` [PATCH] KVM: tests_base.cfg: major guest OS cleanup Michael Goldish
2010-02-07 23:26 ` Lucas Meneghel Rodrigues
2010-02-08 0:44 ` Marcelo Tosatti
2010-02-08 1:59 ` Lucas Meneghel Rodrigues [this message]
2010-02-09 12:57 ` [Autotest] " Lucas Meneghel Rodrigues
2010-02-05 15:46 Lucas Meneghel Rodrigues
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=1265594341.2409.49.camel@localhost.localdomain \
--to=lmr@redhat.com \
--cc=autotest@test.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=mgoldish@redhat.com \
--cc=mtosatti@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