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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
