Even if there were a few dozen, automating the builds using these in a Virtualised environment is trivial ( there may also be some value in publishing these.
Centos 7 gftp install#
Ability to install server roles, maybe we can have a few standard kickstarts published, each of which could represent a different server role.XXX: Needs some KDE specific package lists.Ability to install a KDE Desktop, with functional:.
NEEDS some additional gnome specific package lists.Ability to install a GNOME Desktop, with functional:.Ability to install a Desktop, with a functional:.
Centos 7 gftp driver#
Install a system from cd('s) or dvd without network then configure/install driver (such as ) and configure updates across lan/wan
At the moment, real iron + vmware + xen + kvm + VirtualBox seem to be the 'cared about environments', but add to taste. And each test for the installer should be run, both in text-mode as well as graphical mode, for each of the potential install-media options, including :Īnd then repeating each of those test mechanisms for both real iron and virtualised environments we care about. We could even automate some of these things via dogtail, at some stage. We need to make sure that these things are tested for each of the installer interfaces ( via Kickstart, via GUI and via TUI ). Fabian has offered to help further define these tests and write them up for the QA process. The Clustering ( conga ) packages need special attention to check for branding removal and testing. We want to make every reasonable effort to identify and track these. the apache Vendor string, Firefox and Thunderbird have something similar. Special care should be taken to work with the packages not seen before this release.Īlso, if possible we should identify places where the branding is revealed as a part of the installed OS. Even if they are not to be changed, a mention could be made somewhere on the QA Wiki ( private please ? ) about the places where these exist. Ensure multilib sanity ( more on this later )ĭuring the entire testing process, it should be an aim to list places that are potential upstream Branding points.Ensure that package date/time stamps are preserved for packages being moved from an older releases.Ensure the package metadata is accurate.Ensure all packages are signed with the right key.However, if required, notes on what packages failed these sanity tests should be posted somewhere. Packages that dont meet these specs should not be moved into the QA repo's at all. All these tasks can be done at the buildsystem level, and should be done there.
Centos 7 gftp software#
So once we have ticks on each of these, we'd know that the product is in a 'ship' stage.Īt the end of this document I will attempt to create a test-matrix and define how we might be able to also create some software ( if nothing public is found ) to manage and track these. It could also serve, as a byproduct, a qa-testing endpoint.
Centos 7 gftp series#
Perhaps we can take this doc, merge it with the tests already in the 5.x and 4.x QA series and come up with a master template. This is a list of things that I ( KaranbirSingh ) feel we should be testing for. We should be able to expand on this wide enough that it could potentially become a standard checklist that we work through for all Releases
0 kommentar(er)
